11–20 of 87 posts
https://changelog.com/news/web-developments-lost-decade-LWao
> Amal sits down for a one-on-one with Alex Russell, Microsoft Partner on the Edge team, and former Web Standards Tech Lead for Chrome, whose recent post, The Market for Lemons, stirred up a BIG conversation in the web development community.
> Have we really lost a decade in potential progress? What happened? Where do we go from here?
I really just want to write business logic, wire that up to endpoints in a nice DSL, and move on.
Most web frameworks seem to be obsessed with the web platform to the point they feel more like glorified macros, leaking its web gunk everywhere.
"Concatenates text and fires it off to the browser in a straightforward and predictable way." What ? It's in 2023, you don't want to concanate text ?
I dislike frameworks for the same reason most of their proponents like frameworks, you can not expect to out-compete all the smart people working together on a common goal. Frameworks are bad at cultivating off-colour ideas, they tend to have a well curated API but are often stuck with a singular architecture. Sometimes the solution is to be found in some lateral dimension. One such example is PostREST, it does away…
And then you get yelled at if you try to improve on it, because it is a best practice. :)
I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million years with Rails than five minutes with most of the React SPA monstrosities I've had to work with recently.
I get it: if you want to build a super-complicated, dynamic front-end, there's only so much you can do with the classic Rails-style approach (server-side rendering of HTML templates with some vanilla Javascript, or perhaps jQuery, sprinkled on top). Once you get past a certain level of complexity I can understand the argument for having totally separate "frontend" and "backend" applications where the frontend is built with something like React and the latter renders nothing more than a JSON API.
But why, why, why has the entire industry seemingly decided that the latter, complex approach is the default, perhaps even the only, way to build a web application? The last four companies I've worked for all used the "separate FE/BE" approach for every app, and at all four companies it was a terrible, unnecessary choice that added exponential amounts of complexity and slowed development to a crawl for no discernible benefit. Time and time again I'd get frustrated because the most simple, basic features would take ridiculously long to finish, be a nightmare to test, and be full of infuriating little subtleties and footguns that made the implementation fragile as an eggshell. Even something as simple as adding a would take ten times longer than I knew it would have taken me in Phoenix or Rails.
And yet when I try to explain that I don't think we need the "separate FE/BE" approach for the task at hand, people look at me like I've suggested we don't need electricity. It's all they've ever known and they can't imagine there might be a better way, or at least one that isn't so agonisingly, pointlessly complex. What's happened to the industry? Why has web development become like this?
Rails is probably the best framework still. But it still feels too low-level. I don’t want to care about the mountains of Web gunk there are: JSON serialization, HTTP methods, cookies, etc. Lack of static typing really hurts the maintenance story, too. I really just want to write business logic, wire that up to endpoints in a nice DSL, and move on. Most web frameworks seem to be obsessed with the web platform to the…
Rails is probably the best framework still. But it still feels too low-level. I don’t want to care about the mountains of Web gunk there are: JSON serialization, HTTP methods, cookies, etc. Lack of static typing really hurts the maintenance story, too. I really just want to write business logic, wire that up to endpoints in a nice DSL, and move on. Most web frameworks seem to be obsessed with the web platform to the…
Btw, use Sorbet for Ruby static typing. It's very ergonomic.
Rails is probably the best framework still. But it still feels too low-level. I don’t want to care about the mountains of Web gunk there are: JSON serialization, HTTP methods, cookies, etc. Lack of static typing really hurts the maintenance story, too. I really just want to write business logic, wire that up to endpoints in a nice DSL, and move on. Most web frameworks seem to be obsessed with the web platform to the…
This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million ye…
a good place to start is to ask how the boss became the boss, given that the boss quality inevitably degrades to Dilbert
This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million ye…
Managing any (Literally any) client-side state is also easier with a framework. I'd rather use Preact than write vanilla JS for basic state management.