"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.<p>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.<p>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...)<p>A field of infinite possibilities seems like a great idea, but you quickly realize it's actually a sea of infinite decisions.<p>Once abstraction became possible, the debate between framework or no framework started. And hasn't stopped. Nor do I think it ever will. :)
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.
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.<p>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.<p>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!<p>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.
> Learn Remix, Accidentally Learn the Web<p>Th post links to tutorial, whose first line of actual code is:<p><pre><code> import { Link } from "remix";
<Link to="/posts">Posts</Link>
</code></pre>
1. This is not the web<p>2. This is not transferrable knowledge<p>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.
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.<p>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.
This page talks a lot about knowledge that is transferable, e.g.:<p>> We want your experience with Remix to transfer to web development generally.<p>But then, you opened the quickstart tutorial[1], and the first bit of mark-up is:<p><pre><code> <Link to="/posts">Posts</Link>
</code></pre>
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.<p>It seems the amount they're willing to reinvent is limited to JavaScript.<p>[1] <a href="https://remix.run/docs/en/v1/tutorials/blog" rel="nofollow">https://remix.run/docs/en/v1/tutorials/blog</a>
[2] <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/HTML/Element/li...</a>
> So while you do need to learn a few React specific APIs, most of your code is just JavaScript. That's transferrable knowledge!<p>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.<p>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.
> The worst part is feeling like all the deep knowledge I have with my current tools is now obsolete, and I'm a beginner all over again<p>The worst part is that there are millions of github projects that are abandoned, obsolete, uncompilable, unworkable, broken etc. Meanwhile you can still find every kind of widget in jqueryscript.net and it works! Seriously, screw more frameworks, javascript programming is fundamentally broken and no amount of frameworking or godawful constructs will fix that basic fact. After dabbling a bit with 'modern' javascript i m convinced there's a mass epidemic of masochism in the community.<p>And in the meanwhile browser development is progressing at snail-pace. It's 2022 and we still have to deal with unfinished implementations of ubercomplex things like webrtc.
Remix is looking super cool. A breath of fresh air really in the JS ecosystem.<p>Rich Harris (creator of Svelte) has actually been introducing new features to SvelteKit inspired by Remix.<p><a href="https://github.com/sveltejs/kit/issues/3533" rel="nofollow">https://github.com/sveltejs/kit/issues/3533</a><p><a href="https://github.com/sveltejs/kit/issues/3532" rel="nofollow">https://github.com/sveltejs/kit/issues/3532</a><p>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.<p>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).
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.<p>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.<p>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.<p>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.<p>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.<p>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.
[Disclaimer: I'm the author of mithril.js, another web framework]<p>I've thought a lot about the idea of transferable knowledge, and my feelings on it have matured a bit over the years.<p>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.<p>You could argue that despite the superficial API differences, what <i>is</i> 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.<p>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".<p>So I think of transferable knowledge along two axes:<p>- 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?<p>- 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.<p>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.
Unfortunately Remix is just another framework! It brings nothing new/better than common React/Vue/Angular...<p>It will soon fade away into the funnel of the web development history; just like its many other brothers before/after it.