A Front End Does Not Have to Be Rich
apress.com
apress.com
What about amount of features? Time to ship? Time between releases? Number of bugs? User satisfaction? Development costs? ROI? Ease of hiring? Scalability? Reliability?
Not particularly saying an SPA is better at the criteria above (not saying it isn't either), but these criteria are way more important than "amount of code"
First off, there's the reductio ad absurdum in the room: perl. Using perl, I could rip off some amazing things in amazingly little code. (Forth, too, come to think of it.) I think, though, that most of us who initially fell in love with it eventually came to learn that denser code is not necessarily better code. Nowadays I'll gladly take the same thing written in 5X as much Python code.
Second, sometimes more code provides useful things, like bulkheads and seams that allow for easier modification in the future. Over in OO-land, I find that writing SOLID code often increases line counts considerably, but I still strongly prefer my code to be SOLID.
Long story short, I find that code volume can be a proxy for code quality, but it's a very imperfect one.
I really like those analogies, I'll reuse them!
But it's also true that I see a lot of dissatisfaction around the long-term maintainability of doing things in basic HTML/CSS. And I'm not aware of any compelling options that give you better better modularity, but aren't some super heavy-handed SPA-centric framework like React.
It's really easy to use jQuery or some small purpose-built JavaScript library to add simple interactive features like a datepicker or accordion menu. But then you start building your own interactive features, with no framework or architecture in place to manage the ever-increasing amount of client state that is changing in a user session.
At some point (and I would argue it's pretty early on), it becomes far simpler to have a client-side UI framework/library/architecture in place, even if it is initially too heavy for your current needs. Your website is probably not going to need less interactivity as your product and business progresses.
this. I've been front-end for the last several years, and I always tell my managers that front end doesn't need to write for scalability or extensibility (though those are both GOOD!), it needs to first prioritize _replaceability_. Because the "asks" will change dramatically in just a few years, even if the tech doesn't change (and the tech does also change - stupidly fast).
In fact, most backend systems I've seen that are a mess actually work great...if you use them as originally intended. But the current asks are different than those. Software both requires assumptions and doesn't handle changes in assumption well.
Anyone arguing from a point of code purity without acknowledging these facts doesn't persuade me of much. Sadly, this means that in the regular churn we don't get to pull in all the truly valuable points that are left aside with the other items. (See how much of the industry, myself included, is re-learning lessons learned by the early programming pioneers)
This hasn't been my experience at all. SPAs are so simple for me to spin up these days with all the tooling to cover the boilerplate for you, e.g. create-react-app or Vue CLI. With the advent of cloud providers, hosting is insanely simple too. You can get a working SPA out in a day complete with a frontend, backend API, and a database.
In the case of SPA frameworks, I've not spent much time with them (I'm the back end guy on my team), but the most striking things I see whenever I get involved in a project that uses them, and when I've taken the time to learn them, is that there are just so many moving parts. And a whole lot of stuff about the internal logic of whatever SPA framework you're using, and possibly how specifically you're using it, that a newcomer has to know before they can really work efficiently. They're so complicated that I sometimes see people having to do some really elaborate things to get them to play nicely with other stuff they want to do. Using D3 in the same site comes to mind there.
Edit for downvoters: Ok, technically, YouTube is a SPA. What I meant, in the context of this discussion, is that YouTube uses a technique similar to what GitHub does, where the server returns fragments of HTML.
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.
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.
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.
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 have routines using vanilla javascript, believe it or not.
Model binding is a requirement only if you are going to deal with your model in javascript. Maybe to perform an ajax call or something alike. But I often simply do a form submit like in the old days.
In more complex routines I may use Angular.js (not Angular). But not as a single page application, bundling code, minifying it etc. I often get away with an angular.js application locally to the page which is going to use that script.
I won't lie, the codebase is ugly, inconsistent and unpredictable as hell and new developers, when arrive to the team, get immediately convinced that the architecture was planned by some amateur who don't know what he is doing.
They are probably right, but get familiar with the project really quickly and understand that there is order under that apparent surface of chaos.
I'm pretty sure this leads to more code having to be written, but it's code easier on the brain, easier to split in tasks to different developers and so on. We are not typists after all, experience shows that it's best to spend more fingers and less brains.
This is the best I could do so far to make a fairly inexperienced team deliver at a reasonable pace while dealing with users changing their minds at relativistic speeds.
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 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!).
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.
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.
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 definitely ways to improve performance, but only Google and Facebook seem to pull off real performance with these kinds of tools.
Seeing a loading spinner makes me cringe.
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.
That’s reversed for websites & apps for small companies and startups. In those cases, SPAs tend to feel fragile, buggy, and full of weird defaults and unusual behavior, especially compared to the relative simplicity of a basic form with some JS sprinkles.
No idea why that is, or if the perception is even accurate.
For example getInitialProps being isomorphic means there is no good way to define controller-like behaviour (redirects, error codes, data fetching). Their examples literally tell you to have the function check whether you're executing on the server or client and have the implement the desire to behaviour for both environments.
Their new APIs seems to be pushing people towards building functions for data loading that are deployed as standalone lambdas. This is not nearly as elegant as the solution they have for pages (any thing stored as "pages/:name.js" is renderable).
SSR Vue = Nuxt.js
Django is all SSR and is solid, if a little dated.
In my mind, anything complex would probably be server side anyway for performance reasons (though I admit there are many, many SPAs with seemingly little thought about performance.)
API keys, anything that handles auth, etc.
Only if you're going full REST will there be a risk of client-side business logic.
I disagree, typically business logic is implemented in the API not in the client.
I need some type of remedial web dev training.
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.
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.