Hacker News Reader

Comment by Tade0 | Hacker News Reader

I feel like these problems are endemic to React and the surrounding ecosystem.

Since its introduction in late 2016 Angular 2+ has had no major changes on the scale of hooks and is unlikely to introduce them, because its target audience - large companies making large-scale applications is fairly conservative.

Vue I think had one measurably large syntax shift around v2.5(or 2.6) and will have another one with 3.0, but that's about it.

Meanwhile in React every year there's this new convention that isn't explicitly mandatory, but for some reason "cooler" than the previous one.

All this won't matter once the next gen compiler-frameworks reach maturity. My take is that hooks are React's swan song.

View on HN

> Since its introduction in late 2016 Angular 2+ has had no major changes

As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless.

> its target audience - large companies making large-scale applications - is fairly conservative

React was built for Facebook, which is a large company building a large-scale application.

> All this won't matter once the next gen compiler-frameworks reach maturity.

And here I am using HTML and CSS with tiny sprinkles of JS for most websites, and it's working just fine, and has been for many years.

Personally, I hope that server-side rendering will be the new ~old~ trend.

> As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless.

Oh yeah. I remember the "let's just apply the good parts of AngularJS here and there" in v4-6.

"React was built for Facebook, which is a large company building a large-scale application."

One large scale application, which is not enough to create stable conventions that are badly needed in a framework that's supposed to be used in multiple such projects done by very different organisations.

Personally, I hope that server-side rendering will be the new ~old~ trend.

Users don't tolerate the inherent delays caused by this approach anymore.

All those hoops current frameworks are jumping through so that we can eat the cake and have it too are there because of this.

> Users don't tolerate the inherent delays caused by this approach anymore.

Well, I'm from Germany, but have a 6-y/o Android phone and live in a rural area with poor EDGE connectivity (~50kb/s). Most "modern" websites don't load/work for me.

From my personal experience, there's quite a few people now saying that their computing devices are getting faster and faster every year whereas the majority of websites, uh, webapps are seemingly getting slower each year...

This is also not just a problem with mobile and poor connectivity. Here's an example from my high-powered desktop work-station with a 100 mbits: When I open https://github.com/, my repositories (on the left) are server-rendered and shown instantly as the site is loaded, which usually happens in under 1s. The activity feed in the middle is rendered asynchronously on the client. It usually takes around 3-6s to finish rendering on my machine (while there is space for 5-8 activity feed items on my screen).

Optimizing SPAs is notoriously hard. You don't really have to optimize HTML.

> Users don't tolerate the inherent delays caused by this approach anymore.

Well, I certainly also do not tolerate the delays in contemporary React sites either. Take Reddit for example, which used to be lightning fast when it was mostly serverside, which now is painfully slow, especially on mobile.

Yep, I agree. Was just talking to my wife about Reddit. It's so slow now, especially on mobile. The page constantly crashes on my Android phone and they always recommend the app. No thanks.

Today is the day I decided to switch to old reddit... My Mac can run garageband and vsc and 40 chrome tabs at once, but as soon as I click a front page Reddit link, that modal is like pouring sludge into my computer.

> As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless.

I can second this - I've been working on a variety of Angular apps in an enterprise environment. It's worked fine and the "batteries included" has worked for my org, but it has definitely been a bumpy ride to get from beta to 9 with plenty of changes along the way.

> And here I am using HTML and CSS with tiny sprinkles of JS for most websites, and it's working just fine, and has been for many years.

This has been my favorite setup at work - pick "boring" tech like Django/Flask or Spring Boot and then sprinkle in some Javascript for highly interactive forms/pieces (React or Vue if needed).

As an outsider, I feel like React both does too much (a virtual DOM? Aren't current web standards enough to make a flower shop website?) and too little -- there's all these terms/technologies/subframeworks that people are using like "create-react-app" and "Redux" and so on.

It's neither an overarching architecture that makes normal web technology obsolete but runs on it, like Windows 95, nor a website generator like Wordpress. Web tech confuses me thoroughly, and I read HN all day.

> a virtual DOM? Aren't current web standards enough to make a flower shop website?

Of today's frameworks, all but Svelte use a virtual DOM.

As mentioned, LitElement doesn't use a vdom, but neither does Angular, Ember/Glimmer, Solid, incremental-dom, and many others.

VDOM diffing is pretty slow, memory intensive, and unnecessary. It's very good it's not the only game in town.

Thanks, I see I'm mistaken. Could've sworn Angular was VDOM-based, but no. [0]

[0] https://stackoverflow.com/a/39739739/

Not true.

litElement (used by Polymer) uses tagged template literals and no vdom.

You're right, LitElement and Polymer don't use a VDOM. [0][1]

I don't think Polymer 3 uses LitElement though. Seems to say they're highly compatible, but that Polymer 3 uses PolymerElement, not LitElement. [2]

[0] https://lit-html.polymer-project.org/

[1] https://www.infoq.com/news/2019/06/polymer-lit-html-element-...

[2] https://github.com/Polymer/polymer

Polymer 3 and LitElement are separate projects by the same team. LitElement is the successor to Polymer 3. It would have been named Polymer 4, but it's quite different.

They're highly compatible because they are both web components-based. There's no "framework" that creates component instances, the browser does that when it sees the custom elements. So each component is in control of its own lifecycle and rendering. You can have a Polymer element use LitElements (or Stencil, or Lightening, etc) or vice-versa.

How does it work with data-binding? Isn't that a Polymer-specific feature, rather than a feature of Web Components?

> As an outsider, I feel like the Model-T does too much (an internal combustion engine? Aren't current horses enough to carry our wagons?)

If you don't need a virtual DOM, nobody will judge you for not having one. But once you really feel 'behind the wheel' of a framework like react or vue, it's hard to go back. Not only is it easier to hack out something quick over a weekend, it's also more suitable for collaborating large, complex applications.

Reply on news.ycombinator.com