I agree with what is being said, but I don't really see any new thoughts here. This is such a tired conversation. I used to have opinions about this, but I've grown to have a position of, "ship over anything else". Do whatever you can to ship faster. If that is nextjs, great. If that just a bunch of PHP files on an apache server? great. None of it is one-sized fits-all. /shrug
I feel odd dissing this article, because there's nothing wrong with it: Saying that you should consider your audience, focus on your content, and use "rich" (oh man, I remember when RIA was the buzz-de-jour) websites when, and only when, appropriate, is not controversial.<p>That said, I don't feel like there's much actually said. Just restating what is commonly advised (if not practiced) best practices, and not really doing anything to address WHY it isn't practiced. It also failed to mention the differences when you have an application that DOES benefit from being "rich", how progressive enhancement is still a good theory (I'll be honest, none of my workplaces have DONE it).<p>I've seen plenty of dismissive "web coders are trash" and "lol, Js, learn to code" comments (paraphrasing) in various discussions, as well as more informed discussions as to what is and is not a real cost/benefit of various approaches, but I've not seen much in-depth discussion about why the best practices really are rare, and how to fix that. I wish the author had gone beyond the basics and addressed that.
Agree 100% with the need to consider the project in question. I don't know the context of you guys, but at least in mine, I don't see such kind of planning very often.<p>I'm currently involved with two projects. One is a youtube-like app and the other one, a business management application. In the former I'm using SPA and rich front-ends as if there is no tomorrow; in the last I'm coding as if it were 2000's, with form submits, page reloads and client javascript only to the minimum level needed to ensure a reasonable responsiveness.<p>However most projects I'm aware of are using Angular or even React + Material Components to build business apps with lots of data tables and input forms. In my opinion this is a serious drawback, since it increases the project complexity and adds basically zero value to end users, who get a good-looking application which, at best, does the same thing but it's more expensive to write and maintain.<p>P.S. those are my impressions about my local market (Brazil), your mileage may wildly vary.
I think there's a conflation of client-side-SPA === rich/complex here. For all practical purposes, this may be true as SPAs have gotten reliant on <i>complex</i> frameworks like React, Vue, ..<p>In 2019, with ES6, I believe frameworks to be an overkill. When React was introduced, it did goad people into thinking in components, etc. However, classes and higher-order-functions in ES6 allow one to think modularly without a framework. And the Virtual-DOM's value proposition is questionable when DOM updates are properly batched ( like when using <a href="https://github.com/wilsonpage/fastdom" rel="nofollow">https://github.com/wilsonpage/fastdom</a> ).<p>Complexity is bound to increase with features, either in the back-end or front. But SPAs (with PWAs) offer advantages of being fully functional when offline, or with spotty connectivity, which is a significant value proposition. Not to mention lower server-side costs (in use-cases where server costs are prohibitive, SPA-PWAs is the only economically viable option).<p>My takeaway is to evaluate not just the reliance on SPA/PWAs but also on complex frameworks with diminishing returns.
Equally it's acceptable to go down the single-page-application route and just make sure you prioritise performance. A lot of SPAs/"rich" web applications are not slow because of inherent performance disadvantage to that model, they're slow because they're poorly written.<p>Perhaps just because I've dedicated a lot of time to it but I think something like React makes it a lot easier for me to find where my performance bottlenecks are and eliminate them vs. mixed server-side dynamic HTML / progressive enhancement.
SPAs should just die out. As a user the experience virtually always means slow loading, large downloads, and more fragility.<p>Seeing a loading spinner makes me cringe.
I've been wondering over the last couple years what the state of the art is on server side rendering. There seems to be a lot of energy on the FE side with react and angular, but other than dockerization, I don't hear about the same class of big FAANG shiny backend rendering tools. Even the article is just pointing out that server side exists.
I'm working on setting up a small website for my wife's business and am still thinking of running Flask/gUnicorn just like I did years ago. Maybe there is something with Elixer / Erlang, but that seems niche.
What should I be looking at, if I want to skill up to the new shiny in server side rendering.
Another argument for keeping business logic server-side is, well, that your proprietary and presumably valuable code remains on the server instead of being widely disseminated.
Considering we have had an entirely new paradigm shift in front end development, I have yet to see anything that has blown my mind for usability or UI. Usually it's the same site and design except now it jiggles about as stuff loads asynchronously or repaints. I see way more degradations than I do improvements. I would love to see the creme of the crop, if anyone has any good applications using new tooling they think are a good example?
Going back to the early 2000s with freemarker/twig/mustache is what he means I guess? Nextjs and Gatsby are what they are for very good reasons and backend apis can be written in whatever you please these days... Why would you consider using those dinosaurs again? When that is all you and your team is comfortable with?
I'm a really late comer to web development. I got introduced to it through angular and react SPA. At this point I don't know how to do anything except these types of projects and not a lot of time to dedicate to learning a new (or old, depending on your view) way of doing things.<p>I need some type of remedial web dev training.
agreed:<p>everything that you must do client-side because of latency, offline and/or device capabilities: do it client side.<p>everything else should go to the server.