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