[HN Gopher] Not Another Framework
___________________________________________________________________
Not Another Framework
Author : pspeter3
Score : 47 points
Date : 2022-01-27 17:59 UTC (5 hours ago)
(HTM) web link (remix.run)
(TXT) w3m dump (remix.run)
| huqedato wrote:
| Unfortunately Remix is just another framework! It brings nothing
| new/better than common React/Vue/Angular...
|
| It will soon fade away into the funnel of the web development
| history; just like its many other brothers before/after it.
| weego wrote:
| No, the exhausting part is not a new framework, it's being
| pitched The Next Revolution when it's just a horizontally-
| iterative variation on a domain that people continue to reinvent
| without ever actually making a difference. Someone need to step
| up to the bigger picture of how we stop the entire JS side of the
| industry repeat the same mistakes that not only other domains
| have already dealt with but that the JS community seems destined
| to repeat themselves.
| eternityforest wrote:
| The problem is browsers. On desktop you can keep expanding a
| framework as much as you want, for decades. Even 30MB is
| nothing. When we have more transparent compression in
| filesystems it will natter even less.
|
| Browsers are still stuck in the age of every kilobyte
| mattering, but we try to use them for 21st century things. Not
| a reuse friendly environment.
|
| This should be ideally fixed on the browser end I think. React
| and Vue and all the rest could fly to Google and have a big
| meeting on what to add to browsers that would make it possible
| to implement all these frameworks in 1k of code.
|
| With more core language support, maybe we could finally have
| things like Qt and GTK, mature continually maintained libraries
| that have everything you need and are just there, without you
| having to worry about the code size.
| frogperson wrote:
| I have always wondered why there isn't more hacking on the
| browser side of the web. Why don't we see attempts to replace
| javascript with python or lua or something diifferent? Why
| not replace http or html?
|
| I guess what I'm asking is, what could the web be if we take
| a step back and re-evaluate javascript at all instead of just
| the frameworks that rely on JS?
| vagrantJin wrote:
| Quite simply because HTML and JS work and works well for
| what it was intended.
|
| Your suggestion is like trying to make an F1 car from a
| Diesel locomotive.
|
| There should be another app, with an altogether different
| protocol to suit current needs because clearly, we are
| going to end up with browsers as Operating systems.
| beepbooptheory wrote:
| Having actually read the article, I thought what it had to say
| about "transferable knowledge" spoke to this general complaint
| quiet nicely. Whether you think its the right answer or not,
| I'm not sure.
| weego wrote:
| I just feel like it's trying to force the 'A-ha!' moment that
| the first rails demonstrations had for most developers at the
| time, when that ship has long sailed. I'm probably just
| jaded. There's nothing actually wrong with what they're doing
| at all, it's just 20 years later and there's an overwhelming
| feeling of 'is this all we've achieved?'
| kayodelycaon wrote:
| It's almost like each new generation of programmers needs
| to go through the same cycles of possible solutions. Those
| of us who are older see a rehashing of old arguments. Those
| who are younger, are seeing those arguments for the first
| time.
|
| I wouldn't worry too much about it. High schoolers make me
| cranky and my parent's generation is completely out of
| touch. My parents and grandparents felt the same at my age.
| :)
| danjac wrote:
| Rails was a full-stack framework that took care of
| everything from database models down to frontend AJAX
| integration, so you literally could build a very basic blog
| that actually saved stuff to a database within 20 minutes.
| Remix is yet another frontend framework that you have to
| manually wire up to some other library or service to do
| anything useful.
| kayodelycaon wrote:
| Rails is... ;) (7.0 was released last month)
| franciscop wrote:
| The big component libraries in Javascript are +10 years old
| (except for Vue.js, which is "only" 7 years old), everything
| else that came afterwards is just a rehash/horizontal iteration
| as you say, be it Next, Gatsby, or Remix. If you learn e.g.
| React well, using any of these frameworks is fairly easy.
|
| Which is kind of cool IMHO; this means the core libraries
| remain the same and then the ecosystem improves around. It's a
| world of a difference between React early days manual setup,
| the big advancement that was Create-React-App, and then again
| some other minor but amazing leaps like esbuild or vitejs. I
| can setup a fully-featured React app and be productive in
| seconds, with amazing nice things to have that traditionally
| had to be manually configured in other languages (linter,
| transpiler, hot module reload, etc).
| pier25 wrote:
| Remix is looking super cool. A breath of fresh air really in the
| JS ecosystem.
|
| Rich Harris (creator of Svelte) has actually been introducing new
| features to SvelteKit inspired by Remix.
|
| https://github.com/sveltejs/kit/issues/3533
|
| https://github.com/sveltejs/kit/issues/3532
|
| A lot of people in this thread are having weird opinions because
| they don't really understand the context of Remix. The point of
| Remix is that it facilitates SSR + hydration + progressive
| enhancement full stack dev in the most efficient way possible
| regarding DX. Network wise it's also much more efficient than
| Next, which is the predominant framework in this space.
|
| Of course if you just want to spit out HTML from your server,
| Remix would be a pretty stupid choice. In part because React's
| render to string is very slow, but also because there are already
| very mature options to do that (Rails, Django, Laravel, etc).
| jscholes wrote:
| This page talks a lot about knowledge that is transferable, e.g.:
|
| > We want your experience with Remix to transfer to web
| development generally.
|
| But then, you opened the quickstart tutorial[1], and the first
| bit of mark-up is: <Link
| to="/posts">Posts</Link>
|
| Uh... okay. Not only is this not how you create links in HTML,
| but it also repurposes an element that actually does exist in
| HTML[2] for a completely different purpose. Of course, as to not
| conflict with that element, I now have to remember to type the L
| in uppercase, which is another aspect that doesn't carry over to
| HTML either.
|
| It seems the amount they're willing to reinvent is limited to
| JavaScript.
|
| [1] https://remix.run/docs/en/v1/tutorials/blog [2]
| https://developer.mozilla.org/en-US/docs/Web/HTML/Element/li...
| pier25 wrote:
| That's only if you want to take advantage of the hydration and
| client side routing.
|
| You can of course use regular <a> links and navigate to a new
| page every time.
| jscholes wrote:
| > That's only if you want to take advantage of the hydration
| and client side routing.
|
| I feel it would be doable for a framework to determine which
| links should be client-side routed versus not. Or, failing
| that (or in conjunction with it), provide a way for
| developers to indicate that information, without reinventing
| a cornerstone of the web and HTML mark-up from scratch.
| [deleted]
| brentm wrote:
| It would be really interesting to see what the conversion funnel
| looks like for a new framework like this.
| Scarbutt wrote:
| That's one condescending and manipulative article.
| dgb23 wrote:
| I agree. Their landing page is pretty cool. But I had to
| navigate deep into the docs to figure out what this is:
|
| A Nodejs and React based full stack framework with DSL magic.
| It does progressive enhancement is optimized for partial data
| fetching and UI updates.
| k__ wrote:
| It can be used independently from Node.js
| ithrow wrote:
| But looks like you do need to have v8 running somewhere for
| production?
| k__ wrote:
| It runs on Cloudflare Workers, so I don't think so.
| ithrow wrote:
| What do you think cloudflare workers are and what is
| parsing the JS? ;)
| bdcravens wrote:
| Not according to the package.json.
|
| https://github.com/remix-run/remix/blob/main/package.json
| k__ wrote:
| As far as I understood it, Node.js is needed for
| building, but the package runs on different JS
| environments.
| akmittal wrote:
| How so care to describe?
|
| Well i don't fully agree, you still have to learn react/JSX.
| But they still _use the platform_ lot more than most other
| solutions(next, react, angular)
| dmitriid wrote:
| > But they still use the platform lot more than most other
| solutions
|
| They use about the same amount.
| dmitriid wrote:
| > Learn Remix, Accidentally Learn the Web
|
| Th post links to tutorial, whose first line of actual code is:
| import { Link } from "remix"; <Link
| to="/posts">Posts</Link>
|
| 1. This is not the web
|
| 2. This is not transferrable knowledge
|
| I've skimmed through the tutorial and I fail to see anything in
| there that "actually teaches you web". It's a bunch or same old
| React, with same old React abstractions. Not that those
| abstractions are bad. They are just falling short of what Remix's
| heavy-handed marketing promises.
| jaredcwhite wrote:
| Imagine a web framework where you could write `<a href="/link-
| to-something">Something</a>` and It. Just. Works. _sky parting,
| rainbows, unicorns, choir of angels singing..._
| ziggus wrote:
| Not Another Advertisement Disguised As A Blog Post
| dimitrisnl wrote:
| Were you expecting productivity tips or something?
| akmittal wrote:
| What's wrong with advertising something which is actually
| great. Remix seems very promising and has much better
| performance than nextjs
| mmckelvy wrote:
| I haven't had a chance to check out Remix yet, but I've certainly
| been impressed with the creators' (Ryan Florence and Michael
| Jackson) work on React Router and their React Training series.
| They design very good, easy to learn, low surface area APIs. I
| suspect Remix will be more of the same.
|
| Regarding frameworks in general, the common lament is that it's
| all churn with no progress. In my experience this certainly
| hasn't been the case. It was much easier to work with jQuery than
| with the old web APIs, and it's light years easier to work with
| React than with jQuery or some of the older frameworks like
| Backbone and Ember. Each step built upon the previous one and
| unlocked a completely new set of capabilities.
| kayodelycaon wrote:
| "Not Another Framework" ... is another framework. And from the
| look of it, it's the javascript equivalent of Ruby's Sinatra or
| Python's Flask. It's cool, but I think it promises way too much.
|
| These frameworks aren't so much frameworks, as they are framework
| builders. For small projects, they get out of your way. For
| larger projects, their lack of defaults and structure slowly
| becomes their own undoing. Eventually you get a bad
| reimplementation of one framework or another with absolutely
| abysmal security.
|
| Case in point: every Sinatra site I've ended up dealing with has
| turned into a bad version of Rails. ( Hand-rolled authentication,
| unsafe session handling, no CSRF protection, buggy form
| validation...)
|
| A field of infinite possibilities seems like a great idea, but
| you quickly realize it's actually a sea of infinite decisions.
|
| Once abstraction became possible, the debate between framework or
| no framework started. And hasn't stopped. Nor do I think it ever
| will. :)
| commandlinefan wrote:
| > a bad reimplementation of one framework or another
|
| But worse, as far as I've ever been able to tell. I haven't
| done enough web front-end development to really have a strong
| opinion on front-end frameworks, but I have done a non-trivial
| amount of it. I did work with Javascript back when it was new
| and then followed the jQuery "revolution". While I observed
| that jQuery actually did eliminate a fair amount of code, I
| also observed that is also eliminated all of the
| troubleshooting techniques I'd worked out for Javascript
| development. I couldn't place breakpoints in firebug any more
| because all events were being handled by one massive "event
| handler" (and then re-dispatched to jQuery's own custom
| reimplementation of the event handler infrastructure that the
| browser already had built into it). I found Angular to be
| effectively the same. By then it was worse because Chrome's
| debugging tools were top notch for "vanilla" Javascript
| development - much better then firebug had ever dreamed of
| being, but mostly useless in Angular unless you were lucky
| enough that a problem included a stack trace into some code
| that you wrote. I've never used React, but skimming through the
| high-level docs, it looks like it's more of the "let's write a
| web browser in Javascript and run it in a browser but with
| inferior tooling". This remix thing looks like "let's rewrite
| React in React but with even more inferior tooling" (but I
| could be wrong, haven't actually given it a chance).
| LAC-Tech wrote:
| > For small projects, they get out of your way. For larger
| projects, their lack of defaults and structure slowly becomes
| their own undoing. Eventually you get a bad reimplementation of
| one framework or another with absolutely abysmal security.
|
| The vast majority of projects I've worked on have been small
| projects, using big project technology.
|
| Big frameworks (and here I'll speak more to enterprise react)
| make sense when you have at least one person it is whose
| fulltime job is be a sort of npm and tooling sysadmin. When you
| don't, and there's a small handful of you, it's heart-breaking
| when you all have to stop flying to perform arduous maintenance
| on your 747 you're ill-equipped to operate, instead of making
| progress in your cessna.
| kayodelycaon wrote:
| And someone pointed out Remix has React as a hard-dependency...
| I thought some of the documentation looked familiar.
|
| Talk about misleading:
|
| > When we design Remix APIs, this is something we think about.
| We want your experience with Remix to transfer to web
| development generally.
| ipnon wrote:
| It seems like the best way to conceptualize Remix is that it
| translates your JavaScript components into it's equivalent
| Web primitives, instead the equivalent JavaScript Webpack
| monster interlaced with the endless NPM dependencies we know
| and love. Wherever the browser has native support for some
| functionality, Remix uses it so that you don't reinvent the
| browser as a thin JavaScript layer over every one of your
| projects. The result is that you get the snappiness and
| simplicity of a Web1.0 website on the user end, but you can
| still develop your applications with the all the frontend
| advancements made in the last 15 years.
| OJFord wrote:
| > "Not Another Framework" ... is another framework.
|
| I don't think it's in denial about being a framework, it's
| meant as '[groan] not _another_ framework ' self-deprecation.
| (There's an exclamation mark in the original title that's
| stripped here.)
| mastazi wrote:
| I respectfully disagree with one of the points you made: in my
| experience, micro frameworks like Sinatra or Flask work best
| for large projects while the more full fledged ones like Rails
| or Django work best in small projects.
|
| The reason is that micro frameworks give you more flexibility
| and in large projects this is gold since you have to deal with
| so many requirements and multiple stakeholders. In large
| projects having to do more things "manually" is actually a good
| thing for this reason. It is likely that you have a large team
| so in terms of work required it's not going to impact you that
| much. You can still use libraries for the various things the
| framework lacks, e.g. it's not like you are writing
| authentication from scratch - you can use a library, but at
| least being modular gives you freedom to swap one library for
| another.
|
| On the other hand whenever I worked in small teams or solo I
| have been highly appreciative of frameworks like Django that
| have "batteries included" and let me get things done quickly
| and efficiently.
|
| It's true what you say "A field of infinite possibilities seems
| like a great idea, but you quickly realize it's actually a sea
| of infinite decisions." but this is more of a problem if you
| are working solo or in a small team, whereas if you have a
| large team you can put different minds onto different
| problems/features...
|
| (Edit: grammar)
| lhorie wrote:
| It can go both ways. At work, I periodically get in contact
| with an extremely large codebase that is actively worked on
| by multiple teams. One complaint I heard was that people
| doing willy-nilly things cause setbacks to efforts to make
| project-wide improvements. One example was that build times
| were very slow and there was an effort to implement
| incremental builds along some interface boundaries, but then
| teams would disrespect agreements to not violate constraints
| for that boundary (because immediate deadlines trump long
| term large efforts)
|
| A more accurate way of thinking about it, IMHO, is to look at
| how homogeneous the project is. A project can be very very
| large, but be entirely CRUD forms, and Rails could fit like a
| glove. But on the other hand, a project could have
| predominantly "curveball" features (maybe it simultaneously
| has a real time chat component, twilio integration,
| newsletter emails, periodic 3rd party data imports, print-to-
| pdf, etc).
| [deleted]
| jaredcwhite wrote:
| > So while you do need to learn a few React specific APIs, most
| of your code is just JavaScript. That's transferrable knowledge!
|
| Well that gets a big LOL from me. React goes out of its way to
| eliminate any awareness or interaction with real DOM APIs, and
| tends to abstract away all kinds of things that are actually
| straightforward using native JS APIs. Heck, we're only _just now_
| perhaps-maybe-hopefully getting true support for web components
| and they've been around for years.
|
| If you want to use a reactive view library that actually helps
| you learn about vanilla APIs, try Lit. Or drop down a level and
| check out Stimulus.
| lhorie wrote:
| [Disclaimer: I'm the author of mithril.js, another web framework]
|
| I've thought a lot about the idea of transferable knowledge, and
| my feelings on it have matured a bit over the years.
|
| The premise of the article is that web technologies are
| transferable knowledge because they underlie helper abstractions,
| and yes, you're much more likely to gain a higher appreciation of
| something like FormData if you look at the MDN docs than if you
| look at the axios docs. But also, that's kinda beside the point
| if the idiomatic way to do HTTP requests in React has a different
| API than in Angular.
|
| You could argue that despite the superficial API differences,
| what _is_ transferable is the understanding of the platform
| itself: what is CORS, what is CSRF, what are HTTP headers, what
| is idempotency in the context of HTTP, etc. Learning the standard
| Request API doesn 't necessarily teach any of that any more than
| learning axios' API. But knowing the platform lets you feel your
| way around new framework APIs.
|
| Another example: the naked history.pushState API is frankly
| horrendous to work with. Who wants to think about state machines
| and mess with scroll positions manually? Routers, on the other
| hand, are present in pretty much every self-respecting framework,
| and while their APIs don't always map 1:1 among themselves, the
| concept of declarative routing is transferable knowledge, because
| that's what every framework does. That's the "meta".
|
| So I think of transferable knowledge along two axes:
|
| - the first axis is how much can the framework get out of the way
| of learning the platform. Can I easily figure out what API
| translates to history.replaceState? Can I easily figure out which
| API maps to the `credentials` field for a CORS-enabled endpoint?
| Can I easily reason about CSRF tokens? Can I tell the framework
| to just take a hike and access the underlying API directly?
|
| - the second axis is how much the framework conforms to developer
| expectations. How much does a framework conform to the "meta" of
| declarative views and routers, state and error propagation, etc,
| and how much is gained or lost by breaking away from mainstream
| patterns.
|
| There's also something to be said about the emergence of
| emulation of transferable knowledge. The biggest example of this
| is Svelte, which looks a lot like "plain vanilla JS", but it
| achieves this via some non-trivial compilation, which sometimes
| leaves gaping abstraction holes like the `list = list` pattern.
| The transferable knowledge here for a more seasoned developer is
| not so much the basics of JS, but the understanding of how
| reactivity models are implemented. But this may or may not be the
| level of knowledge that is relevant for you.
| Chyzwar wrote:
| I will not touch remix with 10 foot pole. It is from react-router
| authors, it is only open source that bring my worst emotions.
| andrewl-hn wrote:
| Somehow I had an impression that web developers in general are
| aware of web APIs: stuff like fetch, DOM events, forms and URLs -
| all things this article lists.
|
| Modern React development doesn't deal with these things much not
| because devs don't learn web APIs but because most projects use
| various component libraries that abstract web APIs from devs. You
| as an app developer do a lot more work to glue components
| together to achieve the desired behavior and you mostly deal with
| data management.
|
| I don't say Remix is bad, it's an impressive piece of technology
| for building interactive UIs that tries to blend server side and
| browser side of web in a neat package, quite successfully I must
| say! It's very pleasant to work with, not hard to get into, and I
| personally haven't found any big drawbacks. I'd recommend it for
| all sorts of projects!
|
| But this whole "we do plain web APIs" marketing angle is IMO
| strange and misleading. Remix is a set of APIs on top of React,
| you will be building React apps with it, with JSX, hooks and
| everything else. It's NOT a vanilla web, far from it.
| dimitrisnl wrote:
| > most projects use various component libraries that abstract
| web APIs from devs
|
| You would be surprised
| simonw wrote:
| The impression I have is that many web developers who learned
| their trade in the past five years know how to build with React
| (or maybe another front-end framework) but don't know how to
| hook up a JavaScript-free form using GET or POST - or even know
| that it's possible and sometimes desirable to do that!
| andrewl-hn wrote:
| I suspect you're right. I organize conferences, and about 5
| years we ran into similar situations. A speaker would propose
| a talk and they would put an example that would assume the
| audience' familiarity with jQuery. We'd have to explain to
| the speaker that half of our audience started doing web
| development 2-3 years before, and there was a very high
| chance they started with React and never wrote or read any
| jQuery-based code. Many talk proposals would almost
| completely broke down because of that.
| futhey wrote:
| After hiring several great developers with <5 years
| experience, I am inclined to agree.
| getcrunk wrote:
| Followed the link, didn't know what remix was so clicked the logo
| up top. Took me to /blogs. Clicked again, took me to /
|
| Pretty cool!
| nomdep wrote:
| Not sure if you're been sarcastic or not
| bdcravens wrote:
| I'm going with yes, and would say it's well deserved.
| dimitrisnl wrote:
| Very interesting, hoping to see some real-world examples soon.
| aobdev wrote:
| I don't think anyone here is giving remix enough credit for what
| they're trying to do. In fact I've been a long time lurker and
| finally made an account today to share this opinion.
|
| My company is building a B2B ordering system. We take
| reservations and store fulfillment details with some email and
| SMS functionality bolted on to a web interface; at least for now
| it's a simple business CRUD app. We chose to use Vue for the
| frontend and Python REST APIs on the backend. And it has been
| thoroughly frustrating to just ship our MVP, because when I look
| into our frontend codebase, more than half of it is a bunch of
| API calls, state management, authentication, and error handling
| that honestly does not provide much value to the product that
| we're offering. I half wish that we had built this in Rails or
| Django.
|
| Except, we are geospatial-enabled and have a killer interactive
| map view that powers this whole thing. And it's not just a single
| asset-tracking view, but this map component is going to be
| embedded in several places across the app. And when you zoom,
| pan, or search the relevant data on screen is updated. I wouldn't
| dare try to build this in anything other than one of the big 3
| SPA frameworks today.
|
| Why do I have to choose between a traditional app with poor
| ergonomics for developing frontend JS, and a clunky SPA that
| reinvents everything the browser has gotten good at in the last
| 20 years? Remix is a hybrid and I think they are on to something
| really great here. I can write my server side models and
| controllers as in days of yore and pass them straight to a
| renderer that happens to be full blown React + React Router that
| does as many fancy interactive things on the frontend as I wish
| once the page is hydrated.
|
| I think it's easy for backend devs to discount how nice it is to
| use JSX across the stack if they're used to a templating language
| and writing JS sprinkles to manipulate the DOM. And it's easy for
| frontend devs to discount how much extra work it is to create an
| API when your team is only using it internally for a first-party
| app, because you need APIs for SPAs. But once you realize that
| you can eliminate these entire bodies of work (manipulating the
| DOM and writing an unnecessary API), you get the best of both
| worlds and everything about complicated web dev today feels so
| achievable.
|
| Even if it's early days yet, and Remix can't hold a candle to
| comprehensive frameworks like Rails, this is much more than just
| Sinatra or Flask written in JS. I'm seriously excited about where
| Remix is headed and I'm rooting for these guys all the way.
___________________________________________________________________
(page generated 2022-01-27 23:01 UTC)