As an avid developer of SPAs (currently working on one for my own blog frontend) I'd say a lot if this stems from people being convinced SPAs 1) provide a faster development cycle, 2) they believe that they've offloaded all need for optimization on the framework they use and 3) "serious" development teams build SPAs.
Anecdotally I find SPAs, while I'm more comfortable developing them, will take longer to build. You need to pay more attention to the quirks the author mentions and you need to spend more time explicitly optimizing your code. I like this paradigm because if there is inconsistent logic, poor performance, or other issues, it's my fault and I have the opportunity to fix it.
As a counter example to the ones mentioned in the above article, around 2 years ago I build a drum machine webapp entirely in JavaScript/React (https://io808.com). This has ~17 JS library dependencies and ~6000 lines of source code but the gzipped bundle size comes out to ~97 KB.
Just because you're building an SPA doesn't mean you need to spend less time optimizing your code, in fact it likely means the opposite.
I’ve used React in the past and I believe what you’re mentioning is very React specific.
Angular has lazy and eager loading, which reduces bundle sizes. It also doesn’t require so many frameworks to manage manually. They are still there, but they are sort of imported automatically by angular cli so it doesn’t take a lot of mental overhead.
Some issues I had, though, were with bugs in newer versions. Some of those issues stopped development outright.
Another issue I have on one team is the fallacious notion that the front end programmer will take over the front end so no one else will need to think about it. Business specific logic seems to be out of reach for my particular developers, which prolongs the development cycle.
The benefit of state management and inter component communication have to be balanced the the practicality of who is doing the work and if those people can take ownership of all associated areas touched by the SPA.
Maybe there's more of a gray area between content sites and applications these days, but I think it's still pretty obvious: If most of the user's time is spent reading content, it's a content site.
I work in ecommerce and I feel it’s somewhere in between. We need to build for seo optimizations for the category/product experiences yet there is a lot of application like intersections, especially on the category filtering and the product sku selections. Quickshops, In store pickup modals, user specific recommendations trays, add and edit reviews et all. Different caching for server render at the edge vs personalized components adds another layer. Being able to serve with a shared routing scheme both client side (for improved performance) and server side for faster initial page load and seo on non-Google crawlers is a tough problem. Especially when you add in client hydration of the redux store. That parse time is a real killer on mobile. You add in service workers and prefetching and the complexity ratchets up further. The other issue we deal with is marketing pixels and trackers. But that’s another story. There is a ton of complexity in building a highly functioning ecommerce site.
That's a good starting point. I'd drill down even further and ask "what does the user do with the application?"
If the user needs to look at multiple screens at a time (e.g. like a mail client or something of similar complexity), then they're a candidate for an SPA. If the user does not need to do that, the app is probably simple enough to not be an SPA.
The problem is even content is becoming functional with interactive charts, infographics and figures, videos, media, filtering, sorting - then the site will eventually need comments, ads, subscribing, favoriting, upvoting, login, lazy load next article, infinite scroll, etc. Yes, a pure content site shouldn't be an spa, but how long can you survive running a pure content site? Information is complex and the web allows us to communicate it more richly than the static 2d representations of old.
One of the ways that I prefer to judge a JavaScript framework is (1) what is the minimum payload to use it, and (2) how nicely does it play with a hybrid app?
In practice I’ve found VueJS does pretty well in this regard. Rather than build a full SPA I can sprinkle a few components here and there on pages that are highly interactive. The rest of the mostly static screens on my app are perfectly happy to be rendered from the server.
It can be hard to strike the right balance between developer friendliness (ie maintainability and extensibility) versus user experience (ie speed and backwards compatibility) these days, but as always it’s important work to deliver the best user experience we can, and I agree with the author that SPA are not always the right choice in this regard.
>Rather than build a full SPA I can sprinkle a few components here and there on pages that are highly interactive
In practice, I've found "hybrid" apps hard to pull-off. In my experience, the question becomes, where do you draw the line?
Take the simple/common case of presenting a list view. From the list, you want to allow the user to click to view details, which you then present dynamically--maybe in an overlay. It's a great user-experience. Everything pops, the user can easily return to the list view without a full page-load, etc.
But, you now have a details view that is not reachable directly via its own URL. So, you use the framework's routing capability to assign one. Now, things are getting weird, because you're routing a dynamic view on top of a server-rendered one. You'll likely end up finding that you'll have to route the server-view as well for general navigability. And, you also have to account for people hitting the details URL directly (i.e. render the proper underlying server view, then let the client route to the dynamic URL).
Not to mention the back-button.
All manageable, of course. But, it gets messy to maintain such a hybrid approach. By the time you've integrated the routing, etc. the question becomes why hybrid? Why not full SPA?
If your app is super-simple wherein you're just doing the tiniest bits of dynamic stuff and you don't need things like first class URLs, navigability among dynamic content, etc. then, yeah, maybe. But, that's not really a hybrid-SPA solution because there's no SPA there.
In fact, I'm not sure there is a such thing as "hybrid-SPA". By definition, seems it's either a SPA or it's not.
> broken “open in a new tab” behaviour – people like to handle links in onClick handler, and browser can’t recognize it as a link (even if the majority of the links are valid, sooner or later you’ll encounter a non-link “link”)
This one annoys me the most, but I will say an analogous problem is fairly common on non-SPA web sites, where reloading a URL doesn’t work as expected.
That's usually just a lack of basic engineering practices common to well-implemented SPAs.
All requests below the SPA's root should be forwarded to the SPA root, which appropriately then routes the request to the proper views and controllers.
Proper usage of resource IDs in these URLs allows a newly initialized application model to populate and serve the appropriate content for the appropriate views.
TBH most of the cons stated in this article are just because of bad programming, not because it's a SPA
> broken “back” button (sometimes it works properly, but in general people don’t trust it)
If your UX is good, the user will notice data is refreshed when going back. All current top tier SPA Frameworks have support for correct HTML5 routing.
> broken “open in a new tab” behaviour – people like to handle links in onClick handler, and browser can’t recognize it as a link (even if the majority of the links are valid, sooner or later you’ll encounter a non-link “link”)
Again, most up-to-date frameworks have a fallback by adding a normal href so you can still CTRL-Click it.
> sometimes broken “refresh” button – after refreshing you end up in a different UI (usually slightly, but still different)
I don't see a real disadvantage here, since you can simply store your state by manipulating the URL or even localstorage. So you even have the possibility to not store your state...But again, application design, not SPA
I do agree with TTI (at least on the first load) and bad performance on low end devices.
No. Because it is an SPA, it means there is more work to restore the default behavior of the back button. That's the way he should have articulated his point.
You also mention HTML5 routing.. Ok now you have to configure your web server to properly parse the URL and understand what it's conveying.
Half-expecting this article to itself be SPA, and was pleasantly surprised that it isn't.
I agree completely with the author; there's some things (games and such come to mind) which certainly deserve to be SPAs, but the majority of the time it's a horrific waste for every single visitor to have to process MBs of data just to display a few KB of text and hundreds of KB of images (at most). Why? Just so developers can show off that feeling of how awesome they are for using some incredibly complex framework. That, and the ridiculous rate of churn, are probably what most irks me the most about the whole web development community (and why sites like HN appeal to me so much.)
I'm not sure what's responsible for this "love of bloat", but IMHO we should be teaching developers how to do more with less, and not the complete opposite as seemingly happening today.
> Why? Just so developers can show off that feeling of how awesome they are for using some incredibly complex framework. ... I'm not sure what's responsible for this "love of bloat", but IMHO we should be teaching developers how to do more with less, and not the complete opposite as seemingly happening today.
I think you're misplacing the cause into developers. Developer's want to use the SPA framework because certain magnitudes of "application like UI" become maintainence nightmares for teams who stick with jQuery or use youmightnotneedjQuery.
The reason they end up bloated or with random framework-supported elements broken (back button, etc.) is from what I call MVP culture. AIM and IRC were perfectly fine in the early 2000s, but instead of upgrading them for 2010+ they were abandoned or stripmined of value (Skype). Now we have slack, discord, flock etc.. releasing MVPs. Except apparently, they are perpetual MVPs.
Many industries are encountering this. Developers at large are not permitted to rewrite in native languages, optimize any non-blocking performance issue, fix bugs that don't affect the bottom line. Everyone's trying to disrupt an industry so they can vendor lock in high profit rents. When we finish switching from typescript to reasonML and decide to switch from reasonML to Nim/kotlin-native, MVP culture will still be there to tell developers not to fix the broken back button.
Some of the arguments the author mentions are not really good arguments. Basically it boils down to how much you care about the user experience. I designed and developed a SPA for a large real-estate portal in <6 months. I think we've nailed all of the points the author mentioned:
- Initial request is rendered server-side, so TTI is extremely low. Even if the JS hasn't kicked in, the website is already usable.
- Back button works perfectly fine. We use the HTML5 `history.pushState` method to add new entries to the history stack.
- Links are always rendered as anchor tags. So even if the onClick handler fails or the JS crashed, the link will still work.
- Compress the hell out of the bundle. Clocking in at 190KB compressed. (Edit: should do something about this, should be <100KB)
Basically, we have most of the advantages of rendering "static" pages, yet also get all of the advantages of an SPA. We can do pre-loading in search results for example. If you click a link in search results, we immediately render the page and use the data from the search result to show a basic page and then slowly enhance it.
This powers a large real-estate website that receives hundreds of thousands of visits a week. For this kind of business, a lot of stuff is important to get right. SEO related optimisations are extremely important. Hence, we server-side render everything to make sure the GoogleBot can read it all. The same applies to links. We keep our bundle size as small as possible to keep things speedy.
Oh, and I personally got a kick out of spending a weekend to make the website function perfectly well without JS.
The problem with SPAs in the sort of cases that the author is talking about is that people don't think clearly about what requirements they are satisfying when writing a new one. If your app actually needs to switch between various screens without a refresh so your users can most efficiently get their work done, then yes, by all means, make an SPA. That requires knowing clearly who your users are, what they want to do, and what constraints they are under (e.g. if they all work on desktops with good internet access, maybe it doesn't matter that your app is bloated and slow on mobile). I think most people don't do that thinking step first. They want to play with the new shiny, either as a sort of fun or so they can add it to their resume.
This I think is made worse by the unparalleled decadence in which the modern, first-world developer now lives. It is absolutely excessive to have to download 2.6 MB just to show a blog or some simple textual information, but thanks to broadband everywhere and terabyte hard drives, nobody under the age of 30 who isn't working in embedded systems thinks about this anymore.
From a development perspective, in my humble opinion the single biggest hurdle with developing SPAs vs traditional server side applications are problems dealing with state consistency. The state model in non-spa apps is simple: when a pageload is requested, pull the latest state from the server. In SPAs the state has to be held on the client and server, and has to be able to react to state changes from the other side of the wire.
Also I think that large bundle size being a mark against all SPAs is misleading. Yeah, angular is 1mb+, but vue is ~20kb, so the potential for the bundle to be small exists.
> The state model in non-spa apps is simple: when a pageload is requested, pull the latest state from the server. In SPAs the state has to be held on the client and server, and has to be able to react to state changes from the other side of the wire
My view is the exact opposite. Whenever you go through a page reload you lose the state on the client. And that has to be there, as it's what the user interacts with. You then need to send to the server a state which is not, strictly, an application state (it's a UI state) and that state needs to be taken in account by the server, and possibly merged with the application state, when generating the new page. A mess.
On the other hand, a spa never loses its UI state, so you never need to recreate it. The server is also usually stateless, and simply satisfies the requests of the client. Basically you go from developing two separate applications with partly overlapping concerns to developing a single one, running on the client and relying on a service layer to query and persist its data.
I was thinking about this recently watching a major web app throw a bunch of errors and slowdownsall to do with its SPA features. If it was just a normal web app it would be so much faster and more usable. It seems crazy to me that we have faster and faster computers and internet connections, and yet we've added all this new latency to the software we use.
I find the list of pros somewhat unconvincing.
For a lot of applications, a reload is no hardship, and is faster than most SPA interactions I see.
For a lot of granualar actions, jquery, while not sexy, is not harder to maintain than a full SPA would be.
The alleged development efficiency of decoupling front from back really needs context and argument.
As I see things, there are a lot of web projects where a normal app with a little progressive enhancement is a good solution.
I thought gatsbyjs was a nice medium ground. You have the familiarity of a single-page app in terms of stack and yet have the quick loading times and back button, SEO all of that since it produces a static site. I thought it was genius but I'm biased because I like react.
Funny you mention it, I just started looking into rewriting my portfolio website (http://sdegutis.com) from a custom node-based static site generator to use Gatsby.js, in order to get more practice with React.js. Really curious to hear what other HN regulars who've used Gatsby think of it...
I recently started blogging again, and I chose to go with a static site generator. It's fast, really fast. Loading a whole page with each click is so much faster than visiting most of the sites I visit each day.
I'll never get why we collectively decided that it's reasonable to grant every random website in the world execute permissions on our machines.
Not the most compelling list of pros/cons that I have ever seen.
In terms of raw performance for content sites, I found hybrid implementations like Gatsby.js to beat most things. Most of the cons of SPAs can be significantly diminished with SSR, proper chunking, and a variety of other modern techniques -- it just gets complicated in a hurry.
For anyone reading this thread and thinking about server side rendering their single page app: do not go down that route unless you’re willing to also implement proper chunking! If you SSR your pages, but still need to load a giant bundle, you will get the worst of both worlds: a page that looks ready, but makes your users extremely frustrated because they can’t interact because your app isn’t booted yet.
I have mixed feelings about SPAs. I'm mostly a back end developer but do have some front end experience. On one hand, I think life is a lot simpler with server side rendering. On the other hand, I like the purity of REST APIs and front end rendering.
For technical reasons not worth getting into, on my current project, a SPA would be overkill and hard to implement. But I did take the lessons I learned from my time with Angular to create a poor man's model view framework with a combination of HandlebarsJS+JQuery.
After my experience doing it, I understand why a framework would be better. I'm reinventing the wheel (out of necessity), it wouldn't scale to multiple developers without becoming an ungodly mess without a framework to keep people on the rails and it would be harder to ramp people up. When I got thrust into my first Angular project it was easy just to read a few articles and watch some PluralSight videos.
As the dev lead, I will definitely choose a SPA framework when my next front end project comes up. For all of the reasons above and because it's easier to recruit and retain people when you're doing the new and shiny that can add to someone's resume - including mine.
It doesn't matter how I feel about the most popular frameworks, if I want to be employable, I need to keep up to date.
I've worked on a number of SPA's over the years and I always run into the problem of getting my team to give a shit about performance. "We're not Google," they protest. Frankly for a lot of people it's the trade-off of slow client performance for development velocity. It's much easier to just throw on another state for new functionality than it is to consider what parts of the page can be static and how they can be rendered.
Surely if you can't produce an SPA with equivalent or better performance than a more traditional architecture then - don't build an SPA.
Or even better use a simpler solution that gives me 80% of the benefits of an SPA: Turbolinks, PJAX, intercooler.js or even a light sprinkling of good old AJAX.
See, "we're not Google" should actually mean that you care about performance more. Google can throw millions of dollars worth of infrastructure into making an app go marginally faster. Whereas, all you have is brainpower before you deploy or ship. And it doesn't take that much more brainpower to get big increases in client performance when you're starting from not-optimized-at-all. The marginal payoff is larger and the marginal costs are much smaller.
For the problem of bundle size, it saddens me that Google's Closure Compiler (specifically the advanced mode) hasn't gained much traction. This provides fine-grained tree-shaking to minimize the bundle size. But this requires static analysis of the whole program, which is at odds with the dynamism of JavaScript. Maybe now that static typing is coming back into fashion, the Closure Compiler or something like it will gain widespread adoption.
Organizing all your jQuery into meaningful classes and keeping the whole thing organized and orchestrated is very much the essence of programming. It's a rare skill (as a trip through many large jQuery code bases reveals).
Filling in some templates causing magic to happen behind the scenes on the other hand, not so much.
That being said, 1) are we interested in feeling like programmers or in pumping product? 2) if "pumping" is the answer, best tools depends on what is being done. All in favor or SPAs (when needed), but no, they aren't cooler than jQuery and are often big fat pigs that just shouldn't be used in that situation.
It’s a lot more like writing a native mobile app, that’s for sure. You manage data and state with a much more long-term mindset. A bad line of JS is equivalent to a crash if it halts the whole SPA from working and requires a refresh.
Over 90% of my web browsing is done with JavaScript turned off. When I hit an spa blog I sometimes read it, sometimes not. Clearly if the owner of the blog is so insensitive as to make it an spa, they don't care about the content and especially don't care about their readers. That's fine. There's plenty of other content on the web to read. I don't understand why it's normal to let strangers run code on my computer. Yes, the masses are ignorant of the consequences, but I think that's slowly going away as me generations grow up with the internet. Anyway, the upside is that over 90% of web pages I visit load under a second. Imo, people who make their blog, marketing site, etc. an spa blindly don't care about their content, presentation, or the reader. Why would the reader care about them?
1. tons of widgets/slides/inputs in one single page
2. click submit -> error -> go back -> all filled info gone
3. cant open links in new tabs
4. cant copy shit off the inputs because text was in some kind of fake div with v-data attribute with disabled cursor movements. Had to use devtools to copy shit
5. Naturally, cant paste shit. Had to manually type MD5 checksums.
6. Always got redirect to home page after login
7. Broken links everywhere. Cant restore page state via link. IDK if this page is broken or still ajax in-progress. Had to open devtools to see if there's any js errors
8. If page is broken, refresh, boom, all your typed contents and procedures are gone.
I think if people cant make a proper "multi" page form based web application, they should not be allowed to engage SPA at all.
Very often validation and context-sensitive behaviour needs to be performed on the client and (since you can't trust the client) on the server. You can certainly argue this is better user experience: you don't have to wait for a server round-trip before finding out an action is invalid, but it's hardly decoupled.
Isn't this a part of why node is so popular as a server platform? The stack is now so deeply coupled, it is very beneficial to reuse code.
Repeated validations, while not DRY, aren't a case of coupling. They seem more a case of de-coupling, as they're needed for the application and the service layer to work independently from each other.
While in non-spas your server receives from the client an extremely specific blob of page state plus user input and has to rebuild a specific new page with state updates and/or error messages.
[+] [-] vincentriemer|8 years ago|reply
Anecdotally I find SPAs, while I'm more comfortable developing them, will take longer to build. You need to pay more attention to the quirks the author mentions and you need to spend more time explicitly optimizing your code. I like this paradigm because if there is inconsistent logic, poor performance, or other issues, it's my fault and I have the opportunity to fix it.
As a counter example to the ones mentioned in the above article, around 2 years ago I build a drum machine webapp entirely in JavaScript/React (https://io808.com). This has ~17 JS library dependencies and ~6000 lines of source code but the gzipped bundle size comes out to ~97 KB.
Just because you're building an SPA doesn't mean you need to spend less time optimizing your code, in fact it likely means the opposite.
[+] [-] jamra|8 years ago|reply
Angular has lazy and eager loading, which reduces bundle sizes. It also doesn’t require so many frameworks to manage manually. They are still there, but they are sort of imported automatically by angular cli so it doesn’t take a lot of mental overhead.
Some issues I had, though, were with bugs in newer versions. Some of those issues stopped development outright.
Another issue I have on one team is the fallacious notion that the front end programmer will take over the front end so no one else will need to think about it. Business specific logic seems to be out of reach for my particular developers, which prolongs the development cycle.
The benefit of state management and inter component communication have to be balanced the the practicality of who is doing the work and if those people can take ownership of all associated areas touched by the SPA.
[+] [-] hazza1|8 years ago|reply
You'll get code reuse but that's trivial to get working elsewhere, you just save on redownloading shared code.
[+] [-] notaspider|8 years ago|reply
[deleted]
[+] [-] andrenotgiant|8 years ago|reply
- Content site = NOT single-page-app
- Application = single-page-app
Maybe there's more of a gray area between content sites and applications these days, but I think it's still pretty obvious: If most of the user's time is spent reading content, it's a content site.
[+] [-] motoprog|8 years ago|reply
[+] [-] thehardsphere|8 years ago|reply
If the user needs to look at multiple screens at a time (e.g. like a mail client or something of similar complexity), then they're a candidate for an SPA. If the user does not need to do that, the app is probably simple enough to not be an SPA.
[+] [-] thinkloop|8 years ago|reply
[+] [-] azr79|8 years ago|reply
and you were right, although, with things like Angular Universal and initial server side rendering of SPAs in general, are changing this.
[+] [-] burlesona|8 years ago|reply
In practice I’ve found VueJS does pretty well in this regard. Rather than build a full SPA I can sprinkle a few components here and there on pages that are highly interactive. The rest of the mostly static screens on my app are perfectly happy to be rendered from the server.
It can be hard to strike the right balance between developer friendliness (ie maintainability and extensibility) versus user experience (ie speed and backwards compatibility) these days, but as always it’s important work to deliver the best user experience we can, and I agree with the author that SPA are not always the right choice in this regard.
[+] [-] unclebucknasty|8 years ago|reply
In practice, I've found "hybrid" apps hard to pull-off. In my experience, the question becomes, where do you draw the line?
Take the simple/common case of presenting a list view. From the list, you want to allow the user to click to view details, which you then present dynamically--maybe in an overlay. It's a great user-experience. Everything pops, the user can easily return to the list view without a full page-load, etc.
But, you now have a details view that is not reachable directly via its own URL. So, you use the framework's routing capability to assign one. Now, things are getting weird, because you're routing a dynamic view on top of a server-rendered one. You'll likely end up finding that you'll have to route the server-view as well for general navigability. And, you also have to account for people hitting the details URL directly (i.e. render the proper underlying server view, then let the client route to the dynamic URL).
Not to mention the back-button.
All manageable, of course. But, it gets messy to maintain such a hybrid approach. By the time you've integrated the routing, etc. the question becomes why hybrid? Why not full SPA?
If your app is super-simple wherein you're just doing the tiniest bits of dynamic stuff and you don't need things like first class URLs, navigability among dynamic content, etc. then, yeah, maybe. But, that's not really a hybrid-SPA solution because there's no SPA there.
In fact, I'm not sure there is a such thing as "hybrid-SPA". By definition, seems it's either a SPA or it's not.
[+] [-] baddox|8 years ago|reply
This one annoys me the most, but I will say an analogous problem is fairly common on non-SPA web sites, where reloading a URL doesn’t work as expected.
[+] [-] wavefunction|8 years ago|reply
All requests below the SPA's root should be forwarded to the SPA root, which appropriately then routes the request to the proper views and controllers.
Proper usage of resource IDs in these URLs allows a newly initialized application model to populate and serve the appropriate content for the appropriate views.
[+] [-] JohnnyCrazy|8 years ago|reply
> broken “back” button (sometimes it works properly, but in general people don’t trust it)
If your UX is good, the user will notice data is refreshed when going back. All current top tier SPA Frameworks have support for correct HTML5 routing.
> broken “open in a new tab” behaviour – people like to handle links in onClick handler, and browser can’t recognize it as a link (even if the majority of the links are valid, sooner or later you’ll encounter a non-link “link”)
Again, most up-to-date frameworks have a fallback by adding a normal href so you can still CTRL-Click it.
> sometimes broken “refresh” button – after refreshing you end up in a different UI (usually slightly, but still different)
I don't see a real disadvantage here, since you can simply store your state by manipulating the URL or even localstorage. So you even have the possibility to not store your state...But again, application design, not SPA
I do agree with TTI (at least on the first load) and bad performance on low end devices.
[+] [-] jordache|8 years ago|reply
You also mention HTML5 routing.. Ok now you have to configure your web server to properly parse the URL and understand what it's conveying.
[+] [-] thehardsphere|8 years ago|reply
The worst programming is the result of choosing the wrong tools for the job. There is a class of jobs for which an SPA is entirely unnecessary.
[+] [-] userbinator|8 years ago|reply
I agree completely with the author; there's some things (games and such come to mind) which certainly deserve to be SPAs, but the majority of the time it's a horrific waste for every single visitor to have to process MBs of data just to display a few KB of text and hundreds of KB of images (at most). Why? Just so developers can show off that feeling of how awesome they are for using some incredibly complex framework. That, and the ridiculous rate of churn, are probably what most irks me the most about the whole web development community (and why sites like HN appeal to me so much.)
I'm not sure what's responsible for this "love of bloat", but IMHO we should be teaching developers how to do more with less, and not the complete opposite as seemingly happening today.
[+] [-] Can_Not|8 years ago|reply
I think you're misplacing the cause into developers. Developer's want to use the SPA framework because certain magnitudes of "application like UI" become maintainence nightmares for teams who stick with jQuery or use youmightnotneedjQuery.
The reason they end up bloated or with random framework-supported elements broken (back button, etc.) is from what I call MVP culture. AIM and IRC were perfectly fine in the early 2000s, but instead of upgrading them for 2010+ they were abandoned or stripmined of value (Skype). Now we have slack, discord, flock etc.. releasing MVPs. Except apparently, they are perpetual MVPs.
Many industries are encountering this. Developers at large are not permitted to rewrite in native languages, optimize any non-blocking performance issue, fix bugs that don't affect the bottom line. Everyone's trying to disrupt an industry so they can vendor lock in high profit rents. When we finish switching from typescript to reasonML and decide to switch from reasonML to Nim/kotlin-native, MVP culture will still be there to tell developers not to fix the broken back button.
[+] [-] photonios|8 years ago|reply
- Initial request is rendered server-side, so TTI is extremely low. Even if the JS hasn't kicked in, the website is already usable.
- Back button works perfectly fine. We use the HTML5 `history.pushState` method to add new entries to the history stack.
- Links are always rendered as anchor tags. So even if the onClick handler fails or the JS crashed, the link will still work.
- Compress the hell out of the bundle. Clocking in at 190KB compressed. (Edit: should do something about this, should be <100KB)
Basically, we have most of the advantages of rendering "static" pages, yet also get all of the advantages of an SPA. We can do pre-loading in search results for example. If you click a link in search results, we immediately render the page and use the data from the search result to show a basic page and then slowly enhance it.
This powers a large real-estate website that receives hundreds of thousands of visits a week. For this kind of business, a lot of stuff is important to get right. SEO related optimisations are extremely important. Hence, we server-side render everything to make sure the GoogleBot can read it all. The same applies to links. We keep our bundle size as small as possible to keep things speedy.
Oh, and I personally got a kick out of spending a weekend to make the website function perfectly well without JS.
[+] [-] JohnnyCrazy|8 years ago|reply
[+] [-] thehardsphere|8 years ago|reply
This I think is made worse by the unparalleled decadence in which the modern, first-world developer now lives. It is absolutely excessive to have to download 2.6 MB just to show a blog or some simple textual information, but thanks to broadband everywhere and terabyte hard drives, nobody under the age of 30 who isn't working in embedded systems thinks about this anymore.
[+] [-] nikkwong|8 years ago|reply
Also I think that large bundle size being a mark against all SPAs is misleading. Yeah, angular is 1mb+, but vue is ~20kb, so the potential for the bundle to be small exists.
[+] [-] Udik|8 years ago|reply
My view is the exact opposite. Whenever you go through a page reload you lose the state on the client. And that has to be there, as it's what the user interacts with. You then need to send to the server a state which is not, strictly, an application state (it's a UI state) and that state needs to be taken in account by the server, and possibly merged with the application state, when generating the new page. A mess.
On the other hand, a spa never loses its UI state, so you never need to recreate it. The server is also usually stateless, and simply satisfies the requests of the client. Basically you go from developing two separate applications with partly overlapping concerns to developing a single one, running on the client and relying on a service layer to query and persist its data.
[+] [-] buzz27|8 years ago|reply
I find the list of pros somewhat unconvincing.
For a lot of applications, a reload is no hardship, and is faster than most SPA interactions I see.
For a lot of granualar actions, jquery, while not sexy, is not harder to maintain than a full SPA would be.
The alleged development efficiency of decoupling front from back really needs context and argument.
As I see things, there are a lot of web projects where a normal app with a little progressive enhancement is a good solution.
[+] [-] sebringj|8 years ago|reply
[+] [-] _sdegutis|8 years ago|reply
[+] [-] erlend_sh|8 years ago|reply
[+] [-] eadmund|8 years ago|reply
I'll never get why we collectively decided that it's reasonable to grant every random website in the world execute permissions on our machines.
[+] [-] buchanaf|8 years ago|reply
In terms of raw performance for content sites, I found hybrid implementations like Gatsby.js to beat most things. Most of the cons of SPAs can be significantly diminished with SSR, proper chunking, and a variety of other modern techniques -- it just gets complicated in a hurry.
[+] [-] ryanworl|8 years ago|reply
[+] [-] piranha|8 years ago|reply
[+] [-] scarface74|8 years ago|reply
For technical reasons not worth getting into, on my current project, a SPA would be overkill and hard to implement. But I did take the lessons I learned from my time with Angular to create a poor man's model view framework with a combination of HandlebarsJS+JQuery.
After my experience doing it, I understand why a framework would be better. I'm reinventing the wheel (out of necessity), it wouldn't scale to multiple developers without becoming an ungodly mess without a framework to keep people on the rails and it would be harder to ramp people up. When I got thrust into my first Angular project it was easy just to read a few articles and watch some PluralSight videos.
As the dev lead, I will definitely choose a SPA framework when my next front end project comes up. For all of the reasons above and because it's easier to recruit and retain people when you're doing the new and shiny that can add to someone's resume - including mine.
It doesn't matter how I feel about the most popular frameworks, if I want to be employable, I need to keep up to date.
[+] [-] seawlf|8 years ago|reply
[+] [-] andybak|8 years ago|reply
Or even better use a simpler solution that gives me 80% of the benefits of an SPA: Turbolinks, PJAX, intercooler.js or even a light sprinkling of good old AJAX.
Does anyone remember "progressive enhancement"?
[+] [-] thehardsphere|8 years ago|reply
[+] [-] mwcampbell|8 years ago|reply
[+] [-] bpicolo|8 years ago|reply
[+] [-] adamnemecek|8 years ago|reply
Writing jquery feels like idk...not quite like programming.
[+] [-] mythrwy|8 years ago|reply
Organizing all your jQuery into meaningful classes and keeping the whole thing organized and orchestrated is very much the essence of programming. It's a rare skill (as a trip through many large jQuery code bases reveals).
Filling in some templates causing magic to happen behind the scenes on the other hand, not so much.
That being said, 1) are we interested in feeling like programmers or in pumping product? 2) if "pumping" is the answer, best tools depends on what is being done. All in favor or SPAs (when needed), but no, they aren't cooler than jQuery and are often big fat pigs that just shouldn't be used in that situation.
[+] [-] kylnew|8 years ago|reply
[+] [-] mnm1|8 years ago|reply
[+] [-] est|8 years ago|reply
1. tons of widgets/slides/inputs in one single page
2. click submit -> error -> go back -> all filled info gone
3. cant open links in new tabs
4. cant copy shit off the inputs because text was in some kind of fake div with v-data attribute with disabled cursor movements. Had to use devtools to copy shit
5. Naturally, cant paste shit. Had to manually type MD5 checksums.
6. Always got redirect to home page after login
7. Broken links everywhere. Cant restore page state via link. IDK if this page is broken or still ajax in-progress. Had to open devtools to see if there's any js errors
8. If page is broken, refresh, boom, all your typed contents and procedures are gone.
I think if people cant make a proper "multi" page form based web application, they should not be allowed to engage SPA at all.
[+] [-] sago|8 years ago|reply
I was very surprised to read that.
Very often validation and context-sensitive behaviour needs to be performed on the client and (since you can't trust the client) on the server. You can certainly argue this is better user experience: you don't have to wait for a server round-trip before finding out an action is invalid, but it's hardly decoupled.
Isn't this a part of why node is so popular as a server platform? The stack is now so deeply coupled, it is very beneficial to reuse code.
[+] [-] Udik|8 years ago|reply