51–60 of 111 posts
We use Vue + Firebase and even have SSR working w no complaints. (So it's actually more than just a SPA)
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 n…
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.
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…
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.
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.
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 o…
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.
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 fr…
> 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. I…
I'm open to hybrid being defined as two possible things: a regular SPA with server side rendering (SSR on manual refresh and first visit). Nextjs for react, Nuxtjs for VueJS, angular universal. I think OP was talking about the other definition of hybrid.
The second definition is for when your team prefers or is only trained in or is maintaining codebases in the legacy MPA style, typically similar to Rails+jQuery. When you need a specific div element to have advanced UI components and a jQuery plugin didn't fit the needs, the answer was "not happening". VueJS showed up and changed this to "can budget finite dev hours and willing to maintain", as it had good tutorials for assuming you wanted a small widget instead of a full rewrite to SPA. Do this enough times, and you have a hybrid. Now you have enough SPA-ness that you can be satisfied or you can plan a multi-sprint "convert the rest to SPA" project.
One thing I'm noticing about SPAs is that they're often slower to load, but the slowness and loading animations gives me a higher perception of the quality of the application. The same application loading and doing things instantly as server-side templates feels comparatively cheap and un-modern. What is wrong with me?
Do you ever find some animations to be lower quality than others? E.g. a pop up with a progress bar being lower quality than a spinning wheel? That might be another sign.
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 r…