Hacker News Reader

Comment by s__s | Hacker News Reader

> You probably shouldn’t build websites as SPAs but you probably should build most apps as SPAs.

As a frontend dev this has always been my stance, but I’ve been consistently shunned for it.

How much of that was naïveté vs. misaligned incentives I’m not sure.

In any case, these thing always leave me with the feeling the industry is getting way too saturated with script kiddies. It just feels immature, and the culture that’s grown around web dev seems to reflect that. Or more likely I’m just bitter and old.

View on HN

OS developer here. You’re all naive children playing in our sandbox, arguing over what color to paint your sandcastles.

Or more likely I’m just bitter and old.

Purity: https://xkcd.com/435/

Farmville Devs <- Facebook Devs <- Chrome Devs <- OS Devs <- Chip Devs <- Factory Devs

It's almost like their small differences come with some narcissism.

App developer here. Your sand sucks and it's affecting our apps!

Make your own sand then.

https://youtube.com/watch?v=YSYFs7Y1fFI

… and then go pound it?

Speaking from personal experience, those aren't mutually exclusive.

We need a hardware dev to chime in

If you feel old you should try Next.js. I dove into it recently and joined the Discord channel, sometimes I answer questions. It is really interesting helping people who are creating complex apps by stitching together a bunch of npm modules while having absolutely no clue about the underlying implementations, or the basics of web dev and javascript.

And the meta-interesting thing is, once the abstractions get good enough, that is the correct direction for things to move in.

The abstractions are not, however, good enough yet.

People largely don’t think for themselves, every once in a while the firmware gets updated and they have a new opinion. All you can do is pick your battles, there is finite amount of credits to spend.

We are bitter and old, but that doesn't make us wrong ;)

I liked to put the line between whether you're required to sign in to use it or not. If none of the data was necessarily publicly accessible anyway, that's more of a spa suited interface

Not sure that heuristic works. For many people, the major destinations that require a login are paywalled content sites.

Well, it would be one of many. Considering building an SPA for a paywalled content site would be a little surprising to me in the first place, but it would make a lot of sense to me for any of the behind-the-scenes or account management facilities you'd only ever see once you've logged in. I wouldn't expect the content view to either be sufficiently interactive on its own, or sufficiently interactive when coupled with other aspects of the UI, to require the complexity of an SPA at all.

What do you think the full set looks like?

Once you start adding conditions and context to the heuristic, it starts to look a lot like a Design Pattern.

The full set would be something like who the target market is, whether it's a completely internal or completely standalone thing that just happens to be built with web tech, whether it's intended to be offline-capable and whether there's a lot of state involved in the interactive capabilities of most views, should there be the capability to do any kind of concurrent UI things like picture-in-picture video while someone navigates the rest of the screens and changes data frequently, and then the importance/complexity of maintaining a high-level of accessibility.

What I was describing could maybe be conceptualized as multiple applications that serve one larger site. You have the public facing staticly rendered site, built in whichever way, but that ultimately has accessible rendered content on page load and as fast as possible. Then you also have interfaces to the data that is rendered there, which might be completely separate codebases for different purposes.

These could also take place in things like a reporting portal inside a company, where stakeholders need to regularly see static or filterable reports of pre-rendered data, and then you have other internally available apps that different departments can use to manipulate that data in ways that they can easily receive immediate feedback on whether or not it's valid or how it looks etc..

I’m also surprised how people can’t see the benefit of have 1 way of doing things. 99% of the websites end up in app like features.

Maybe we don’t talk about the same thing, but isomorphic code with react is great for websites too: server side render, instant page change on client side. Reuse of exact code. Huge benefits.

Reply on news.ycombinator.com