Live data from Hacker News

If Not SPAs, What?

macwright.com

261–270 of 456 posts

Re: If Not SPAs, What?

#261
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 programmers know that JS is an awful language. But there’s also a tooling or SDK “blub problem”. For example, compare npm and webpack vs gradle and javac (not to defend the Java ecosystem, but it does get some things right, or more right than others).

More idiosyncratically, there’s this historical arc of encountering fundamental problems, and trying to solve them within the current constraints of the web, rather than perhaps waiting for the web to standardise and evolve. This seems to be a mixture of lack of experience outside of this ecosystem (a bit like Blub) and, for this and other reasons, fixing problems “in your app” that should be fixed in the fundamental infrastructure of the web. It feels like technical solutions to social problems or, to use another metaphor, we are patching downstream what should be fixed upstream... if you build a house on sand, it will never be robust, no matter how many layers of infrastructure you add. That’s where the complexity arises.

It’s an enlightening exercise to step back and ask how you would build SPA infrastructure if starting anew. You certainly wouldn’t use a language like JS, you certainly would want to provide visual design tools as far as possible, APIs would be replaced with standard protocols, and probably you’d use a relatively small XML for layout. So perhaps only the HTML is anything like what you’d use. There’d be no transpilation, no webpack, no polyfills, no CSS, no JS.

In fact, what you’d end up with would look remarkably similar to the dev process for a Java applet!

Re: If Not SPAs, What?

#262

I think if Chrome changes to the omnibox really click. The need for SPA in general will dwindle. You cannot see the URL so if it is ugly who cares. And if the page refreshes fast enough most end users will not be able to tell you are on a SPA or not.

SPA has nothing to do with URL. If your SPA uses a routing/history solution so deeplinks and history and the back button work properly (and it should), it's exactly, in terms of URLs, like what you'd naively expect from a non-SPA app.

Re: If Not SPAs, What?

#263
post #134
post #37

I'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…

> developing became more and more inefficient Anecdotally I find the opposite to be true. I've been writing frontend code for over a decade, but I've never moved faster and wrote less buggy code than now. Is that because I've become a better developer? Sure, a little bit. But by and large, I don't believe that ultimately is the reason. I think it's the maturity in the technology. My growth as a programmer is hardly l…

>What I believe, is that the bar to build web applications has been lowered,

Yes, the bar to build web applications has been lowered. We can all build something on the level of GMail now.

The ability to build websites has been crippled, because you are often forced to build the sites using the tools suited to applications. As you and both the parent comment seem to agree on.

Re: If Not SPAs, What?

#264
post #232

Earlier quoted context omitted.

> Frontend tooling has never been better than it is today. What's the library or design pattern to consume a REST API in React or any of the mainstream front-end frameworks? The only thing I'm aware of is Ember Data but Ember is apparently not cool anymore, and I couldn't find a suitable replacement. I'm asking because in all the projects I've been involved with, consuming the backend API always felt like a mess with…

For what it's worth GRPC-Web is a pretty nice solution here. My team generates backend stubs from our GRPC spec which allows us to jump right to implementing our business logic. Frontend projects make use of the GRPC-Web client codegen to make calling the API simple and type safe (we use typescript). We mostly use all the official GRPC tooling for this. We write backends in golang and dotnet core so GRPC-Web is suppo…

Yeah, after experiencing type safe APIs + editor integration with TypeScript I don’t think I can go back.

There are, of course, other solutions besides GRPC.

Re: If Not SPAs, What?

#265
post #134
post #37

I'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…

> developing became more and more inefficient Anecdotally I find the opposite to be true. I've been writing frontend code for over a decade, but I've never moved faster and wrote less buggy code than now. Is that because I've become a better developer? Sure, a little bit. But by and large, I don't believe that ultimately is the reason. I think it's the maturity in the technology. My growth as a programmer is hardly l…

> Frontend tooling has never been better than it is today.

eh. Swing in its golden age run circle around what we have now. Granted it's old tech now that we settled for in-browser delivery, but still:

- look and feels could do theming you can only dream of with css variables/scss

- serialize and restore gui states partially or whole, including listeners

- value binding systems vue can only dream of

- native scrollers everywhere you could style and listen to without the rendered complaining about passive handlers. - layout that didn't threw a fit about forced reflows

- unhappy with the standard layouts? build your own one as needed

- debug everything, including the actual render call that put an image where it is

- works the same in all supported os

browsers are an insufferable environment to work within compared to that, css is powerful and all but you get a system you can only work by inference, and were everything interferes with everything else by default, which works great to style a document and is a tragedy in an app with many reusable nested components.

Re: If Not SPAs, What?

#266
post #151

The fundamental problem is not that the SPA pattern is bad, is that it takes a lot of skill and effort to make a proper SPA. Obviously, skill and time are scarce resources and the result is that most SPAs are crap. OTOH all these component based frameworks have definitely brought us a much better way to produce interactive experiences compared to the jQuery days. This is not related to SPAs at all. You can use React/…

No, it doesn’t take that much skill. I think this is the source of the problem. The stupidity and hostile fear of originality I detect in this these comments is a very real reflection of my professional experience. This, dependence on frameworks and inability to imagine anything beyond the common SPA, really scares the shit out of me knowing I will be coming home from a military deployment soon and returning to the c…

> No, it doesn’t take that much skill.

That is a pretty bold statement to make.

Re: If Not SPAs, What?

#267
post #8

I 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

Blazor Server (https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor) is similar. It's a very productive environment.

Re: If Not SPAs, What?

#268

Earlier quoted context omitted.

> These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. I think this is one area where front end tooling can be painful for the average dev. The bar to writing idiomatic JS for a given framework can get pretty high quickly, especially when you look at some of the really popular tools out there (i.e. redux). Front end work has become so much harder to grok because t…

A good starting point to explaining reducers is that you are reducing two things into one. A redux reducer: The action and the current state reduce into the new state. And of course it doesn't matter how many reducers or combined reducers your state uses - they're all ultimately just doing this. This also works for Array.prototype.reduce(). You're reducing two things into one.

The concept of a reducer isn’t the hard part of Redux... it’s designing your state, organizing actions/reducers/selectors, reducing (no pun intended...) boilerplate, dealing with side effects and asynchrony, etc.

Re: If Not SPAs, What?

#269

Earlier quoted context omitted.

> These inexperienced people are put in charge of designing codebases that don't scale and become spaghetti. I think this is one area where front end tooling can be painful for the average dev. The bar to writing idiomatic JS for a given framework can get pretty high quickly, especially when you look at some of the really popular tools out there (i.e. redux). Front end work has become so much harder to grok because t…

What most people have in mind as "idiomatic JS" isn't that. It's usually meant to refer to some patterns that appeared and started getting popular around 8 years ago. And often, code written in this not-idiomatic way works _against_ the language and/or the underpinnings of the Web in general. It's just that the circles promoting the pseudo-idioms have outsized and seemingly inescapable influence.

This is very vague. Can you give some examples?

Re: If Not SPAs, What?

#270

Earlier quoted context omitted.

Stackoverflow -- the website that every developer uses probably all the time -- is an example of a site running on a very small number of machines efficiently. I'd rather have their architecture than 100's of VMs.

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 maybe development converges towards microservices because cloud providers make this option cheaper than traditional servers. We would gladly stay with our monoliths otherwise.

I tried to contrive a usage scenario to illustrate this but you know the problem with hypotheticals. And without even a concrete problem domain to theorize on, I can't even ballpark estimate compute requirements. Would love to see someone else's analysis, if anyone can come up with one.

Post reply on HN