Hacker News Reader

Comment by pier25 | Hacker News Reader

He has some great points.

For 5 or so years I've been the guy who immediately started a SPA and I've turned 180 degrees. I now think SPAs are basically a cancer, with some exceptions where an app-like website is justified (Gmail, etc) or a hybrid app. SPAs introduce unnecessary complexity and bloat for the vast majority of use cases.

View on HN

The html version of gmail still works great! It also loads in under 30 seconds (near instantly for me) and is incredibly snappy. It also doesn’t look like a PM vomited google product integrations over the screen.

> It also loads in under 30 seconds

Jesus Christ what is going on with the web.

I have a theory. Search is a Killer Feature. And I mean that in the most extreme and broadest way possible. The user interface paradigm of "type a bit of what you want, hit enter, click and immediately be using what you want" was, in hindsight, what users wanted/needed. It was so completely successful that nothing else mattered. It didn't matter that web apps are fundamentally flawed, introducing ridiculous latency on all the other simpler interactions (would you tolerate 200ms latency for a clientside application to respond to you clicking a button?), throwing away all of the work done to create and present unified user interface elements, enabled every click and action to be surveiled, profiled, and datamined, added points of failure completely outside of the users control, locking user data away in someone else's systems, etc. None of that could outweigh the gargantuan power and usability of search. Desktop OS' still aren't treating search as a first-class citizen. You still can't just search and be using a new application nearly immediately. Mobile gets close with their app stores, but there's still friction there. Even though the W3C adamantly refused to acknowledge the web as a platform for interactive applications for 2 decades, it just kept growing and more was shoehorned into their static document presentation system no matter what they did. It amazes me how difficult it still is to find an application that does what you need, download it, install it, then launch it. Unsurprisingly, even that relies upon the web to accomplish the first searching portion. I like to dream that perhaps we are approaching a sort of convergence, though. The web makes sandboxing less and less relevant as users data is all migrated into remote services (protecting your data is what sandboxing was FOR, right?) while desktop OS are making clientside sandboxing and containers easier and easier. Technology never fails to be interesting to watch while it develops alongside us.

I don't think this is true at all. In fact, I have a hard time believing users actually prefer the web over native apps at all. As you say, web apps are pretty terrible. They will never be as fast or reliable as native apps.

> You still can't just search and be using a new application nearly immediately.

You can't? I sure can. Gnome, kde, and Mac all have great ways of searching through your apps. The windows search is a little crap.

But the great thing about a local, native environment is that the user is actually in control. If there is an app I need quick access to, I can map it to a shortcut or desktop icon. That's way faster that searching and scrolling through results.

From my non web dev perspective, the reason there is such a proliferation of bloated web apps is because of the devs. All of a sudden we have a ton of developers with little to no formal training who want to make cool apps instead of good products. So they layer on plenty of dependencies. And when there's a Cool New Framework© next week, they'll incorporate that too.

I just don't think devs have performance and user experience as number one priorities. The web will always be horribly slow compared to an SSD. In my opinion, the web has a couple of other fatal flaws that make it inferior to native for applications. But if we do want the web to be where all our applications to live anyway, we need to be concerned about performance as a high priority.

> You can't? I sure can. Gnome, kde, and Mac all have great ways of searching through your apps

He was talking about using new apps, not already installed ones.

And the Windows search works fine as long as you disable Cortana... As sad as that is.

> type a bit of what you want, hit enter, click and immediately be using what you want

This is a nice idea, but it’s far faster to search with mail.app. The great thing about gmail is just labels.

"SPA" is a fine, if difficult, architectural pattern. One needs to make a distinction between the processes and tools, and the pattern itself. SPAs are bad because of how they are built; personally, I blame the rise of front-end build tools for this. When it's easy to add dependency after dependency, then you get a bloated nightmare. Transpilers don't help, either, since they just remove you even further from "bare metal" of the browser, which is itself already at a dizzy height from the bottom. You might say that modern javascript programmers are too high, so to speak.

JavaScript should be used like a condiment instead of a whole meal. It's led to the bastardization of the web in my opinion.

Like, all we have for dinner is tomato ketchup.

I'm with you. It occurred to me that what I love about things like react or vue has nothing to do with SPA capabilities. It's just developer ease in building reusable, composable, testable components.

I've had similar experiences with scaling too early into microservices for example. I need a seriously compelling reason to consider building around these paradigms now. The overhead is unreal.

Both great ways to solve a problem, but not really a problem I've yet encountered - ever.

I'm still glad I've had great opportunities to learn this, at least.

Thing is, building reusable components was always a feature of SSR Web frameworks since early 2000's, so there is no need for react or vue for bundle the HTML/CSS/JS that makes a fancy calendar widget.

And with WebComponents being supported across the board, even less so.

Web components are useless, you can't pass values around without converting them to string or employing a non-native mechanism, and of course you need to do all DOM updating by hand - which is both way worse than just using React from various perspectives.

Web Components are HTMLEelement instances, which are ordinary JavaScript objects on which you can set properties without any "non-native mechanisms":

`document.querySelector('div').someProperty = {some: 'value'};`

For DOM updates you will generally use a declarative DOM rendering engine like lit-html, just like how you use React's VirtualDOM. In fact, the most popular Web Component "library" [LitElement](https://lit-element.polymer-project.org/) uses very simlar vernacular as React (like the `render()` method), and from a developer perspective feels exactly like using React, except it relies more on builtin platform features.

Only from the point of view of React devs with their anti-WebComponents agenda.

Everyone else is just embracing them.

There are no tools to embrace them, there is no way to make an universal web component like you can do with a React component without severely limiting what you can do and how you can develop it and how it performs. It's very sad, I'd love to use native Web Components but it's so bad it hurts (or you end up reimplementing incompatible React).

You're not understanding what web components are.

They alone are not a replacement for the entirety of frameworks, they are low level hooks that standardize the more fundamental level of frameworks: component instantiation, component lifecycle, and style and DOM encapsulation.

Higher level features like DOM rendering are left to libraries, and there are some really good libraries for that. And I'm not sure what you even mean by the libraries limiting what you can do how you can develop. There's way more choice in the web components ecosystem than within any single framework.

I think the biggest difference is that I consider DOM rendering a low level feature that should be abstracted away lowest as possible.

Yep, again the anti-WebComponents message.

Angular, Vue, Polymer, Svelte and a couple of Web based RAD editors look like tooling to embrace them to me.

Since I don't have any plans to ever use React, how does your magical component work with my tooling?

My component is "magical" thanks to the React ecosystem and because it uses the tools the React platform provides to greatly integrate with said ecosystem. The tools you suggested are not comparable to React - React Hooks and Contexts are the part I'm most interested in.

If you use different tooling, then it doesn't work, and that's okay. You don't need to care about React and I don't need to care about Web Components. It was suggested that React is useless and should be replaced with Web Components, and I'm simply saying that Web Components are not sufficient to replace React, not that you should switch.

Naturally my tools are not comparable to React, because by targeting WebComponents they support everyone on the browser instead of the React developers silo.

And best of all, they are even usable from React.

Ofcourse you can pass properties, I'm afraid your information is wrong in both cases.

A small demo https://jsfiddle.net/zu52o7bq/.

Sorry but this is in no way comparable to what React Hooks, React Contexts and React component props offer, plus the non-existent component lifecycle. I even have to render it myself! Inside the component!!! Where is separation of concerns? And why do I need to register it? I just want a class/function that behaves like a component (with a lifecycle and managed rendering), no registration whatsoever.

These are not React-like components - independent reusable universal blocks that can be used without any knowledge of the component other than that it uses React.

You stated one can't pass props around and you have to resort to strings (this incorrect statement is posted to HN so often I'm curious where does this knowledge comes from).

I just proved you wrong with this simple demo, so you waved that away and pulled out hooks argument.

How is that related is beyond me (not to mentioned hooks are fresh in react world too). If you want to have a discussion at least have decency to not change subject randomly, it is annoying.

BTW. You can use both hooks (via haunted project) or redux (lots of people do that) with WC's just fine. In fact I wrote code that looks almost the same in react and lit-element.

I think we misunderstand each other because of terminology. You understood me as class props, but what I meant is component props: <Component prop={something} />. In React world this is different from class props because if the prop changes it also causes the component to update. React separates the component "template" (class or function) and "node" placed in the component tree, the props are updating the node contrary to WebComponents where you have a class instance directly. In WebComponents I have to catch the underlying HTMLEntity and then set the props on the class (in React we're not setting the props on the class itself, it's separated for the ability to handle updates) and then handle all updates myself instead of just passing the complex object as a prop.

Hooks are an extension of that - it is a different way to pass values around, a very powerful one.

Yes what you need to do as a workaround is a BUG in react, not a problem with WC's - and I think Dan Abramov tweeted that this will be solved eventually (I can't find the exact tweet) - In Vue, svelte, Angular or even preact you would be able to do <my-component prop={something} /> just fine, no need to mess with HTMLEntity. If this is fixed this should be transparent to you and work the same way, you should be able to mix and match both kinds of components.

See here https://custom-elements-everywhere.com/ a list of popular libraries and how they handle events and props.

I meant when I'm not using react

I have no idea what you meant by that statement.

I didn't talk about React-WC cooperation, I was talking about passing props around WebComponents when using WebComponents alone - it allows you to pass only plain values, otherwise you need the underlying HTMLEntity

I still have no idea what you mean by that, implementation detail? I have passed props using WC's alone in a declarative way via LitElement - all other popular solutions allow that too.

This is just so wrong. Where did you hear these things? You've obviously never actually tried web components.

So I can pass a complex value as a prop without needing to convert it or catching the underlying HTMLEntity? The tree will update once a property updates?

There is so much entertainment in SPA vs HTML and similarly Vim vs Visual Studio, static vs. dynamic types etc. debates. But to be boring (sorry!) it all comes down to the most approriate tool for the job. At work it's a SPA because it's an application delivered via the web. Delivering via not the web wouldn't work as well, and delivering it as not an application is a non starter.

My current side project is a HTML sprinkled with JS, turn off JS and you can use most of the site kind of thing. Why? Because ... well mainly SEO to be honest. But there you go ... reasons!

> But to be boring (sorry!) it all comes down to the most approriate tool for the job.

It does. But, depending on how you look at it, either most web companies absolutely suck at picking right tool for the job, or the job isn't really what you'd think it is.

Taking your typical plain webpage done as an SPA, you could either say (as I would) that the authors picked wrong tool for the job, introducing completely unnecessary complexity both on their end and customer end - or, you could tell that the job of that website isn't to be useful to and considerate of the visitor, but to be e.g. CV-fodder for web developers, a way for the team to show off their sophisticated infrastructure, or for the marketing to play their A/B testing shenanigans, or for the company to show off to the investors, etc.

Once you account for all the "parts of the job" that are orthogonal or even opposite to delivering value to users, suddenly a proliferation of frontend complexity makes perfect sense.

Google recently updated their crawlers to understand "full Javascript websites" ; I don't like the term spa as one could build one with pure css and html and still have a single page.

Now onto the js frameworks, it depends on which one is used. One could build a website watching web.dev and use a budget to make sure it's app is lightweight. There are numerous tools to make sure an app is properly made. But tbh, I like my js framework because the community is so great, I know the framework is good even tough there are arguments there and there.

I guess it all depends on the tool you choose and how you build your end product. Now having a website that loads in 30s is a joke I haven't experienced in the modern web, and my js framework actually provides a powerful caching system that makes the website available even tough I could bring down my dns. To this point I presume we are just in a odd point in web evolution where we have discovered a new paradigm and rushed into it's usage without maturity.

These things will change but I think it is important to know that some JS front framework are not incompatible with a lightweight web.

I agree completely, use the right tool for the job, it's just that the SPA pattern has been abused.

Bah, to hell with your boring moderate stance! I would much rather have endless debates with others about why MY hammer is better than their hammer, and ignore the fact that maybe not everything is a nail ;)

If you use the right tools, SPAs reduce complexity.

The problem is that most of the popular frameworks today add unnecessary complexity.

I still can't believe that we live in a world were most developers are OK to coding with a 5 to 15 second build delay and source mapping during development. I find is extremely frustrating. It slows me down and breaks my train of thought.

If you go the SPA route you have to, at the minimum, add some form of routing and manage application state and logic. It doesn't matter how good the tools for doing that are, there is always going to be an overhead to do that.

That’s a great synopsis of the tricky bits, which I’ve noticed provide the most value to unit test as well.

> If you use the right tools, SPAs reduce complexity

Like? I am curious: built a few SPAs (quite complex ones) and it sucked; I got the tools/frameworks from HN.

If you use the right tools ‘tradional’ websites are not complex either.

I do think that sometimes you just need a simple static website and then don't need an SPA.

I think SPAs are good when you have to handle a lot of dynamic data. Especially realtime data.

I built a sample SPA with VueJS, Asyngular and RethinkDB to demo how easy it is.

It's a relatively complex app where all the views update in realtime but all the server code is less than 300 lines.

The framework does most of the work; on the back end, all you need to do is define the data schema and access control rules on the server side. See https://github.com/SocketCluster/ag-crud-sample/blob/6805499...

For the front end, I use VueJS in the simplest possible way without any build step during development. I just define my main app component and setup a component for each page: https://github.com/SocketCluster/ag-crud-sample/blob/master/...

For data, I just use my own model and collection components to bind to the server data in real-time: https://github.com/SocketCluster/ag-crud-sample/blob/master/...

The collection component lets you bind to a 'view' which is declared in the schema on the server.

It's just CRUD with realtime subscriptions built into the model and collection objects, nothing special.

You can achieve a lot more if you just keep things simple (at least conceptually) and use the right tools.

Reply on news.ycombinator.com