I avoided web programming for many years. Not just because of the observed churn, but because of the multiple concurrent stacks you have to juggle between. Do I solve this part in CSS, html, JS, or on the back side? What’s the state of the browser engine? And it’s rarely just choosing just one of the stacks with its different syntax and models, it’s usually some proportionate mix of at least two.
But of late I’ve been learning Elixir LiveView. It doesn’t make all of that go away completely, but it’s a perceived improvement from my place of observance.
As someone who recently reviewed a codebase that was refactored to Next - I think there are a ton of footguns that people don’t really think about. I think many people think they can just turn on server side rendering and get “fast” apps.
For example, by moving all of your front ends service calls to the backend you basically bottleneck your initial page load in waiting for those calls to resolve. Time to first paint can absolutely tank, and this is a pretty important perceived performance metric that impacts interactivity.
I’ve also found that developers who moved to Next don’t really have a clear understanding of how to handle application state management on the front end now that redux has fallen out of style. Excessive service calls (requesting data you’ve already fetched in other components) has ballooned to levels I’ve never seen before. And because all of these calls are happening on the backend, it’s not obvious to developers when they are making excessive calls because they can’t see the requests in the network tab of any modern browser.
So now they need to start thinking about a cache because the performance feels so much worse. Luckily Vercel can sell you this service - this adds another layer of complexity, but it solves their problem and they proclaim that Next is some hyper performant framework.
Now I know there are very efficient ways to do server side rendering, and properly using the new server components in Next and managing state… but the paradigm is so much different that I think many developers miss that step and actually degrade the performance of their applications when trying to migrate to this new framework of server side rendering.
I might be old fashioned but I do think this “new” server side rendering approach adds a lot of complexity for not a whole lot of gain, but I am still excited to learn more about Next and understand the best practices when using this style of app.
I wonder why the author did not mention PHP wgen he writes about the cool kids choosing the old technology. For me this is obvious: get a ultra cheap webhosting throw your PHP, HTML and frontend JS on and forget about server maintenance
Maybe an off-topic rant but I ran into a similar feeling when wanting to do a personal PHP project with Laravel.
Even with the backend set, the front still felt like it had to make a choice among Blade, Livewire, Vue and React glued together with Inertia (?). Then you had to pick between several different authentication systems. Unfortunately I wanted app support as well which would require React Native, Flutter or something else which the Laravel documentation doesn't seem to make any mention about.
Naturally one could make it all from scratch with vanilla PHP and JS but that's often not a suitable comparison to a full-fledge framework.
Laravel has become highly commercialized, having raised $57 million in VC funding last year. While it remains an open-source framework, it has evolved into a full-fledged ecosystem with official services like Forge, Vapor, and starter kits (Breeze, Jetstream) that streamline development and deployment. These tools are optional, but Laravel is making it harder to install a barebones version through Composer, subtly pushing developers toward its ecosystem.
Laravel is no longer just a PHP framework; it now resembles Java Spring — an opinionated, enterprise-friendly ecosystem where everything can be connected through configuration. The focus has shifted towards businesses and teams rather than personal or hobbyist projects.
For those who prefer a more traditional framework with long-term stability and fewer commercial dependencies, Symfony remains a solid alternative.
I mentioned Ruby and Python in this vein, but PHP with Laravel would count in my book too. That said, PHP may be nearing the stage Java has gotten to, where it’s well-understood but is perceived as outdated enough that it causes hiring and retention friction.
AFAIK there's no JS framework that solved the whole thing and doesn't depend on other packages.
I don't know why JS devs historically have an aversion to frameworks. Maybe the author of the article is right and this is caused by preventing heavy bloated JS apps in the browser.
In any case, after 10 years of Node in the backend, I'm done with it.
I've found the vast majority of my issues with JavaScript is the modern tooling itself. I really like the new language improvements over the ES5 e.g. not having to worry about scope/hoisting issues, async/await, fetch is much simple to what came before.
The tooling on the other hand is often a Rube Goldberg machine transpilers, compilers etc. Some of the information is documented, some of it isn't and it can be a massive time sink to get everything working together and have your IDE / Editor correctly configured.
TypeScript can be nice, but I run into rough areas where you are actively fighting the type system.
Favorite boring tech of late is ASP.NET w/ Blazor server-side rendering. .NET Core runtime has great performance, really nice DX, EF Core is arguably up there with ActiveRecord for persistence frameworks, and everything seems to hold together quite well. I really appreciate that the designers of ASP.NET have zero qualms just copying things they like from other frameworks wholesale. You have the pervasive DI that Spring has, Rails-style convention over configuration, and Blazor components are very similar to JS components. Auth is a first-party module that is reasonable to integrate.
The farther away I get from the JS ecosystem, the more fun webdev becomes for me.
I have very similar experience to yours (though I have yet to checkout Blazor, see my other comment in this thread).
I also read CSS in Depth book by Keith Grant recently based on someone's recommendation on HN. After struggling with CSS for over a decade, it all finally makes sense now. I can layout a page exactly how I have it in mind. Webdev can be so much fun and productive with server side rendering, beautiful CSS and some sprinkling of JS where required.
Yeah I'm also moving over from Node into dotnet. The DX has been very nice with VSCode and EF Core is really one of the best ORMs in the market. Also the performance is fantastic.
For APIs I'm using FastEndpoints [1] and loving it. I'll probably end up switching to Minimal APIs once they have validation etc.
I made atleast 3 web apps for personal use (hosted on my home server, accessible only within the local network) in Asp.Net (on linux) and I can say it is the best development experience I have had in a while. It is as boring as it gets, batteries included, performant and excellent docs. Can be very stripped down setup using Minimal APIs for simple cases, but can support more complex requirements using Razor pages or MVC.
I very strongly believe it's only Microsoft's reputation that is hindering it's adoption outside enterprise settings (and very deservedly so).
> Suddenly, sharing libraries and UI components between server and client went from science experiment to mainstream. You could have apps that were mostly server-rendered, but then that same code could instantly update the UI at runtime in the browser. Or apps that were mostly client-rendered, but later moved piecemeal to the server to improve performance. The holy grail of a unified codebase is now possible.
Remember Meteor[0]?
> ...but sometimes people ask, “What do you even need client-side rendering for nowadays?” I think it matters most for products where folks are actively getting work done, where you want things like optimistic updates, offline mode, rapid workflows, realtime collaboration, and lovely little animations that warm your users’ hearts
The reality is that SPA is mostly a bane for the first three, unnecessary for the last one, and there's rarely need for realtime collaboration apart from a few specific workflow. Today the recommendation is to start as a monolith first, I'd love for people to start with server-rendered UI first. Not loading several libraries just to reimplement (badly) already existing browser features. It's disheartening when you see simple blog can't even show text without javascript.
The deeper I get into my career, the harder my bad decisions have bit me later.
For JS-in-the-browser at least, I feel like it’s less about which framework/paradigm you pick today, but more about how your choices will limit your options in the future. If you could predict the future, you’d just choose the framework with the longest maintained life, but you can’t, so just focus on maximizing abstractions in the framework built on the slow-changing parts of the web (HTML/CSS, browser APIs) and try to consider how it would integrate as the “legacy” application you’ll be bemoaning only 5-7 years from now.
Some of the most successful companies I’ve heard about have legacy applications. Aiming to make the perfect choice for all future problems up front seems like the wrong choice IF it prevents you from changing your choice without tearing everything down first.
It is super productive. It will scale for 99% of the apps. There are common gotchas that hurt your performance, mostly related to ActiveRecord/DB layers. Like neglecting n+1's or not making sure indexes for actual query paths are in place. You can offload most of overhead to background jobs, caching, etc. You can also throw more money to scale backend servers but it's not the cheapest stack out there.
Also, sorbet/tapioca are great tools for static typing. Admittedly, there's some work to get the proper setup. They have limitations too (don't expect TypeScript levels), but it's worth it. I found a few sneaky bugs that were in the open for years, just by typing one large-ish model (despite it being tested thoroughly).
For anything without really heavy client-side interactivity then Django is my default recommendation. The currently-trendy tools feel like an order of magnitude productivity penalty if what you're doing can be done within one of the mature frameworks.
It is speedy, but you need to convert to the rails way. They have solved a lot of implementation problems related to crud applications and you can get a working application easily if your database and your UI is only separate by a few business logic rules.
Employment wise I would be a little cautious. At least in 21-22, there was still a pretty big pool of rails devs from the 2010s, open positions seemed to prioritize YoE with Rails much more than other openings.
It's nice that .NET has kept the number of web frameworks somewhat limited. They had the unfortunate ASP.NET Web Forms, than course corrected to ASP.NET MVC (which was solid but had too many API variations during the .NET core era), and now offer the really slick Blazor framework that lets you use C# on both the server and client... I hope it gains more industry momentum and Microsoft keeps investing in it.
JavaScript has plenty of stand alone ORMs like Drizzle, TypeORM, sql builders like Knex, there’s tons with a bit of googling.
I think that ActiveRecord is actually the weakest part of Rails, and the scariest and most difficult to manage code in a large rails app is models and stuff that is doing lots of active record stuff.
Rails can’t be reduced the goodness is that it’s more than the sum of its parts to get everything together, as DHH says, omakase. It’s not needing to build a framework before you can build your idea. It’s having such a solid and complete base that add-on packages can extend knowing they have a solid foundation. It’s being dominant enough in the language that most things try hard to work well with you.
Outside of React, I don’t think there’s any package in JS that comes close to have the gravitational pull that Rails has in Ruby.
I'm not actually a fan of ActiveRecord, i kind of detest it actually. But it's the beating heart of rails. The ORM aspect is almost a distraction from its primary benefit, defining a globally referencable model with lifecycle hooks and monkey-patching. Basically everything else falls apart without the model to leverage to rapidly produce code. The add-on packages you reference work so well because there are so many ways to hook into activerecord (and to a lesser extent, routing etc).
Like, the typical path is: 1) add gem, 2) code gen, 3) run migration, 4) you now have third party code managing a subset of your model. Crazy powerful pattern. applies to everything from auth to sending emails to async task workers to writing audit logs.
> RedwoodJS seems like the best attempt at a Rails in JavaScript these days, worth a look.
It's telling to me that Redwood/Adonis haven't really seen huge uptake. I feel like the JS ecosystem moves pretty slowly on a conceptual level overall. Backend dev is still heavily associated with express.js when that's seen as a minimal framework in other ecosystems.
I know im rephrasing the post, but nestjs (plus/or fastify) for bigger backends is our go-to right now. Its like an opinionated express and has been my motivator for working through work
coming from express, I just took a look at the nestjs docs and I'm confused as to how this is supposed to be motivating to learn. Being 'opiniated' is not a positive, I dont want to memorize a new 'nestjs way of doing things' when express is just intuitive. javascripts problem is that its Dunning-Kruger'd wannabe devs who think they know of a better way to do things and just start littering. Thats what framework spam essentially is, throwing around trash because you can.
> Until recently, though, there has been an impedance mismatch between your application code that does the initial render on the server, and any separate-but-tightly-coupled logic that renders further interactions and updates in the browser.
Of course, like all sensible users I absolutely despise JavaScript and can’t stand when web devs decide to burn my battery for no reason. But, I wonder if we’re anywhere near pushing through at this point? Perhaps a framework could be invented that detects that the user has disabled JavaScript, and actually do all the JavaScript rendering server-side?
I guess at that point web devs could script to their hearts content and their employers will bear the cost power cost of dynamically generating a bunch of stuff. (Hopefully the incentive change there will cause them to be more prudent, but if not I guess I don’t really care that much).
The rapid evolution of JavaScript frameworks is both a blessing and a curse. While innovations like React Server Components promise improved performance, they also introduce complexities that can be overwhelming. How can developers balance the need to stay current with the risk of 'JavaScript fatigue'?
I just feel zero need to stay current. New frameworks may well be better, but incrementally, not radically. I stay "current" by keeping an eye on HN, and when a name becomes so familiar that it seems entrenched, I'll give it a try on my next greenfield project.
Not everyone can work like that; it's a side effect of the domain I work in. But I chose that in part because I'd rather get work done than chase new things.
I do the same, stay current by hanging out on HN. When a stack or concept appears to become mainstream or important for my career I’ll do a small personal project with it. I don’t try to become an expert I just want enough exposure that, if I had to, I could become productive in short order. I consider it employment insurance.
But of late I’ve been learning Elixir LiveView. It doesn’t make all of that go away completely, but it’s a perceived improvement from my place of observance.