The interesting thing with web technologies is that the web, by default, meets many of the major requirements of modern development. Plain content in HTML is mobile-friendly, responsive, and accessible. Any web development system that harms these things is unacceptable.
On a related issue, I can’t stand the popularity of client-side rendering. The logic goes that it allows for faster-seeming apps, and that user’s machines can handle it, but that is completely at odds with the rise of mobile.
Web development today feels like a lot of people needlessly reinventing the wheel. Server side rendering (or even hybrid, I guess) works just fine. And we can work on the performance issues. We don’t need these bulky and slow frameworks that mess up basic things like separation of concerns.
Basically, stop screwing up the web. It was working fine before.
We don’t need these bulky and slow frameworks
This actually depends on your use case. I certainly believe that you don’t need this sort of framework. But I do need something like Angular or Ember for much of my work.
The main area in which Angular is slow is the initial render. Once you’ve gotten past that cost, things can be very snappy indeed. It doesn’t make sense for most public-facing websites. But if you’ve got a highly interactive web app behind a login, you can actually preload the application logic and templates while the user types in their credentials, eliminating most of that cost.
that mess up basic things like separation of concerns.
There are different ways of separating concerns that make sense under different circumstances. Angular rejects the “traditional” web model because it isn’t a great fit for client-side applications. There may be better ways to do it, but the Angular way isn’t unreasonable.
Yeah. I understand that there are use cases for these sorts of things. But (as is often the case with the hot new thing) they are used widely and without reason. I don’t doubt there are organizations for whom these frameworks are actually the right choice, but I highly doubt that those represent anywhere close to the majority of the actual users.
It really wasn’t. Nor will it. Processing, ram, storage, these things tend to increase at an exponential rate along t. Actually available mobile bandwidth does not. And there’s nothing you can do about C, so there’s always going to be lag waiting for server responses.
I’m not sure what you’re saying. My point was that pushing rendering to client side is at odds with a goal of a friendly mobile experience. It assumes a certain amount of bandwidth, and more importantly eats up limited data for users.
Pushing rendering on the client also consumes more of the client’s energy (battery). I occasionally run across some JS laden sites that peg cpu cores doing things like.. scrolling!
I loved, and still love, writing websites with Wicket, doing all the rendering on the server side. You can dynamically update part of the page when the user clicks a button - but that happens via an ajax roundtrip. It’s the nicest framework I’ve ever worked with.
But it’s not at all mobile-suitable, because it relies on being able to roundtrip to the server more-or-less at will. If the user goes into a tunnel, their page breaks. In the olden days, making a user reload and start again when they lost their connection might have been acceptable; nowadays, not so much.
Which means either doing it on the client, or hybrid. Hybrid is inherently more complex - it means doing everything twice, with the potential for them to get out of sync. If you want to just have one set of rendering logic in one place, the only place for it is on the client.
I disagree on client-side rendering. I think one of its big strengths is that it cleanly separates the data layer from the end representation and forces you to address that from the design inception.
I agree. To me the whole REST (or similar) + client side rendering is a good choice in many cases. It also allows one backend setup to service web, mobile, IoT or anything else that can receive data without needing to scrape HTML or maintain and API alongside page rendering.