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.
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).
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.
Yep. There's a proliferation of reductive posts that essentially repeat the same truisms we've all heard: You don't need a SPA; NPM is a ghetto; Front end web development has too much churn.
Who cares? If you don't like the state of web dev, leave or learn to make it better. If someone were to write yet another NPM sucks article, BUT include in it a description of a PR they opened to improve the process, I'd happily upvote them. But instead people seem to be satisfied with complaining with little action.
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.
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.
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.S. those are my impressions about my local market (Brazil), your mileage may wildly vary.
>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.
So what (if any) framework do you use for the business-like apps that don't need a rich frontend? I agree that using something like Angular can be bloated, but it does offer some nice "shortcuts" for even the blandest of UIs. Specifically model binding.
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 complex frameworks like React, Vue, ..
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 https://github.com/wilsonpage/fastdom ).
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).
My takeaway is to evaluate not just the reliance on SPA/PWAs but also on complex frameworks with diminishing returns.
I actually tried to implement a SPA using just ES6 (in Typescript) some years back and ran into quite a few problems with data flow, which frameworks like Vue.js readily solve.
I think that (for example) Vue by itself is quite light (mu Vue apps were never slow, even on a computer that choked on most other webpages). The problem is that many web developers don't care about performance and will hapilly fire tens of HTTP requests while loading the page, which happens to be over 1M because of all the unnecrssary JS and CSS libraries (looking at you, Bootstrap!).
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.
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.
> 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.
I feel there is a wrinkle here, though. SPAs aren't inherently slow, but they are built around models that will ineluctably tend towards slowness unless the developer works hard to avoid that.
SPA frameworks are all about breaking your site down into small, self-contained interface elements that can then easily be composed into a larger whole. When each interface element is acting independently, though, you end up with lots of network requests getting fired as each one builds up its state independently of the others. Network requests are slowwwwww, and it only takes one of them stalling out to make the whole page feel sluggish or broken.
There are ways to architect around this problem, but they require understanding that it actually is a problem, and they take away some of the "shared nothing" developer independence that made the SPA approach so appealing in the first place. So it's not surprising that so many SPAs either don't take advantage of them or do so incompletely.
>web applications are not slow because of inherent performance disadvantage to that model, they're slow because they're poorly written.
Do you think code quality is affected at all by framework choices?
Remember, we're not talking here about absolutes in terms of possible performance, it's about performance per dollar for the business. If it is substantially harder to learn and/or write "good" code using one framework over another, I'm not sure it matters how much you "prioritize performance."
There are inherent performance disadvantages, including time-to-first-paint. Facebook using React makes a lot more sense than your average business website, because Facebook has a lot of dynamic content, with a complex interface.
There are definitely ways to improve performance, but only Google and Facebook seem to pull off real performance with these kinds of tools.
Usually with any website which involves booking tickets, if I see it's a SPA I think there's a good chance that the company spent some effort on this and therefore care and it's likely to work OK.
If it's a server-rendered forms type application, I almost expect it to be poorly implemented, be frustrating to use or fail completely.
My suspicion is that, because these server-rendered forms type frameworks are very mature and much easier and faster to build something with, they are the go to option when budget is low, i.e. when quality is not a priority, and I think that may explain the correlation I've seen. Nothing to do with the underlying technology of course.
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.
I think it makes sense to just stick with what you know, unless you have good reasons not to. But since you asked (and mentioned Elixir), Phoenix live view or https://github.com/grych/drab.
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.
And the opposite to that argument is that making an SPA gets you an API "for free". If you want users to be able to write their own code that interacts with your platform, it might be beneficial not to write multiple server-side interfaces and to "eat your own dogfood".
Wouldn't the actual business logic remain behind an authenticated API endpoint? Even your relational data models would probably be turned into something more like a tree.
Only if you're going full REST will there be a risk of client-side business logic.
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?
Yeah, business logic in the client is not a great idea. What happens when you add a new client (mobile app?), and you get to relive all of the same bugs you fixed? Just don't do it.
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.
Just type "jquery" in front of every programming-related web search you do.
If you want something old-school but even more advanced... type "jquery plugin."
I know what you're thinking... I should write an ebook. But I'm too deep in mountains of jquery slop at work, I barely have time to write this comment.
[+] [-] duncan-donuts|7 years ago|reply
[+] [-] collyw|7 years ago|reply
[+] [-] dunk010|7 years ago|reply
[+] [-] draw_down|7 years ago|reply
[deleted]
[+] [-] ergothus|7 years ago|reply
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).
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.
[+] [-] _hardwaregeek|7 years ago|reply
Who cares? If you don't like the state of web dev, leave or learn to make it better. If someone were to write yet another NPM sucks article, BUT include in it a description of a PR they opened to improve the process, I'd happily upvote them. But instead people seem to be satisfied with complaining with little action.
[+] [-] myth2018|7 years ago|reply
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.
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.S. those are my impressions about my local market (Brazil), your mileage may wildly vary.
[+] [-] jotato|7 years ago|reply
So what (if any) framework do you use for the business-like apps that don't need a rich frontend? I agree that using something like Angular can be bloated, but it does offer some nice "shortcuts" for even the blandest of UIs. Specifically model binding.
[+] [-] timw4mail|7 years ago|reply
[+] [-] writepub|7 years ago|reply
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 https://github.com/wilsonpage/fastdom ).
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).
My takeaway is to evaluate not just the reliance on SPA/PWAs but also on complex frameworks with diminishing returns.
[+] [-] dvdkon|7 years ago|reply
I think that (for example) Vue by itself is quite light (mu Vue apps were never slow, even on a computer that choked on most other webpages). The problem is that many web developers don't care about performance and will hapilly fire tens of HTTP requests while loading the page, which happens to be over 1M because of all the unnecrssary JS and CSS libraries (looking at you, Bootstrap!).
[+] [-] paperpunk|7 years ago|reply
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.
[+] [-] smacktoward|7 years ago|reply
I feel there is a wrinkle here, though. SPAs aren't inherently slow, but they are built around models that will ineluctably tend towards slowness unless the developer works hard to avoid that.
SPA frameworks are all about breaking your site down into small, self-contained interface elements that can then easily be composed into a larger whole. When each interface element is acting independently, though, you end up with lots of network requests getting fired as each one builds up its state independently of the others. Network requests are slowwwwww, and it only takes one of them stalling out to make the whole page feel sluggish or broken.
There are ways to architect around this problem, but they require understanding that it actually is a problem, and they take away some of the "shared nothing" developer independence that made the SPA approach so appealing in the first place. So it's not surprising that so many SPAs either don't take advantage of them or do so incompletely.
[+] [-] Benjammer|7 years ago|reply
Do you think code quality is affected at all by framework choices?
Remember, we're not talking here about absolutes in terms of possible performance, it's about performance per dollar for the business. If it is substantially harder to learn and/or write "good" code using one framework over another, I'm not sure it matters how much you "prioritize performance."
[+] [-] timw4mail|7 years ago|reply
There are definitely ways to improve performance, but only Google and Facebook seem to pull off real performance with these kinds of tools.
[+] [-] timw4mail|7 years ago|reply
Seeing a loading spinner makes me cringe.
[+] [-] davnicwil|7 years ago|reply
Usually with any website which involves booking tickets, if I see it's a SPA I think there's a good chance that the company spent some effort on this and therefore care and it's likely to work OK.
If it's a server-rendered forms type application, I almost expect it to be poorly implemented, be frustrating to use or fail completely.
My suspicion is that, because these server-rendered forms type frameworks are very mature and much easier and faster to build something with, they are the go to option when budget is low, i.e. when quality is not a priority, and I think that may explain the correlation I've seen. Nothing to do with the underlying technology of course.
[+] [-] mmartinson|7 years ago|reply
[+] [-] collyw|7 years ago|reply
[+] [-] greenhatman|7 years ago|reply
[+] [-] baldeagle|7 years ago|reply
[+] [-] dagoat|7 years ago|reply
[+] [-] timw4mail|7 years ago|reply
[+] [-] williamdclt|7 years ago|reply
[+] [-] Eire_Banshee|7 years ago|reply
SSR Vue = Nuxt.js
Django is all SSR and is solid, if a little dated.
[+] [-] btbuildem|7 years ago|reply
[+] [-] Eire_Banshee|7 years ago|reply
[+] [-] dvdkon|7 years ago|reply
[+] [-] ppeetteerr|7 years ago|reply
Only if you're going full REST will there be a risk of client-side business logic.
[+] [-] onion2k|7 years ago|reply
[+] [-] ehnto|7 years ago|reply
[+] [-] dugluak|7 years ago|reply
I disagree, typically business logic is implemented in the API not in the client.
[+] [-] duncan-donuts|7 years ago|reply
[+] [-] igl|7 years ago|reply
[+] [-] thieving_magpie|7 years ago|reply
I need some type of remedial web dev training.
[+] [-] halfjoking|7 years ago|reply
If you want something old-school but even more advanced... type "jquery plugin."
I know what you're thinking... I should write an ebook. But I'm too deep in mountains of jquery slop at work, I barely have time to write this comment.
[+] [-] je42|7 years ago|reply
everything that you must do client-side because of latency, offline and/or device capabilities: do it client side.
everything else should go to the server.
[+] [-] amelius|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] kimjongman|7 years ago|reply
[deleted]