Not Another Framework | Hacker News Reader

Not Another Framework

remix.run

70 pointspspeter383 comments

"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. :)

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.

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.

> it translates your JavaScript components into it's equivalent Web primitives

It doesn't. Or, rather, it does nothing different than React.

> instead the equivalent JavaScript Webpack monster interlaced with the endless NPM dependencies we know and love.

Yup. Because Remix translates those components by pure magic, with no dependencies

   > npx create-remix@latest
   > cd node_modules
   > ls -l | wc
   379

Oh look. 379 dependencies before we even wrote a single line of code

> 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.

Remix's own docs show this is not true. It adds additional abstractions everywhere, and "uses underlying browser functionality" literally to the same extent as everybody else.

Example, fetching data:

  Remix polyfills the fetch API on your server
  so it's very easy to fetch data from existing
  JSON APIs.

  Instead of managing state, errors, race conditions,
  and more yourself, you can do the fetch from your
  loader (on the server) and let Remix handle the rest.

   Remix optimizes the user experiences by only 
   loading the data for the parts of the page 
   that are changing on navigation.

So it creates a polyfill, and adds layers of abstraction to make it work. You can say, "it's because it's not in the browser, but on the server". Yes, exactly, Remix doesn't even have documentation on how to use all that goodness on the client. Instead, it creates a huge, complex, and undoubtedly brittle tower of abstractions to make all that work on the server.

> 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).

> 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.

> "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.)

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 have to build authentication from scratch, 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)

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).

> A more accurate way of thinking about it, IMHO, is to look at how homogeneous the project is.

This is a very good point. I tend to take as a given the a highly homogeneous project is always a smaller/simpler one, and that a heterogenous one is always a large project with a large team... but thinking about it, this is not true at all, in fact I can think about some very large projects that don't do many different things, and I can think about some smaller projects I've worked on that are a bit of a Swiss Army knife.

> real time chat component, twilio integration, newsletter emails, periodic 3rd party data imports, print-to-pdf, etc).

All of these things are pretty easy to do with Rails and Laravel. I don't see how Flask or express or the home made framework on top of those could make anything of this easier. Other than writing the code yourself and not needing to read documentation (which will be a problem for future maintainers) I don't see any advantage for anyone except the one writing it for the fun of it.

> 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

Not my experience at all. The "new requirements" you mention are always about business, not technical. Frameworks like Rails, Django and Laravel solve a pretty good bunch of the technical challenges which, in my experience, are common to the 90% of everything we build in most web based companies.

I've seen this argument of let's use flask/sinatra/express/fastapi because I need the flexibility/it is just a simple service too many times. And every single one ended up in a frankestein mix and match of 10s of other libraries that some developer ( now gone, of course) decided at the time was the best thing in the world until he got bored.

Also, you're not forced to use everything in these frameworks. If you think your application just needs routing, you can also use them and call it a day. If it happens 3 years down the line that you need an ORM, then you have it right there waiting for you.

> are common to the 90% of everything we build in most web based companies.

Imagine that you had to build something where you need to use 90 nails and 10 screws: it's not a good idea to do the job with just a hammer, you should probably have a screwdriver as well.

Fortunately I'm in the web development business and not in the construction one.

Based on what you said in your previous comments I thought you were interested in magic :-p

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.

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.

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?'

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. :)

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.

Rails is... ;) (7.0 was released last month)

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).

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.

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?

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.

Browser sandboxing currently seems to work, users vaugely have a sense of how to avoid hacking on the web. A new protocol would have a lot of catching up to do, and would probably just be... a modified browser, because browsers are amazing at GUI stuff.

Browsers as OSes work fine, aside from the fact that all the advanced features aren't real standards, and everyone other than Google tries to kill them, so you can never be sure what's going to get deprecated later.

Browser makers do not want you to do this. Or at the very least, not enough to want to help you.

Plugins are no longer a thing except for the mostly useless extensions that are only a few steps above a bookmarklet.

As far as I'm concerned,HTML is the best thing we have ever had to represent basically anything that goes on a screen, but HTTP isn't great for some use cases, mostly because of TLS.

Beaker Browser is making a good effort, but I don't really consider any web technology usable till it has mobile support, and I don't like Hypercore's use of append only logs instead of being truly mutable-first.

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.

> most projects use various component libraries that abstract web APIs from devs

You would be surprised

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!

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.

Seems like an approach like that contributes to the problem. Instead of rejecting the talks, it seems fitting to make sure the talk includes a five-minute quickstart about how jQuery works if the audience is not familiar with it, rather than rejecting it outright.

After hiring several great developers with <5 years experience, I am inclined to agree.

> 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.

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…

We had that already! In the 1990s!

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.

> 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.

Isn't React Router one of the projects that are famous for completely changing their API for every single version they've released (basically)? Sure, they got a lot of training to perfect designing APIs I guess, but at one point you get frustrated of the constant churn, and the authors neglect of stability.

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...

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.

> 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.

I agree with your point.

I dont know what it is about some devs aversion for HTML.

But a anchor with a data attribute should more than suffice rather than creating over-engineered abstractions.

But then again, not many devs even read the HTML docs.

That's probably what they would have done if starting from scratch, but Remix is built on top of React Router which is a 7-8 year old project with its own idioms.

Also, Remix is for React developers. It's expected you will use JSX, components, etc.

Personally I have a toy client-side router for Svelte. Links that need to trigger client-side navigation simply use a Svelte action:

https://github.com/PierBover/roots-svelte-router

> I feel it would be doable for a framework to determine which links should be client-side routed versus not

I think that is worse. Replacing a core html element behind the scenes to do a `history.pushState` is like to monkey patching. This way you can still use <a> elements and everything will work just fine, or you can very deliberately use a <Link> element if you want the extra functionality it provides.

Same as with the <form> element which will work just fine in Remix as if it was a 2005 PHP project. Or you can use Remix‘s <Form> component which does all the "AJAX" magic behind the scenes that you'll spend two weeks adding to your 2005 PHP project.

> 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.

> helps you learn about vanilla APIs, try Lit

Ah yes. The library that has its own string-based DSL surely "helps you learn about vanilla APIs"

> 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

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.

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.

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.

Why?

Every new release was like "we broke backwards compatibility but we got it right this time", rinse and repeat

The upgrade docs for the latest release is like War and Peace.

For a frigging router. With lots of things like "we renamed this or that option or component for literally no reason"

What do you mean for no reason? The authors run a consulting shop and give trainings on this library. They are clearly incentivized to break things regularly.

Same. Got burned so badly by it. And I'm pretty sure same thing will happen with this framework.

Can see how 1 year from now it is a totally different thing impossible to update without rewriting everything because they've got a new idea.

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!

Not sure if you’re been sarcastic or not

I'm going with yes, and would say it's well deserved.

In general you want navigation to remain the same no matter where you are. Clicking the same button twice takes you to a different place compared to if you press it once? That breaks the user expectation.

More fitting would have been to have two elements next to each other, one "Remix" that takes you to the landing page, and one "Blog" that takes you to the index of the blog.

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).

> A lot of people in this thread are having weird opinions because they don't really understand the context of Remix.

Because Remix goes out if the way to never describe what it actually does.

> The point of Remix is that it facilitates SSR + hydration + progressive enhancement full stack dev in the most efficient way possible regarding DX.

See, if this was written on Remix's website, or in the blog post we're discussing, there would be significantly fewer people "missing the point".

I'm so immersed in this stuff it seems obvious to me (and probably the creators of React) but you're absolutely right.

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.

> I don’t think anyone here is giving remix enough credit for what they’re trying to do.

We would give it credit if Remix actually told us what they are trying to do. Instead we see very heavy-hanvded marketing claiming nothing short of a revolution and failing.

> 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

Authentication and error handling are deal breakers, hence very valuable for any paid product.

API calls and state management can be offloaded via libraries. However, they too are essential part of App. Just because they are not sexy or in business domain does not mean that they do not add any value

> Why do I have to choose between a traditional app with poor ergonomics for developing frontend JS

You don't. The same JavaScript is not 20 year's ago JavaScript, PHP is not 20 year's ago PHP, etc, etc.

Not doing an SPA doesn't mean form POSTs for a like button reloading the whole page or doing jQuery spaghetti. MVC and server side templates rendering has come a long way too.

Some technologies that would make your reservation system trivial to implement with this approach:

- Hotwire (Rails). See https://hotwired.dev/.

- Livewire (Laravel). See https://tallstack.dev/.

- Unpoly (fw agnostic). See https://unpoly.com/

and there are many others.

The caveat here is that you need an open minded engineering team that are happy with using programming languages as tools to build something and not js/python/elixir fanatics which can't touch anything which is not js/python/elixir/etc.

That's one condescending and manipulative article.

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.

It can be used independently from Node.js

But looks like you do need to have v8 running somewhere for production?

It runs on Cloudflare Workers, so I don't think so.

What do you think cloudflare workers are and what is parsing the JS? ;)

I could swear your comment said Node.js instead of V8 when I answered.

Not according to the package.json.

https://github.com/remix-run/remix/blob/main/package.json

As far as I understood it, Node.js is needed for building, but the package runs on different JS environments.

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)

> But they still use the platform lot more than most other solutions

They use about the same amount.

[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.

Not Another Advertisement Disguised As A Blog Post

Were you expecting productivity tips or something?

What's wrong with advertising something which is actually great. Remix seems very promising and has much better performance than nextjs

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.

Sorry yes, it's yet another framework. This one happens to have more marketing than others.

It would be really interesting to see what the conversion funnel looks like for a new framework like this.

Very interesting, hoping to see some real-world examples soon.

Reply on news.ycombinator.com