Author seems to think the goal of SPAs was to simplify web dev, but it’s actually to allow you to build fully featured, highly interactive, apps in a browser. What the author is really getting at, I would guess, is that front end dev is awful, due to this weird combination of the Blub issue and a historical trajectory that has caused many problems. The blub issues is mostly simple enough to pin down. Experienced prog…
What is a "blub issue". I tried a slang dictionary but couldn't find anything. Thanks.
If Not SPAs, What?
321–330 of 456 posts
Re: If Not SPAs, What?
#322HTMX https://htmx.org/ LiteDOM https://litedom.js.org/ Stimulus https://stimulusjs.org/ Turbolinks https://github.com/turbolinks/turbolinks
I am quite a fan of HTMX and am using it for multiple projects now. I hope it continues to gain traction.
Do you have any examples or favorite articles about using it? I'm exploring the space, but have really limited time to sit down with all of the different options today. HTMX is one that is very intriguing.
Re: If Not SPAs, What?
#323I think Phoenix Live View is maybe the most compelling story around this ( https://github.com/phoenixframework/phoenix_live_view ). I'm moving a side-project from React/SPA to Phoenix live view and it's kind of amazing to get the dev ergonomics of a server-rendered page with the UX benefits of a SPA. This course is a pretty great intro: https://pragmaticstudio.com/phoenix-liveview
It's still not a silver bullet. There's lots of things in a LV driven app where you're still wondering what front-end library to use with it.
Typically you wouldn't use LV to handle:
Menu dropdowns, tooltips, popovers, modals (in some cases), tabs (when you don't want to load the content from the server) or things that change the client side state of something but don't adjust server state. That could be things like a "select all" checkbox toggle where that doesn't do anything on its own other than select or de-select client side check boxes or toggling the visibility of something. There's also things like wanting to copy to the clipboard or initiating stuff to happen on drag / drop (like animations).
Basically you'll still find yourself wanting to use JS with LV. Whether that's Stimulus, Alpine, Vue, jQuery, vanilla JS or something else that's up to you. But I do find most of the above necessary in a lot of web apps I develop.
Re: If Not SPAs, What?
#324Earlier quoted context omitted.
Kubernetes is the biggest joke. I remember working with a sysadmin who worked for The Guardian provisioning servers remotely as demand spiked. This is pre-AWS. He used Puppet and remarked that you would only ever need what he was using for managing massive fleets of servers. Then Kubernetes and Docker arrived, which were intended for even bigger deployments in data centres. Before you knew it, just as with SPA's, Kub…
Also never underestimate the power of a single bare-metal server. Today everyone seems to be in the clouds (pun intended) and has seemingly accepted the performance of terrible, underprovisioned VMs as the new normal.
In the world of crazy SEO and ridiculous demands by Google for lighthouse score if the page is not static, the competition wins.
Re: If Not SPAs, What?
#325I think there is another layer to that conversation. Frameworks become bureaucratic and boring because they are developed by large teams for large teams. Most developers are working on small projects and need more fun and less maintaining huge amount of boilerplate code that recreates the browser. The framework that I feel makes development less ugly is svelte. But still, I really don't like the idea of heavy client…
I went down this route recently. There are a couple of different options depending on your preference: • Write the glue code yourself if you only need svelte on a few pages • Inertiajs if you want to replace your view layer with svelte
Wow, InertiaJS looks like exactly what I've been wishing for. Component-driven SFCs in Vue are the best tool I've used for interfaces in 20+ years, but I don't love having an API layer between the client and server. This is really interesting. Do you have experience with it and know how it handles frequently live-updating pages?
Re: If Not SPAs, What?
#326I have been using Ruby on Rails with Vue.js + Inertia.js and honestly my productivity has skyrocketed. I don't worry about writing APIs for the frontend, no need to maintain separate router on frontend and no state management required. Using this stack I'm able to build a highly reactive apps with minimal efforts.
Do you have any examples or favorite articles about this? I just learned about inertia from this thread and your set up is similar.
Re: If Not SPAs, What?
#327I've always felt this problem from the first time I touched Angular. It was just so much more complex and fragile without actually a lot of benefit unless you wanted to make a really interactive async application like Google Docs or Facebook Chat. When SPA's became the norm and even static web pages needed to be build with React, developing became more and more inefficient. I saw whole teams struggling to build simpl…
When SPA's became the norm and even static web pages needed to be build with React I'm in a weird situation where I'm contracting into one organisation and they've contracted me out to another. The first organisation know me as a senior dev/architect with 15 years experience in a niche domain. The second organisation see me as brand new to them and despite paying an embarrassing day rate are giving me noddy UI tweaks…
Honestly when they come with decisions like that, I'd like them to spend some time on a formal writeup - have them prove they understand the problem, the existing solution, the issues with it, and why React or technology X would solve it. Have them explain why they / their employer should spend thousands on changing it.
I mean it'll only take them an hour or two to write it up, better to spend that than the 20 hours it would take you (for example) to spin up a new stack.
Re: If Not SPAs, What?
#328I think Phoenix Live View is maybe the most compelling story around this ( https://github.com/phoenixframework/phoenix_live_view ). I'm moving a side-project from React/SPA to Phoenix live view and it's kind of amazing to get the dev ergonomics of a server-rendered page with the UX benefits of a SPA. This course is a pretty great intro: https://pragmaticstudio.com/phoenix-liveview
It's still not a silver bullet. There's lots of things in a LV driven app where you're still wondering what front-end library to use with it. Typically you wouldn't use LV to handle: Menu dropdowns, tooltips, popovers, modals (in some cases), tabs (when you don't want to load the content from the server) or things that change the client side state of something but don't adjust server state. That could be things like…
> It's still not a silver bullet. There's lots of things in a LV driven app where you're still wondering what front-end library to use with it.
> Typically you wouldn't use LV to handle:
> Menu drop dropdowns, tooltips, popovers, modals (in some cases), tabs (when you don't want to load the content from the server) or things that change the client side state of something but don't adjust server state.
My experience is that LiveView is fine for all but the last use case. And while in practice I often don't really need to keep things client-side-only, when I do it's often pretty easy to just write a bit of js and, if necessary, use hooks and events to communicate with the surrounding LiveView(s).
In fact, I vaguely recall that in the early days of LV, the creator himself argued that it should be used for just 'smaller interactive stuff'. Over time, we all discovered that LV does surprisingly well for SPA-type use cases (and as a result we now have stuff like router-level LiveViews (that take over the whole page), live_redirects, url updating, and so on).
> That could be things like a "select all" checkbox toggle where that doesn't do anything on its own other than select or de-select client side check boxes.
Why wouldn't you just keep that within the server-side state LV paradigm? I've done just that in a project I'm working on.
> There's also things like wanting to copy to the clipboard or initiating stuff to happen on drag / drop (like animations).
For those things you write js, yes.
> Basically you'll still find yourself wanting to use JS with LV. Whether that's Stimulus, Alpine, jQuery, vanilla JS or something else that's up to you. But I do find most of the above necessary in a lot of web apps I develop.
Absolutely, but I'm continuously surprised how little of it I need, and how often I /think/ I do just because I haven't quite wrapped my head around the different paradigm.
Re: If Not SPAs, What?
#329Earlier quoted context omitted.
It’s remarkably efficient and simple: https://stackexchange.com/performance For those who are discouraged by the massive complexity of Kubernetes/Terraform and various daunting system design examples of big sites, remember you can scale to a ridiculous levels (barring video or heavy processing apps) with just vertical scaling. Before you need fancy Instagram scale frameworks, you’ll have other things to worry about l…
Wow. Stack Exchange is a curious case study. I share the general HN sentiment over microservices complexity but just to play devil's advocate... I suspect that server cost in this case is asymptotic. If the (monetary) cost of SE's architecture is F(n) and your typical K8s cluster is G(n), where n is number of users or requests per second, F(n) very large. In essence, the devil's advocate point I'm making is that mayb…
I can't recall reading much on how going for 'the cloud' or 'serverless' saved anyone money. On the other hand, I've read my fair share of horror stories about how costs ballooned and going for the old-fashioned server/VPS ended up being much, much cheaper.
The main argument in favor of the 'cloud' is that it's easier to manage (and even that is often questioned).
Re: If Not SPAs, What?
#330My argument for SPAs rests on the completely subjective yet I feel incredibly powerful impact of latency. When anything takes more than 50ms to react, it becomes mentally jarring to the user. Whether it is typing in an SSH session, clicking a menu with a mouse, auto-completing a box, etc - all these things generate a completely different human response and relationship with the application if they get below that thre…
I've designed and programmed highly interactive SPAs for customers large and small, and the reaction is invariably "I can't believe this is a website, it feels like an app". Being non-technical, they can't put their finger on it, but I know that while the base design plays a part, so does the concrete UI implementation.
I wonder how many of the people crapping on SPAs are actual front-end or full-stack app devs, or otherwise people developing very close to the UX.
I'm sure there are some disgruntled UX devs who are running back to SSR, but when I come to the bimonthly "SPA sucks" thread on HN, for the most part it feels to me as though the critiques are coming from people for whom UX and front-end development are secondary concerns.