Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Second-Guessing the Modern Web

macwright.org

Post reply on HN
Print view View original

191–200 of 467 posts

Re: Second-Guessing the Modern Web

#191

Post by retreatguru »

luxphl wrote: 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.…

Do they really save us time?

What about if you used a mature back end framework such a Rails, Django or Laravel for 95% of your app. And then vue or react for the 5% that rally needs it? Would this be more or less productive?

Re: Second-Guessing the Modern Web

#192

Post by millstone »

simonw wrote: post #78
burlesona wrote: post #72

Earlier quoted context omitted.

For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the…

What a great anecdote. It aligns with my big worry here: we are raising a cohort of front-end developers who don't know how to use plain HTML and forms!

I want to hear a war story of someone starting from a React bug report, reducing it to pure JS, fighting through the Chrome build process, isolating the v8 JIT bug, producing a patch, and going on to a successful compiler career.

Re: Second-Guessing the Modern Web

#193

Post by cryptonector »

ISTM you need to strike the right balance. The ideal is that you have a static site and fetch data using JS -- this is good because it's simple. Most pages don't have a lot of data, and if there is data and its dynamic, then JS is needed to make the app responsive. On the other hand, if you have content that you could be fetching using JS but it's desirable to have it rendered every time you land on the page, then yeah, you want to render it server-side.

Re: Second-Guessing the Modern Web

#194

Post by millstone »

MattGaiser wrote: post #156
userbinator wrote: post #113

Earlier quoted context omitted.

It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. As a user and developer myself, that's the sort of selfish attitude that really really angers your users. I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answ…

> As a user and developer myself, that's the sort of selfish attitude that really really angers your users. A user is only unhappy if they withhold some money over it.

Right. If your product is paid for in eyeballs, then by the time users have perceived your low quality, they've already paid.

Re: Second-Guessing the Modern Web

#195

Post by erichocean »

theonething wrote: post #177
renaudg wrote: post #87

Earlier quoted context omitted.

> Developers like simple sites like Hacker News. Nobody else does. One word : Craigslist.

For being the behemoth it is, amazon.com has a relatively simple frontend. Most links are simple html that loads a new page. It's doing fairly well.

FWIW Amazon is moving away from this model in new code, e.g. the "business account" interface, and in updates to seller central.

Re: Second-Guessing the Modern Web

#196

Post by millstone »

mgummelt wrote: post #128
burlesona wrote: post #72

Earlier quoted context omitted.

For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the…

Can you give an example of a problem that would take significantly longer solving with React than with DOM manipulation?

https://bugs.chromium.org/p/chromium/issues/detail?id=604033

Re: Second-Guessing the Modern Web

#197

Post by Yhippa »

bit_logic wrote: post #46

What I dislike the most about the modern web and the unnecessary use of SPA technologies is how unreliable and error-prone it has made sites that really need to be simple and reliable. For example, banking websites, utility websites, government websites (like DMV, unemployment, and others), anything where failure or mistakes have a high cost. These sites should stick to reliable, tried and true, pre-SPA technologies.…

Because of the cargo culting, you see all sorts of Fortune 500 companies using this for fairly critical end-user tasks and failing at it. Air Canada did a redesign a while ago and I still can't book a flight on there. You look at the console and it's barfing all sorts of client-side errors and 500's. I would rather have a static, slow, reloading app that is reliable.

There are good uses for SPA's like ticket sites that have virtual queues and office applications. I just don't see the advantage SPA's give me for a lot of critical things I need to do in my life.

Re: Second-Guessing the Modern Web

#198

Post by lhorie »

pier25 wrote: post #101
tomaszs wrote: post #89

Earlier quoted context omitted.

Swelte has exactly the same problems author mentions about React.

Obviously Svelte can't do nothing about the misuse of Svelte (which is one the major points of the article) but: > The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too high for any company to include it as part of an SDK. Svelte is just a simple way for you to write vanilla instructions. There is no runtime and practically no framework. Oth…

> There is no runtime and practically no framework

As a fan of Svelte, I really wish people would stop repeating this. There _is_ a runtime in the form of repeating patterns of code, which are objectively less ideal than the not-so-revolutionary approach of just having a runtime. Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and having best-in-class perf. On the other hand, the question of how the Svelte repetition scales as an app grows is a constant worry that drives away would-be newcomers.

Re: Second-Guessing the Modern Web

#199

Post by post_below »

luxphl wrote: 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.…

The author wasn't claiming that react and co are bad for development. Rather that they are great for particular use cases and inferior to other options for other use cases.

I think that's undeniably true.

You hinted at something that to me is a key point: A lot of web apps are built by teams at big organizations.

In that environment trends are compelling because they keep everyone on the same page. It's easier to onboard people, it's easier to hand things off, easier to maintain going forward.

That makes a strong case for using the latest frameworks even when they aren't the best solution for a particular problem but it doesn't make it right from an efficiency or user experience perspective. There are a lot of reasons why arbitrary complexity is expensive. One example: what happens when your page load times start to rise above the threshold where it starts hurting organic traffic? You probably don't scrap everything and start over, instead you hack solutions on top of what you already have. Now you've lost money in both free traffic, one time development costs and increased maintenance costs going forward.

Again it's not that react is bad, and either way people aren't going to stop using it for things it's not ideal for until another trend replaces or absorbs it. But I think there's value in seeing things for what they are, and having conversations about it.

Post reply on HN