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

Second-guessing the modern web (2020)

macwright.com

Post reply on HN
Print view View original

91–100 of 309 posts

Re: Second-guessing the modern web (2020)

#91

Post by stevebmark »

For dynamic websites, React should always be SSR first with optional client hydration. Next.js makes React SSR easier, if you're using Next.js for non-static sites, and not doing SSR, you shouldn't be using Next.js.

Browsers have decades of optimization to show HTML to you as fast as possible. Before scripts, sometimes before stylesheets. Browsers can't optimize the extended network dance you need to do to download and parse KB of Javascript before you can _start_ fetching data.

SSR with partial client Javascript hydration. It's a solved problem, but few people do it.

Re: Second-guessing the modern web (2020)

#92

Post by dntrkv »

reaperducer wrote: post #74
Zababa wrote: post #28

Earlier quoted context omitted.

I see a big difference between Hadoop and React though: React pushes the costs on the client. This is something that's not often mentionned, but with a traditional SPA, a good part of your code runs on the client, which is server costs you don't have to pay. I don't know if it's something that people do consciously to reduce costs and just never talk about, or if it's an unintended consequence, but it's here. If your…

I don't know if it's something that people do consciously to reduce costs and just never talk about, or if it's an unintended consequence, but it's here. It's very deliberate. It's even what is taught in colleges. I've had debates with recent graduates who believe the proper way to build anything from a web site to an app is to offload as much of it as possible on the client. If the client doesn't have the latest gea…

Nobody teaches that.

You don't offload things to the client in order to save money. You offload things when it will improve performance. Most of the processing power and bandwidth will still be incurred by the server, just at a different time in the lifecycle of the app.

Re: Second-guessing the modern web (2020)

#93

Post by phist_mcgee »

scrollaway wrote: post #63
ian1321 wrote: post #40

The amazing part to me is that SPAs are so much harder to do right compared to old-school server-side rendered HTML. One could be forgiven if they think a "simple" SPA is a good starter project, but they'd be very wrong. Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible. On top of this, understanding how data flows through these SPAs is no sm…

It's absolutely possible, dare I say easy, to do old school SSR wrong. You start with an honest to god html file. Your IDE lints it. You are happy, life is easy. Then you need a second page. So you copy some things over. Then you need a third page, and it becomes apparent that you need a way to share parts of your html pages across multiple files, in a generic way. And kids, that's the story of how I met your templat…

To extend your point, I think the linked article suffers from a common trend in web dev editorialism, which is over-generalisation of problems, and reducing the domain into simple binary thinking.

A lot of these arguments talk about the dangers of SPAs, but don't talk to the reason why first class interactivity/reactivity exists on the web. It's because for average users, they want to see feedback to their actions immediately. Articles like this talk to SPAs as if they are unnecessary or overused. I disagree, I think SPAs are mostly appropriate for most SaaS, social media, or business tooling. Sure, the poorly implemented version of an SPA is harder to debug than a poorly implemented template generated site, but that's like comparing the complexity of a car built in 2021 to a car built in 1980. And cars from 2021 sell better than cars from 1980.

A lot of these articles strike me as opinion pieces decrying the direction of modern web development, and seem to point to the past as a more 'gilded age' of internet browsing. But this was back when users sat at a desk, and scrolled pages using a analog mouse, viewing it on a CRT monitor. Users today want to browse on their phones, want to share and upload, to take live videos, to see when their message was sent, delivered and read. We need SPAs and libraries like React just like we need cars that can do lane assist. It's because it's a feature users want, and on the whole, it is much easier to build using React and SPAs.

Re: Second-guessing the modern web (2020)

#94

Post by mbgerring »

dmalik wrote: post #87
mbgerring wrote: post #65

There’s a really great fix for this, which is to design JS frameworks to not take over the entire application. I have been waiting for a long time for the framework that will let me write a web component, and then include that web component in a regular HTML page, in a way that’s supported by the idioms and best practices of that framework. It’s also worth pointing out that all of these drawbacks to rendering web pag…

> design JS frameworks to not take over the entire application. Facebook did just that with React. React doesn't have to be used only as a single page app. Use it for just a single component on a page if you want.

Nobody does this in practice. Tooling, tutorials, frameworks, etc are all created around the idea that the entire application is an SPA with a single root element. I understand that it’s possible to do this in theory, and that’s why I said I want to see a framework where the idioms and best practices are geared for this kind of use.

Re: Second-guessing the modern web (2020)

#95

Post by tshaddox »

mathgladiator wrote: post #32

I'm no fan of React, and I'm building a new back-end and front-end that is probably heretical to... well.. everything. What I have found is that if you have reactivity from your back-end, then front-end reactivity is... easy. My focus is on board games, but the idea generalized pretty well. As an example, my dumb chat room: https://github.com/mathgladiator/adama-lang/blob/master/demo... I really need to focus on this…

There is an SPA pattern (perhaps sometimes called "offline-first") where your client application code does all reads and writes data against a local database, then another bit of client code is responsible for syncing this local database with the server's database. The local database could be IndexedDB, or localStorage, or even some bespoke DBMS. In some sense the client app would be running on one node in a replica set.

Indeed, one could go even further and try streaming the UI state itself from the server, so that the client is something like an X11 client. The obvious downsides of this are 1) the server needs to store the session state and 2) it's fairly intolerant of connection interruptions, but for something like an interactive game these are probably not deal-breakers.

Re: Second-guessing the modern web (2020)

#96

Post by sombremesa »

React is very good at what it's for, and much of this article is saying that React is not good at what it isn't for. That's a fair point to raise due to the ubiquity of the library, since many will reach for it out of habit or ignorance when it isn't appropriate, but it really doesn't amount to second guessing the modern web in my opinion.

There are plenty of people still using Django and even things like Plone. They're just not in the zeitgeist, because those tools have practically congealed at this point and there isn't much reason to have a discourse about them.

Re: Second-guessing the modern web (2020)

#97

Post by simonw »

dmalik wrote: post #87
mbgerring wrote: post #65

There’s a really great fix for this, which is to design JS frameworks to not take over the entire application. I have been waiting for a long time for the framework that will let me write a web component, and then include that web component in a regular HTML page, in a way that’s supported by the idioms and best practices of that framework. It’s also worth pointing out that all of these drawbacks to rendering web pag…

> design JS frameworks to not take over the entire application. Facebook did just that with React. React doesn't have to be used only as a single page app. Use it for just a single component on a page if you want.

In theory that's true, but I hardly ever see it used like that in practice.

Re: Second-guessing the modern web (2020)

#98

Post by arsome »

1vuio0pswjnm7 wrote: post #85
zabzonk wrote: post #49

Earlier quoted context omitted.

Sorry, what's a "SPA" - can't seem to find it by Googling.

firefox "https://en.wikipedia.org/w/index.php?limit=500&profile=all&search=spa" At the top is the link to the Disambiguation. https://en.wikipedia.org/wiki/Spa_(disambiguation) A more specific search, e.g., "single page", will not redirect. In some ways, for discovery, Wikipedia's search engine is better than Google's. For one, it is non-commercial and does serve ads based on past surveillance of the user's activity.…

The link you used directly brings up the wikipedia article on Spas. Not sure that's what you were going for. :)

Re: Second-guessing the modern web (2020)

#99

Post by 1vuio0pswjnm7 »

"There are decent patterns in the form of GraphQL, but for a React component that loads data with fetch from an API, the solutions have only gotten weirder."

Wonder how many people using "GraphQL" realise those decent patterns are from the 1970's, i.e., QBE.

https://en.wikipedia.org/wiki/Query_by_Example

Re: Second-guessing the modern web (2020)

#100

Post by darepublic »

The spa paradigm was not invent d by react. Or any framework for that matter. Remember when asynchronous xmlhttp requests were cutting edge?. It's just one step from ajax to spa.

I have been growing increasingly dissatisfied with react but there's no clear superior alternative. Server side react is a pretty good solution for most problems and fairly scalable.

Post reply on HN