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

101–110 of 467 posts

Re: Second-Guessing the Modern Web

#101

Post by pier25 »

tomaszs wrote: post #89
pier25 wrote: 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.

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.

Other than React he is criticising problems which have better solutions than the ones he is proposing.

For example the bundle splitting problem can be solved by a smart browser refresh at the appropriate time.

The SSR problems he mentions are non existent with Svelte as the JS needed for an SSRd page is probably less than 5kB and since those are so small you can preload all JS files on the first user visit. He also mentions authentication problems which are non existent if your SSR app talks to the database and uses some KV cache for sessions. It's also certainly possible to cache the HTML, not only in the server but in the browser too using service workers.

As for his critique of APIs I don't agree. He also states that "GraphQL application will suffer under the N+1 query problem" which is true on the most simplistic implementations. Hasura, Fauna DB, and other GraphQL servers don't suffer from this problem at all.

Re: Second-Guessing the Modern Web

#102

Post by what-the-grump »

Reeks of obscurity engineering. Simple crud is being rewritten into react, things that could be done 300-400 lines are being written into 2 month long projects.

The vast majority of tooling, pages, functionality is so simple that I want to puke every time someone drops in node,react,Vue to replicate something that could be done in 100 lines of python or perl.

Re: Second-Guessing the Modern Web

#103

Post by Scarbutt »

acemarke wrote: post #13

Dan Abramov put up a tweet thread agreeing with this piece, and talking about how the React team is now looking at trying to come up with some server integration capabilities to enable a hybrid model for the rest of the community: https://twitter.com/dan_abramov/status/1259614150386425858

Hasn't this hybrid model used by many for a long time already? SSR react as most as you can(try to avoid client-side routing), then hydrate/enhance parts of the page and make it dynamic.

Re: Second-Guessing the Modern Web

#104

Post by luxphl »

burlesona wrote: post #72
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.…

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…

This is what I meant by gatekeeping; there is common misconception that you have to go looking for a library to solve a problem. And it makes it seem like there's a higher barrier to entry than there is.

But the reality is that React is plain HTML and Javascript, in a less error-prone and maintainable package.

Everything you can do with vanilla JS you can do in React, but with React you benefit from being forced to separate the state of the DOM from manipulating it.

I don't buy the hipster-centric logic, for me it comes down to productivity. The bugs of yesteryear, tracking down which procedural code path led to modifying a variable, are mostly gone with React. And if you don't use it (or something like it), you end up implementing a subset of it anyway because it's a foundational part of coordinating UI with business logic. /shrug

Re: Second-Guessing the Modern Web

#105

Post by microcolonel »

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.…

> 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 answer is often no, or they are a contrarian in general.

I've been developing single page applications, mostly, for six years; and I generally don't enable JavaScript on a website unless it is otherwise broken and I actually care to use it. I'm developing a website right now that has some persistent elements (video call, interactive charts) that don't play well with server side rendering. For the elements that are fine without it I prefer to render them on the server when there are enough of them, but ultimately there are limits.

Re: Second-Guessing the Modern Web

#106

Post by luxphl »

Dowwie wrote: post #65
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.…

You are contradicting yourself by opening with a claim of time savings and ease of use followed by admitting that the solution is largely more complex. More complex work does not save time in aggregate and is not easier to use.

The calculator on my desk is a (relatively) complex set of circuitry but it sure saves me a lot of time when I do my taxes

Re: Second-Guessing the Modern Web

#107

Post by userbinator »

systemvoltage wrote: post #54
caribousoup wrote: post #34

Earlier quoted context omitted.

I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens. You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least…

Please write more about this because I feel the exact same. Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static. Why do you want things moving around and reacting? People of the internet - imagine if the internet protocols were given to us, but no browser existed. Would we develop this non-sense we have today…

Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static

Exactly. As a bonus, you automatically get the behaviour associated with a link that browsers already implement: people can bookmark a link for later use, open it in a new window, etc. All of which would need extra effort (and thus also easily break) if it was just a clickable element invoking some JS.

I've had some pretty annoying conversations with customer support and developers about things like this; almost always, the response is something like "we didn't think you would have a need to do that". They would not have needed to think about it at all, and it would work for me, if they had just used a regular link.

That said I'm not totally opposed to SPAs; highly interactive apps, e.g. realtime games and such, would definitely benefit as they wouldn't really make sense as a linked set of documents. But for everything else it feels like they not only reinvent the wheel, but make it square.

Re: Second-Guessing the Modern Web

#108

Post by learc83 »

tomaszs wrote: post #89
pier25 wrote: 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.

Not all of them. Without the overhead of rendering everything to a virtual DOM and then doing a diff, performance can get pretty close to native javascript--the sweet spot the author mentions gets bigger. Plus since the framework is mostly just a compiler, the bundle issue is less of a big deal.

Re: Second-Guessing the Modern Web

#109

Post by bobthepanda »

conorh wrote: post #81
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.…

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…

> Features that should take a week to build now suddenly have complex client side state management requirements (to name one issue)

This sounds like bad system design rather than a problem of React.

In general, I find React hate massively overblown. The problem seems mostly to be that everyone is using it, and "everyone" in the case of frontend devs is all over the place in terms of how they got there, what they know to do, and what they know not to do. If you're not careful, all of the JS ecosystem can give you a lot of rope to hang yourself with. The relative accessibility of webdev is a blessing and a curse.

Re: Second-Guessing the Modern Web

#110

Post by MattGaiser »

rossdavidh wrote: post #85
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.…

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 o…

I haven't seen a bootcamp teaching Django recently, so I can see where that might be true. The cheap people are overwhelmingly JS.
Post reply on HN