Live data from Hacker News

Second-Guessing the Modern Web

macwright.org

341–350 of 467 posts

Re: Second-Guessing the Modern Web

#341

Earlier quoted context omitted.

> 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. It sounds like you're reinforcing this divide by classifying people who have a different opinion to you as "hipsters." They label your technology choice as outdated, and you label them as hipsters. You become the thing you fight.

The problem with using some shiny new library/software/app/technology is, that it might dissapear in a year. The developers will move on to new companies, and work with some new shiny tech, and all your codebase will be useless due to a unmaintained library and no new people (developers) who know how to use it. I wanted to make an example that it was like starting work at a company, and seeing that they're still usin…

> but it seems phpBB is still being developed

Doesn't that underline your point though?

Re: Second-Guessing the Modern Web

#342
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 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. Our salaries are expensive because, presumably, we're being paid to make something that serves the users. So anything that benefits us at the expense of the people we're serving should…

Salaries are high because the supply of (skilled) software developers is low.

Re: Second-Guessing the Modern Web

#343

Earlier quoted context omitted.

It literally doesn't. You can build a fully normal HTML form in react. The only reason to do any of it yourself is because you need something regular forms can't provide and even then you can still use as little or as much custom parts yourself.

It literally does, unless you have the form POST or GET to an API directly + a redirect from the API. You have to override the submit functionality which is built-in by the browser. You have to maintain state of what the user inputs, which the browser handles for you. You have to reset inputs, which the browser handles for you (button type=reset). And a ton of people forget to actually validate on the server because…

You do have to override the submit functionality if you don't want to load a new page, sure, but that was always the case with plain Javascript or jQuery or whatever.

You don't have to maintain the state of what the user inputs if you leave the inputs as uncontrolled (https://reactjs.org/docs/uncontrolled-components.html) and access their value via a ref. You could even give them IDs and access their value directly via that if you wanted to, just like you would pre-React. But there are clearly advantages to making the inputs controlled by React, otherwise there'd be no reason to bother doing so (not saying that there aren't probaly a lot of cases where you could keep it simpler but people have been led to believe they need to put their form data in Redux so use some elaborate solution which doesn't scale, or whatever).

Also if you are doing forms in React, check out formik, it's the nicest library I've found so far. Granted it's not as "easy" as a straight HTML form that POSTs to a new page, of course, but modern web experiences often demand richer functionality than "the old way" allows.

Re: Second-Guessing the Modern Web

#344
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 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 have a 20 year history of building websites, and a recent three year stint of building front-end applications professionally using mostly React, which I'm now proficient in. I also normally use a strict whitelisting policy for Javascript using NoScript. If it's not a tool that depends on it that I really want to use, or if I find no obvious reason for it to be using Javascript, websites don't get added to the whitelist.

Javascript, as far as I'm concerned, is a wide open vector for an ongoing large scale attack on my privacy. Not only that, but I also have to pay for it in battery life and memory. The occasional blog built in React without a static fallback will usually go unread on my end, and no one is losing sleep over it.

I also think that you are fundamentally missing the point of the article if you your experiences building native applications vs building web applications is supposed to offer a counterargument. It's a false dichotomy in this case; the blog was never a native desktop app. The marketing site was never a native desktop app. They're collections of documents and I have no idea how anyone could come to believe that arranging that using a framework designed to facilitate reactive web applications is easier than just delivering the documents using technology designed to do so.

Re: Second-Guessing the Modern Web

#345

Earlier quoted context omitted.

The problem with using some shiny new library/software/app/technology is, that it might dissapear in a year. The developers will move on to new companies, and work with some new shiny tech, and all your codebase will be useless due to a unmaintained library and no new people (developers) who know how to use it. I wanted to make an example that it was like starting work at a company, and seeing that they're still usin…

> but it seems phpBB is still being developed Doesn't that underline your point though?

Does library-support-wise (well, software-wise). Trying to find a developer with phpbb experience now, would be a totally different story.

Re: Second-Guessing the Modern Web

#346
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 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 have a 20 year history of building websites, and a recent three year stint of building front-end applications professionally using mostly React, which I'm now p…

Do you also wear tinfoil hats?

Re: Second-Guessing the Modern Web

#347

Earlier quoted context omitted.

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

“Let the page refresh” translates to a terrible UX. It devalues the application. It’s equivalent to buying a physical product, say a car, but the car jerks up and down whenever you hit the gas, and you hit your head on the roof every time. Yea, the web page _works_ but it’s ugly, and in poor taste. Users do not care about browser purity, they want an app that seems polished. You can’t get that experience by using sem…

I'm pretty sure blind people don't even notice this 'terrible UX' problem you describe, and that sighted folks aren't quite as jarred by it as you think.

This 'taste' issue probably matters more in some organizations than others. Hopefully they don't involve blind people in their business, because SPAs are notorious for being unusable to them. You can design an SPA with accessibility in mind (https://www.deque.com/blog/accessibility-tips-in-single-page...) but most devs either can't be bothered or aren't even aware of the issue.

Re: Second-Guessing the Modern Web

#348
post #321

Earlier quoted context omitted.

> 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 answer is often no, or they are a contrarian in general. Anyone who cares about privacy allows minimal JS etc. Especially if they're using Tor. And given Tor's high latency and low bandwidth, sites that require lots of…

Proof that hardly anyone cares about privacy

Most people don't because it never impacts them in a visible or tangible way.

Re: Second-Guessing the Modern Web

#349

Earlier quoted context omitted.

By what measure? Majority of individual 'products'? Majority of programmers? Majority of investment? Majority of revenue? I think that at best what you're describing is a thin simple majority by some of those metrics. But there are so many developers working on factory automation, networking, gaming, small embedded systems (anything with a chip in it, from washing machines to cars), not to mention the huge frameworks…

I'd say majority of programmer-hours, because anything else is a metric that's too unreliable / easy to fudge. "Individual products" is an arbitrary marketing distinction (e.g. a company I worked for could create and sell new products by tweaking few lines in a config file; every customer would get their own mix and match of software pieces). And neither investments nor revenue are directly correlated with the amount…

Using web technologies is not the same as doing crud web apps. Games for example are a very different kind of programming. And even if network admin and factory automation apps have web front-ends, that's still a minuscule part of the code.

Re: Second-Guessing the Modern Web

#350

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…

> chances are there’s at least one front-end hipster around who will mock you as outdated Well, React isn't something very 'shiny' anymore, for shiny things you would look at things like svelte or wasm. React is older than jQuery's age when React was first born now.

WASM is entirely different from Svelte/React. WASM is a compilation target for native-code languages, and can't interact with the DOM except through JS shims.
Post reply on HN