In my experience, front-end development is a battle of competing standards and compatibility across platforms. Remember developing for IE 6? I do. “I’ve seen some things, man…” [eye twitches]
Browsers are good at rendering HTML, and servers are good at generating HTML; doing things client-side—while often necessary—was tedious and brittle at best.
Things are arguably better now, but client-side still comes with a cost. Fully embracing modern JS (in the form of a static single-page app) usually means rejecting the traditional paradigm.
Given the complexities of modern development in general, it still seems silly to move everything client-side just for the hell of it when there are well-established standards and patterns to build on.
“You can’t build a lot of apps without modern JS.” That’s true, but there are many types of apps, and in my experience, good development is all about managing complexity.
“Single-page apps perform better than traditional web apps.” OK, but at what cost?
When I look at the tooling that is necessary to reap all the benefits of “modern JS”, I really begin to wonder why you would subject yourself to that if you’re not building a Slack or a Notion.
The DHH/Basecamp/Rails full-stack approach still makes sense for a lot of people. Laravel and Phoenix are great too. As a small team, skipping hype cycles and shipping is one of the best things we’ve done at Honeybadger.
What about devs who haven’t spent 20+ years battling JS in the browser? To them, JS has always been cross-platform, it’s always been in a state of constant improvement, and “everyone does it this way.”
The simplest solution is usually best, and if everyone’s first and only choice is to build a “modern JS” app, we’re all maintaining a lot of needless complexity. Use modern JS; just do the math first, and use what you can afford.
Don’t let modern be the enemy of good. The End. </👴>