Live data from Hacker News

Second-Guessing the Modern Web

macwright.org

81–90 of 467 posts

Re: Second-Guessing the Modern Web

#81
post #47

I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…

I disagree. Do you remember the days when J2EE was the hot stuff? Popularity comes and goes and is not necessarily correlated with whether something is a good idea or not.

Over the last 15-20 years or so as a web development shop we've gone through Prototype, Jquery, Backbone, Angular, Vue and now React for JS frameworks. We've mostly settled on React lately. Our experience is however that it is wildly overused where it is not needed and adds significant time to development. Features that should take a week to build now suddenly have complex client side state management requirements (to name one issue) and take several weeks. We've seen this in several projects while working alongside experienced developers.

We do use React extensively and we find the sweet spot is in smaller components on a page, or highly interactive sections, things without lots of shared state, but it often seems like web developers have one hammer and it is not the right one.

Re: Second-Guessing the Modern Web

#82
post #76

You guys should give Svelte a try. It's a breath of fresh air for modern JavaScript. Your codebase becomes much simpler. It's much faster and lighter than React. It doesn't give you absolute flexibility like React + JSX does, but it solves your most common problems much more pragmatically.

There are a lot of really interesting ideas in Svelte. I'm waiting for Typescript support to jump in.

Re: Second-Guessing the Modern Web

#83
post #49

> But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. If "React" is used loosely here to mean a modern frontend framework, then at least one concrete benefit is the ease of splitting web pages into components, and the ease of co-locating CSS with these components. I have tried Eleventy with…

This is pretty much it, tbh. Every time one of these types of threads pop up you get a bunch of people commenting about how broken the web is and how it sucks because front end devs aren't real devs or something, and it's immediately clear to me that none of them have done any serious work on a modern website.

The problem is a business/orgnanizational problem - it's not like developers are incapable of mimicking their own websites with pure html+css+js (especially with all the improvements to JS and the browser apis over the years), it's that doing that and then maintaining and growing it with a team of people is basically impossible at any useful scale.

Frameworks provide a common language for teams to build their site with. The fact that they also currently introduce a lot of extra complexity that require developers to handle previously "free" things (ex. performance, bundle splitting) isn't some fundamental flaw with the idea of frameworks, it's just a result of people still trying to figure out exactly how the hell you can provide a nice, interactive site with all the bells and whistles that'll make like 5 different groups of stake holders happy.

Re: Second-Guessing the Modern Web

#84

Earlier quoted context omitted.

"React is bad in your case, drop it." I know it's far out idea in tech, to flat out tell someone "you don't need this, you just save time and money and get a better result of you don't use what we made", but it shouldn't be. React is fine per se, the problem is throwing these "simple, magic" solutions onto everything , without even caring what mountains of code end up running as a result. The minimum for a Discourse…

I personally liked how easy it was to install Discourse thanks to Dockerization, and don't care one whit about requiring 10GB of space (cheapest DigitalOcean droplet comes with 25GB).

Fine, but that kinda falls under "without even caring what mountains of code end up running as a result". You use 10 GB instead of a few MB, and get an easy installation vs. an easy installation.

It's like driving a huge truck everywhere, even to get the mail from our mailbox, because it starts up real fast and we don't have it far to the garage from our living rooms, and then later on because we haven't walked in so long, we don't even remember what it is. And especially with websites, people also tend to forget that their website isn't the only thing anyone ever runs on their machine, some have to share resources with dozens of tabs.

Re: Second-Guessing the Modern Web

#85
post #47

I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…

I put food on the table, and I do more work in Django than I do in SPA's. In fact, one of the complaints I read about from management is that Django devs cost more than JS devs (don't know if that's true, just saying it's a management concern).

But I think the "React everywhere" error, is more or less the same as the "one language for everything" error, the "everything should be Windows" error, and many other cases of wanting to use only one technology and have it work for all cases.

Re: Second-Guessing the Modern Web

#86

Use the right tool for the job. Why is this so controversial? Yes SPA frameworks are overused but a lot of modern web "apps" are actually real applications and can't be built on a reload-the-world on a mouse click paradigm of the old web.

What constitutes a real application? There is some obsession with preserving client-side state as if the user could not live without it, and yet in almost every case where significant engineering has been put in to (essentially) reimplementing a web browser within a web browser, the result is either on a par or slower, and almost always vastly more cumbersome than just shipping a brand new page.

There are so many things the majority of applications never even try to get right, like progressive loading or history management, that have been solved problems for browsers since the dawn of time.

Separately, avoidance of client JS eliminates multiple classes of potential bugs, because eliminating (or minimizing) active behaviour on the client prunes vast chunks of the overall application state space.

I hire contractors quite regularly, and the amount of time I waste almost weekly having to explain "no Javascript, rip it back out, you're making a mess", because so few people seem to understand this. Our market is somewhat unique, in that most clients are high latency low bandwidth, but even if that were not true I expect my direction would still be the same.

"The page content is smaller as JSON" .. "you introduced a round-trip, game over"

"We only need 200KB of JS what's the problem" .. "the page didn't even start to render until the last byte of JS was loaded"

"We can implement mixed rendering and fix this on the server" .. "or you could just send HTML and rip out the JS, which is what we're doing"

Re: Second-Guessing the Modern Web

#87

The problem with not using a JS framework is that eventually, the investors/business person/design team/frontend enjoying devs wants this highly animated site with all sorts of little toggles, confirmation boxes, popup models, toasts, etc. It is far nicer doing that in React where you can just casually npm in some online component that does that rather than in vanilla JS or jQuery. React is basically a compromise bet…

> Developers like simple sites like Hacker News. Nobody else does.

One word : Craigslist.

Re: Second-Guessing the Modern Web

#88

The problem with not using a JS framework is that eventually, the investors/business person/design team/frontend enjoying devs wants this highly animated site with all sorts of little toggles, confirmation boxes, popup models, toasts, etc. It is far nicer doing that in React where you can just casually npm in some online component that does that rather than in vanilla JS or jQuery. React is basically a compromise bet…

Except for the user, who never asked for vanity animations and hate the popups.

The cases which should be simple, don't give anyone a chance to be impressive. This applies not only to the devs, but also to the managers (and designers, and etc).

I am impressed with simplicity, but most people aren't.

Re: Second-Guessing the Modern Web

#89
post #76

You guys should give Svelte a try. It's a breath of fresh air for modern JavaScript. Your codebase becomes much simpler. It's much faster and lighter than React. It doesn't give you absolute flexibility like React + JSX does, but it solves your most common problems much more pragmatically.

Swelte has exactly the same problems author mentions about React.

Re: Second-Guessing the Modern Web

#90

Use the right tool for the job. Why is this so controversial? Yes SPA frameworks are overused but a lot of modern web "apps" are actually real applications and can't be built on a reload-the-world on a mouse click paradigm of the old web.

What constitutes a real application? There is some obsession with preserving client-side state as if the user could not live without it, and yet in almost every case where significant engineering has been put in to (essentially) reimplementing a web browser within a web browser, the result is either on a par or slower, and almost always vastly more cumbersome than just shipping a brand new page. There are so many thi…

This is an overly broad statement. In the last year, for example, I've built an in-browser SVG vector drawing tool and a very detailed dashboard with a lot of nested charts and data visualizations. Neither of these would have been possible without a heavy client-side JS component.

My current project is an e-commerce app that's almost entirely server rendered. I avoid JS where it's not needed but also avoid irrational biases against it when it is needed.

Post reply on HN