A Front End Does Not Have to Be Rich(apress.com)
apress.com
A Front End Does Not Have to Be Rich
https://www.apress.com/us/blog/all-blog-posts/your-front-end-does-not-have-to-be-rich/16537718
84 comments
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
In my experience going SPA seems to double the amount of code needed (at least).
Maybe (I would instinctively agree). But amount of code is not a good metric for almost anything.
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"
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"
If you view code as a liability then more code is worse.
Viewing code as a liability does not make it worse, as not all code as the same level of liability associated with it. I'd much rather have double the lines of code if it yielded a code base that was more maintainable, easier to reason about, easier to debug, and had better separation of concerns.
This is such a thorny issue.
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.
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.
> bulkheads and seams
I really like those analogies, I'll reuse them!
I really like those analogies, I'll reuse them!
This pokes at one of my suspicions: Personally, I agree that SPAs are way more complicated and heavyweight than you need for most sites. And they do seem to require a lot of code up-front.
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.
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.
Projects that start out as basic HTML/CSS (perhaps with server generation, like Rails) can run into major problems when they gradually need to start adding interactive features (which, in my experience, is almost certainly going to be the case with any company whose website is a significant part of their product and who have not yet found product-market fit).
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.
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.
> But it's also true that I see a lot of dissatisfaction around the long-term maintainability of doing things in basic HTML/CSS
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. 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)
> Personally, I agree that SPAs are way more complicated and heavyweight than you need for most sites.
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.
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.
The experience is definitely easy, but it's hard to believe that it's simple. Oftentimes things that are very easy on the surface have a whole lot of complexity going on under the hood.
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.
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.
I can build a whole app in only a hundred lines of code once I add a million lines of code... :)
How cloud providers make hosting simpler for SPA and not for server-side rendered apps? Agreed, for the front, you can use something like Netlify. But for the backend, the game has not changed. What do you use?
I haven't had that experience. I will agree -- going with a SPA has pretty much always made things more complicated than they needed to be. I've always liked SPAs, but won't use them if I'm building a site that doesn't have complex interactions. Idk, there's a pro/con for any tech in your stack. It depends on what you actually want to be stuck supporting.
When it comes to speed of delivering, the most important thing is usually what you have experience in. If most of your experience is in SPAs then go for it.
With SPAs you are going to need experience in a frontend and a backend framework. With server side rendering you can get away with only knowing the backend framework well.
Yay, the world is waking up,
google search is not spa,
Ebay is not spa,
Wkipedia is not spa,
Youtube is not spa,
Stack exchange is not spa,
Duck Duck Go is not spa,
HomeIdea3D.com is spa though
HomeIdea3D.com is a real app with complex state and stuff so an SPA makes sense here.
Google, eBay, Wikipedia, YouTube, Stack Exchange, and DuckDuckGo fit nicely with the concept of “type search in form, get list of links, video, article, QA page, etc.” HomeIdea3D tries to emulate/replace a desktop application. This is the type of tool that I would allow a SPA for, even though I normally browse with JS disabled.
YouTube is indeed a SPA.
YouTube is not really a SPA as in React or Vue. It looks like they use something similar to TurboLinks or Intercooler: https://youtube.github.io/spfjs/
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.
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.
Hear, hear!
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.
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.
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.
It depends.
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.
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.
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.
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!).
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!).
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.
I need some type of remedial web dev training.
I need some type of remedial web dev training.
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.
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.
No, we don't think you should write Yet Another E-Book. :(
agreed:
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.
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.
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.
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.
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 not sure how you drew the last 2 conclusions from this article. The point is to make sure people think twice before they default to an SPA to make sure it's the right decision - in my experience a lot of people are jumping to the SPA pattern without considering the alternatives. Do you not think an article like this, which aims to increase awareness of non-SPA architectures, is helping to make it better? What else would you like to have seen this article cover?
The last two points are not specific to the article but to the category of vaguely contrarian points about modern web development in which the article resides. And I’m a little skeptical of the premise, which is that we need to increase awareness of non-SPA architectures. Even though there is a lot of hype around SPA’s and fancy front end driven architectures, I’d bet that the vast majority of code written and new developers minted are primarily focused on server side web applications. It’s just nobody ever says “yknow what’s new and hot and the thing everybody should use? Java servers!”
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.
Server-side rendering doesn't really have "new shiny". It works, just as it has, and that is a feature, not a bug.
This is why the next generation of dev's is going to be FE heavy, I think. Because the big marketing of mindshare and talks is going to all the developments on FE, vs server side where it is steady and reliable.
For React, AFAIK Next.js is the main guy for SSR
Next seems to do a lot right. But there are some big gaps that they need to fill to be the canonical SSR framework.
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).
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 React = Next.js
SSR Vue = Nuxt.js
Django is all SSR and is solid, if a little dated.
SSR Vue = Nuxt.js
Django is all SSR and is solid, if a little dated.
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.
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.
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.
To build on this, I think it may be an issue with the REST model specifically as opposed to SPAs themselves (which you may have been alluding to). It inherently encourages several small network requests. I'm not a huge GraphQL fanboy and I haven't worked with it closely, but it's a lot more conducive to batching data fetches into only a few requests. You can get around this by violating some REST assumptions like making heavy endpoints that return all of the data you know you'll need at the initial loading of an application, but then you open yourself up to criticism from pedants.
>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."
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.
There are definitely ways to improve performance, but only Google and Facebook seem to pull off real performance with these kinds of tools.
SPAs should just die out. As a user the experience virtually always means slow loading, large downloads, and more fragility.
Seeing a loading spinner makes me cringe.
Seeing a loading spinner makes me cringe.
It's funny, I have the opposite association.
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.
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.
Personal experience, I've seen SPAs created with a one developer project, I've seen server-rendered forms created with a 30 person team. Both satisfied the needs of the business which was "to take data from text boxes and save them to the database".
My experience matches yours for large organizations; fairly or not, if I’m booking a plane ticket through the airline, an SPA page makes me feel confident that there was some real work put into it, while a basic server-side forms + JS approach makes me worry it’s a semi-abandoned afterthought.
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.
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.
please keep in mind server-side doesn't mean necessarily "basic"
you can have a server-side app and still have the same user experience as a full-blown SPA app, as long as you know what you must do in the client for a great user experience.
Personally, I'd love if google maps stuck around. It'd be a bit of a bother if it was server rendered.
There are some places where it makes sense, but they are overused.
Some, but most "web applications" are just overly complex websites.
I’m implementing an SPA right now and I really don’t see why they get so much hate. Vue is what I’ve been using and with the right implementation is capable of being very fast, very secure, and easy to debug if you choose to go down the typescript path. The only real problem I see occurring down the line are issues with SEO, but better support from search engines and workarounds to pretender pages seems to make the positives of SPA outweigh the negatives
That just means the site is slow. That has nothing to do with SPA.
> business logic being implemented in the client
I disagree, typically business logic is implemented in the API not in the client.
I disagree, typically business logic is implemented in the API not in the client.
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.
exactly, that's one of the advantages or the modern way of web development - decoupling business logic and UI (HTML)
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.
This is my biggest issues with SPAs. Its not that it is that hard, its just so much easier to keep it secure if its being done server-side.
What's an example of something that would be proprietary, reasonably on the front-end, and stealable from minified source?
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.)
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.)
An inexperienced dev might do something like put API keys in frontend code. You can even do an advanced search of Github to find people's keys to steal to get access to paid APIs.
Inexperienced devs already leak keys into front end code before SPAs.
Anything you would normally stash in an API gateway.
API keys, anything that handles auth, etc.
API keys, anything that handles auth, etc.
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.
Only if you're going full REST will there be a risk of client-side business logic.
Equally, you can't build a server-side app that works offline. There's arguments for and against regardless of what you choose.