I’m surprised this article doesn’t touch on Next.js at all.
Author too busy hating to actually explore tools that would do exactly what they want.
You probably don't need a single-page app
261–270 of 522 posts
Re: You probably don't need a single-page app
#262Unpopular opinion: I love SPAs for simple stuff. Yes, they're a ton of work. But the feel of them is unparalleled.
I have my personal home page written as a Vue SPA. It was a silly amount of work to get together, and not everything works perfectly. BUT: it moves like a rocket. I pre-render the simple front page, so initial load is nearly instantaneous (especially with cloudflare &c), and, by the time a visitor finishes absorbing the information on the front page (which is just a palmos style collection of icons to other content), everything else is loaded. Which means that the effective load time of the whole website is perceptually indistinguishable from zero on a moderate-speed connection (like my crappy home DSL).
And that's... cool. It's legitimately cool. Let me have my fun!
Re: You probably don't need a single-page app
#263Earlier quoted context omitted.
I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all. Compared to client side rendering discrete web requests with minimal templates; you usually get much better…
I completely agree that a big part of this conversation falls on ensuring code quality is maintained over time, regardless of the architecture you choose. Fortunately, I inherited a set of pretty well-maintained SSR rails apps, and they've been pretty straightforward to continue working on (with a couple of exceptions). The single biggest disadvantage I see with front end apps is that comprehending state management v…
Hi, I'm a Redux maintainer. Any specific concerns that I can help with?
You might want to check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:
Re: You probably don't need a single-page app
#264Coming from similar background as author (various legacy web apps with all the challenges of learning now useless js frameworks) - I’m now have a different opinion: SPA approach should be the default unless you have specific requirements to add html SSR (and even then google is pretty good at indexing public spa content too). So, respectfully disagree.
You're disagreeing, but not providing any justification for why SPA should be the default. Why do you think this?
I'll try adding to the conversation by at least justifying why I like SPAs: clearly decoupled front-end/back-end logic, likewise parallel updates/deployment from different teams, back-end mocking, minimal data updates for DOM changes, easy integration with microservices, powerful front-end tools to deal with client feature creep (e.g. interactive widgets), reusable UI components, easy migration to multiplatform desktop apps (e.g. Electron), possible single language for everything (JS, rather than a mishmash of JS/HTML/CSS/Python/PHP/etc), easy integration with hybrid or SSR stacks ( Next.js, Gatsby, etc).
But all this is just rationalization for one simple fact: I'm vastly more productive building SPAs. I know the tools, and I can quickly deliver anything from simple sites to richly interactive experiences very quickly. I can go from SPA -> SSR (via, say, Gatsby) easily. But going the other direction from SSR to something interactive has been far more painful for me. That's why I default to SPAs and adjust from there.
Re: You probably don't need a single-page app
#265This. So much this. My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well. Since the a…
Anytime you rewrite 12 existing, working web apps in something new it is going to be a huge pain. The only sane way to approach this is the strangler pattern, picking one page/view in one app to rewrite, then another, hooking them up with some kind of client-side router, and slowly letting the SPA consume the old SSR pages.
That way you can measure the cost/benefit of each page before deciding it should be added into the SPA.
Re: You probably don't need a single-page app
#266Earlier quoted context omitted.
I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all. Compared to client side rendering discrete web requests with minimal templates; you usually get much better…
This is a load of nonsense. If you can't separate concerns in a hybrid MVC pattern, you'll be screwing it up just as much in an SPA. Plus you've got the extra layer of an API to maintain too making it even more complicated, and more likely to spaghettifi, not less.
I definitely view being forced to build a sane API as one of the perks of a SPA. Having worked on some PHP pages with SQL queries, HTML, CSS, & JS all in a single file you would be surprised how people fail to separate concerns when they aren't forced to.
Re: You probably don't need a single-page app
#267One of the biggest reasons I reach straight for React is that I then have only one UI language. Instead of templating on the server in python or c# and then doing any UI updates in javascript on the client, I only have to write templating code in React and it runs on client and server.
You switched from a C# or Python backend to node.js so that you can render React on the server, correct? Or are you doing something fancy to serve react.js rendered contents from a non-js backend? I agree that the hybrid approach of both server-side templates and SPA-controlled content looks difficult.
Personally, I don't use node.js as a backend. I normally use Django REST Framework (DRF). I may do server-side rendering of the client using express, still calling back into DRF for the data. The important piece for me is that I don't like the idea of generating a page in one language and then mutating the UI on the client side with another language. I just use one language for the whole UI.
Re: You probably don't need a single-page app
#268Earlier quoted context omitted.
I completely agree that a big part of this conversation falls on ensuring code quality is maintained over time, regardless of the architecture you choose. Fortunately, I inherited a set of pretty well-maintained SSR rails apps, and they've been pretty straightforward to continue working on (with a couple of exceptions). The single biggest disadvantage I see with front end apps is that comprehending state management v…
Hi, I'm a Redux maintainer. Any specific concerns that I can help with? You might want to check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-starter-kit.js.org
i love redux - surface area for bugs is reduced so much compared to the past. thanks!
Re: You probably don't need a single-page app
#269Earlier quoted context omitted.
I understand the toolchain juuust fine. I have been making HTTP and browser applications for two decades. The technology landscape is absolutely ridiculous if you want to do things for the web. Each browser has its own standard, chrome is the new IE6, the industry is hacking together assembly languages to port from other technologies, preprocessors, minification, state and what have you not. The web today had been tw…
chrome is the new IE6 I've heard this repeated a few times, and it's utter nonsense. Unless you're deliberately going off into the weeds, a full featured SPA works the same on Chrome, Safari, Firefox, and Edge. I don't even bother testing on multiple platforms anymore; they just work. I did web development in the IE6 era (and before). This is nothing like that.
I do believe the live standards from whatwg is a good example of some vendors making it possible to implement features before other vendors do.
It creates a gap, it creates a constant drive forward which again seems, IMO, to sometimes be about vendor competition instead of the greater good of the web.
Re: You probably don't need a single-page app
#270This. So much this. My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well. Since the a…
Anytime you rewrite 12 existing, working web apps in something new it is going to be a huge pain. The only sane way to approach this is the strangler pattern, picking one page/view in one app to rewrite, then another, hooking them up with some kind of client-side router, and slowly letting the SPA consume the old SSR pages. That way you can measure the cost/benefit of each page before deciding it should be added into…
I have had to do this approach before - I hate it so much.