3 ms·
I tend to agree here. I don't blame SPAs (not that i think you are), but it does feel like there is correlation between SPAs rise in usage and with the fronten
by intothemild 4y ago
I tend to agree here.
I don't blame SPAs (not that i think you are), but it does feel like there is correlation between SPAs rise in usage and with the frontend becoming worse.
Not that it's the tool, but the welder of the tool.
I'll explain, I think that basically a lot of frontend engineers started using SPAs for too many different usages... Like using a SPA instead of a static page for a really simple basic website.. to me this is like when a meeting could have been an email.
Or adding in so much tooling to their site which doesn't really solve any problems except make new problems, so now there's more tooling for that. (read state management, client side routers)
I remember at a <very popular SPA> conf I spoke to the two guys who made a very popular framework for building that popular SPA, they asked me how my serverside project used express.js's router... Like the questions they had were along the lines of "how can you do (insert basic routing thing here) in express?". The only exposure to express they had was a catch all route to their apps main clientside router.
I was stunned... They were aware there was this tool, and ignored it.. instead deciding that they could do better.
To me this was post SPA frontend in a nutshell.
- ChadNauseam 4y agoYou acknowledge that it's the wielder of the tool, but I feel a need to repreent the SPA evangelism strike force because they're just so freaking cool. The web is a UI framework with features that are actually pretty hard to find elsewhere. It has native support for: tabs, forward and backward, zoom, and coolest of all, links so you can send the current UI view of an application to someone who's never heard of it before and they can open it up in seconds. All of those apply to regular websites too, but SPAs allow you to write actual apps in a way that doesn't want to make you pull your hair out. And it's often possible for a well-designed SPA is indistinguishable from a native site. I maintain my personal website as a SPA. When I posted a monad tutorial on my site [0] to HN, not one person complained that my site is slow (it isn't) or that it doesn't work with JS disabled (it does [1]). Plus, when you hover over a link, it uses some SPA magic to prefetch the page you're going to visit, so the transition is even faster than it would be on a typical site. This is the archetypical case of "using a SPA instead of a static page for a really simple basic website" and I think it works really really well. There's definitely some room for improvement. I'd love to be able to make it a bit smaller by rewriting it in Rust through WebAssembly, but it's not quite there yet. [0]: https://news.ycombinator.com/item?id=30762281 https://news.ycombinator.com/item?id=30762281 [1]: except on pages that can't be implemented without JS, like https://chadnauseam.com/reasoning-quiz/ https://chadnauseam.com/reasoning-quiz/ or https://chadnauseam.com/productivity/rational-breaks/ https://chadnauseam.com/productivity/rational-breaks/
- int_19h 4y agoFWIW these features are not unique to the web. WPF offered a page-centric app navigation model for desktop apps, complete with forward/backward, history etc, since 2006 [1]. I haven't seen it actually used much though. And, to be honest, I don't think I'd want a desktop app to use it, unless it does something that is naturally represented in that paradigm (most use cases are not). [1] https://docs.microsoft.com/en-us/dotnet/desktop/wpf/app-development/navigation-overview https://docs.microsoft.com/en-us/dotnet/desktop/wpf/app-deve...