Why is that? Especially since most of the new frameworks copy the ideas of existing frameworks.
P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s
Django and Sails.js both seemed like they were a step down in terms of general productivity, though each had a unique advantage of their own (admin out of the box, websockets & realtime features).
I haven’t had a chance to really give RedwoodJS a trial run, but it's the JS-based fullstack framework I'm most curious about.
Maybe my first update experience with Laravel was a bit of a mess (v4.2 to v5.0 "The recommended method of upgrading is to create a new Laravel 5.0 install and then to copy your 4.2 site's unique application files into the new application. This would include controllers, routes, Eloquent models, Artisan commands, assets, and other code specific to your application."), and I couldn't easily "see" the models' properties and the Facades, that's why I have shy-ed away from it a bit. I have worked with several Laravel applications since then and have gone through the v6 through v10 upgrade cycle and can say it's gotten easier (though I wish they could settle on a release schedule), but my preference is still Symfony.
Plus when I checked out Django, I felt a bit more "at home" (e.g. see Twig templating language and how they used Django templating language as inspiration).
I've worked with Vue.js and AngularJS 1 and Angular 2+, but I'm glad htmx is coming in strong, so I can focus on logic, speed and stability instead of glueing the frontend and backend API together and debugging in the different browsers.
Not sure if that's a plus or a minus, after all there might be devs whose preferred stacks differ by 1 or 2 items (e.g. prisma over drizzle, nextauth over something else) and they'd both benefit from having a standardized template to start with.
EDIT: just remembered I fell in love with Meteor for a while. Then they started shoving React and other external stuff into it to gain more market share and it inevitably lost that opinionanted nature that, IMO, made it so good. Choice isn't always a good thing for the end user (even, and sometimes especially, when that end user is a professional who just wants to get things done).
Express was the default with Node for some years but it was mostly used for APIs to feed front ends. These days lots of people have switched to Fastify but again mostly for APIs.
There's really nothing fullstack in the JS world that can be compared to Rails, Laravel, or Django.
Current fullstack solutions (Next, Nuxt, SvelteKit, etc) in JS are trying to kludge front end components into the server which IMO is a mistake. And I say this as someone who has been doing mostly front end since the 90s.
I would like to introduce you to Adonis. https://adonisjs.com
But still... There are no queues or jobs. No HTML over the wire. No colocation of presentation logic. Etc.
https://packages.adonisjs.com/?category=Rendering
And the fact that these aren't official is kind of the point I've been making. In the JS world there isn't a holistic fullstack framework. You have to stitch it all up yourself. In Adonis, Express, Fastify, Next, SvelteKit, etc.
Because most people are content with using Adonis' Edge templating with something like Alpine for sprinkling in interactivity, or using Vue.
> In the JS world there isn't a holistic fullstack framework.
This is true for all monolithic frameworks in every other language. Even Rails you have to use 3rd party addons for stuff. It's not feasible to build everything in for every possible use case, so they make it easy to add on stuff.
I think now you're just starting to move the goalposts.
I'm not talking about adding client-side interactivity though. Read my comments again.
> I think now you're just starting to move the goalposts.
I think you're not really reading my comments.
Obviously no solution will solve everything 100%. That's not even an argument.
I think you make a good point here, JS is uniquely able to be executed both frontend and backend, hence things such as underscore templates.
Other languages don't have that ability. Therefore I would agree that there is no point in making a 1to1 copy of existing MVC ideas.
Being an ex-rubyist and now doing a lot of NodeJS, I really enjoy moving server code to the client at zero mental cost since it's mostly the same APIs
Trying to use client patterns to solve the server has been mostly a mistake. OTOH separating server and client and using an API to glue has produced a lot of issues too (SPAs, etc).
I think the future is a hybrid model where 80-90% of the front end is orchestrated from the server (LiveWire, Hotwire, LiveViews, etc) and 10-20% is a pure client side solution.
why?
Flask is almost completely freeform in what it allows you to do, it just has a few style recommendations and a ton of community convention, but you could technically ignore 90% of it since Flask doesn't really expect any sort of structure.
Django is to Rails as Flask is to Sinatra, imo.
Moreover, JS really encouraged the use of API driven development + React, at a time when that trend was in general growing. I bet this impacted the ORM development space, as I suspect FE style devs were perhaps more demanding of an ORM while more backend oriented devs were perhaps fine writing SQL. With other frameworks I find the coupling of ORM and template views to be slightly more natural. Maybe this is just me inventing story lines but its how it feels. I think the lack of a quality ORM _really_ hurt the most.
Lastly there was a growing trend towards micro dependencies and assembling from parts, and I think it promised more than it could deliver. I think if Node had shipped a higher quality standard lib, perhaps akin to Go or (maybe) how Deno is trying to do, the story might have looked much different.
This is my take as a consumer, rather than creator / maintainer of these frameworks, so not sure how accurate this is. Just my viewpoint with my dev career growing alongside the early emergence of Node.
https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...
https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...
Next.js is using React, it's a piece of the fullstack framework, like Rails and erb. React is the primary fullstack JS templating system, that's even more featureful as it's a better client side JS interop story than html templates.
By the stackoverflow graph, it's clear that most complex projects have moved onto frontend frameworks like React, instead of templated html, which standard Django is using. Django used in conjunction with a frontend framework, is most often through Django Rest Framework, which fares much less popular on stackoverflow trends:
https://insights.stackoverflow.com/trends?tags=next.js%2Crub...