371–380 of 522 posts
Earlier quoted context omitted.
Not contradicting you, but how did you evaluated that the SPA is not bringing any value to the customers? It may make work harder for you, it may cost more, but maybe that cost is rightfully justified from a business perspective.
As a consumer of SPAs all across the internet, all I seem to get is a bunch of janky, slow, bloated, buggy experiences. Server-rendered views just seem more performant and reliable when done well.
Unpopular 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 finish…
Earlier quoted context omitted.
With gmail: Move your mouse pointer down to the lower right corner of the tab. Do a forced refresh (Ctrl+f5) and you'll see some text pop up while it's loading, one of which is a link to a basic HTML version of the site. Click on it and you're back to what appears to be almost the original gmail interface. Up the top of the page you'll see an option to make it default. It's super fast. Almost absurdly so, compared to…
There is a direct link to access basic HTML version of GMail : http://mail.google.com/mail/h/
Earlier quoted context omitted.
You overlooked this part: > Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks
Yeah, I don't buy that. React and Vue are dead simple.
But if the comparison is with more traditional SSR sites, React and Vue are also not doing everything the back-end was doing before.
Earlier quoted context omitted.
You overlooked this part: > Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks
You simply trade back-end frameworks complexities for the front-end framework complexities. With the right architecture there is no huge difference IMO, just of course you also need to upgrade your teams so that they can handle a lot more tasks on the front-end than with SSRs (and you'll probably need less back-end devs)
Not necessarily, you can have simple and modular front-ends while also having less complex back-end frameworks. The question is between SPA and non-SPA web applications, not between SPA and JSP/PHP.
Earlier quoted context omitted.
Separate frontend from backend development and make it even two teams. This makes it much more robust and loosely coupled because both sides protect the interface from each other.
This works. Now you only need double the engineers to create the same app as you would using a server side framework. Hardly a more powerful argument against SPAs than this.
That may not always be the case, but if your SSR team and API team are the same size, your devs suck, bluntly. API based backends are much easier to build, test, manage and look after.
Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big…
When working with static pages that have minimal interactivity, sure. Just render the HTML and send it to the client.
Once you get past that though, if you try to stick with SSR you'll end up with incredibly difficult-to-decipher mish-mash of if/then statements, most likely with lots of jQuery or equivalent thrown in. I've debugged such templates and they are universally messy, not just because they are usually written by backend engineers who have a minimal understanding of/appreciation for JavaScript, but also because keeping track of state with such templates is really inefficient and frustrating.
Earlier quoted context omitted.
It's funny how Google has been banging on about "just a few milliseconds of extra loadtime and your bounce-rate increases!" while in Gmail it's like they think the product is so good, people should be willing to wait 10 seconds to view their _mail_. The reason I'm even reading this comment section is because I wanted something to do while waiting for Gmail to load.
If Gmail is taking 10 seconds to load it might be worth your time to consider a faster computer for your own sake. It can be like 3-4 seconds on a faster computer.
For new development, I reach for SPA tools (like VueJS with Webpack) fairly quickly. The reasons for this are: 1. Reusable web components. 2. Clear separation of backend and frontend logic. 3. Using the latest version of javascript. I really like HTML/CSS/JS as tools for building GUIs, but I feel HTML/CSS specifically suffer from the inability to make components. I think there are definitely instances where there is…
Are you familiar with CustomElements? https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
Totally agree with the article, the spa hype has produced a lot of crappy slow web sites and crippled productivity of many teams for years. I think ppl in the industry are way too young and have the bad attitude to nod add tools in their belt but keep only the last one that has hype. Spa are like applet or Silverlight, just different tech, same goes for ws* vs rest api and so on...
> I think ppl in the industry are way too young and have the bad attitude to nod add tools in their belt but keep only the last one that has hype. The current culture is to only keep a job for ~2 years before moving on, why wouldn't they adopt that attitude?