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

331–340 of 467 posts

Re: Second-Guessing the Modern Web

#331

Post by OOPMan »

MattGaiser wrote: post #111
simonw wrote: post #78

Earlier quoted context omitted.

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!

That's what the C devs said about all the people learning Java. "We are raising a cohort of developers who knows nothing about memory management." Sure, there are things you do not know if all you know is React, but technological changes make it irrelevant in all but the most niche of cases.

And you know what, the C devs weren't wrong.

Coming back to C++ after a decade of Python I realised I had largely forgotten about how memory management works and that felt bad. I felt stupid, because not thinking about that wasn't necessarily a good thing.

Re: Second-Guessing the Modern Web

#332

Post by amw-zero »

grey-area wrote: post #237
amw-zero wrote: post #52

Earlier quoted context omitted.

I agree with the sentiment of what you're saying, but I don't agree with the premise that there are no use cases for single page apps. You can achieve a decent UX for some applications by using small amounts of vanilla JS, but it's simply not possible to avoid re-rendering the entire page without using XHR requests at some point. That is how the browser is designed, fundamentally. Because it wasn't designed as an app…

You don't need an SPA to use XHR, and your description of the SPA experience for the end user is a fantasy - there's a reason pretty progress bars are popular in SPAs, and it's not because of fast state changes, quite the reverse.

It's funny, your example actually shows the primary benefit of an SPA, and doesn't do anything to show any downsides. A progress bar is a perfect example. You can't show a progress bar with HTML. You would have clicked something, and a new page would be rendered entirely. In the time it took to create the new page on the backend, the user would be staring at either a white screen or the current page. If they're looking at the current page, they probably think the application is malfunctioning, as no user feedback was given to their action.

Whereas, with an SPA, you can _instantly_ show a progress bar, at least indicating that something is going on. And, the very fact that you're showing a progress bar means that the client side rendering isn't the slow action, it's retrieving something from the server. So, the UI was as interactive as possible.

Re: Second-Guessing the Modern Web

#333

Post by TeMPOraL »

mavhc wrote: post #286
pvg wrote: post #270

Earlier quoted context omitted.

I'd like to know which users desired a web-based e-mail client 20 years ago. Millions of them, by then. https://en.wikipedia.org/wiki/Outlook.com#History See also Rocketmail. 20 years ago, the market for web-based email was well-established, not some push experiment.

those crazy users, not wanting to install, configure and update software, download their emails and make sure their backups work, and just get on with actually reading their emails on whatever computer they wanted

Those crazy users who then cry, "what do you mean I've lost 10 years of e-mails forever, becuase my daugher commented with an emoji on a YouTube livestream, and Google decided to go nuclear everything associated with that account?".

Cloud services aren't more reliable than owning your data. They're just unreliable in a different way. You need backups anyway.

Re: Second-Guessing the Modern Web

#334

Post by TeMPOraL »

tsimionescu wrote: post #259
TeMPOraL wrote: post #221

Earlier quoted context omitted.

I'd say you have to group business-facing front ends with consumer-facing front ends, as well as big chunk of mobile development, because all of these are done by the same people from the same programming culture, with the same technologies, patterns and ways of thinking. And with that, I'd argue this is majority of software.

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 of software you have.

Note also that out of the things you mentioned, "factory automation, networking, gaming, small embedded systems", perhaps only small embedded systems projects aren't partly done in web technologies. Gaming definitely is (in AAA games, all the UI that's not the part of core gameplay - e.g. launchers, lobby, marketplace - is likely to be done in Electron or some embeddable webview library). Factory automation, if two companies I worked with over the last decade are any indication, is slowly moving towards webapps for everything. So I imagine networking on the admin side.

It's basically too cheap to make a shit, bloated but somewhat pretty UI with JavaScript. Everyone's doing it, everyone keeps hiring for it.

Re: Second-Guessing the Modern Web

#335

Post by WesolyKubeczek »

andrepd wrote: post #311
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 people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. Not exactly making a value judgement about this, but imagine for a moment any other engineering discipline saying this: Yeah, I kinda made this road 20x less efficient that I could have, but I didn't want to bother with the nitty gritty details. Yeah I'm using trash materials to make this buildin…

You would be shocked to learn how many roads and buildings are actually built like this. Except that in the case of roads and houses, people die sometimes as a consequence.

Re: Second-Guessing the Modern Web

#336

Post by grey-area »

amw-zero wrote: post #332
grey-area wrote: post #237

Earlier quoted context omitted.

You don't need an SPA to use XHR, and your description of the SPA experience for the end user is a fantasy - there's a reason pretty progress bars are popular in SPAs, and it's not because of fast state changes, quite the reverse.

It's funny, your example actually shows the primary benefit of an SPA, and doesn't do anything to show any downsides. A progress bar is a perfect example. You can't show a progress bar with HTML. You would have clicked something, and a new page would be rendered entirely. In the time it took to create the new page on the backend, the user would be staring at either a white screen or the current page. If they're looki…

This is an amazing feature you simply don't need on the majority of web apps, because a) the browser has a loading indicator and b) most web apps are fast enough to not need to tell the user about it, they just load new pages in milliseconds instead.

An in-page progress bar is in most cases a failure of UX, not a success.

Re: Second-Guessing the Modern Web

#337

Post by mirimir »

mavhc wrote: post #321
mirimir wrote: post #120

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

Yeah, that does seem pretty clear. So it goes.

Re: Second-Guessing the Modern Web

#338

Post by grey-area »

deiznof wrote: post #326
grey-area wrote: post #214

Earlier quoted context omitted.

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 The premise of the article is that they are not easier to work with and do not save time in most situations. I agree. Most websites are fundamentally documents, even those that think of themselves as apps. You could even build gmail quite easily as a document based app with some limited use of fetc…

>Your about page is not improved by using react. Well...fortunately people don't use React for making About pages. These examples of why not to use React in these comments are silly, people use them for web apps 95% of the time.

I gave an example of a prominent web app I don't think needs a js framework - most web apps don't IMO as the web correctly centres the experience on documents. Games would be the obvious exception where an immersive app experience is warranted and there are no documents as such, almost every other app works with data organised into stores of documents (i.e. in gmail every email is a document and deserves its own URL IMO).

Re: Second-Guessing the Modern Web

#339

Post by onion2k »

TeMPOraL wrote: post #330
onion2k wrote: post #293

Earlier quoted context omitted.

Very few SPAs give proper user feedback. There could be any number of silent errors in the background. Badly built apps that ignore errors and don't work well for users are certainly not limited to SPAs, and blaming SPA tech for that seems a bit unreasonable.

For "classical" websites, it was not possible to screw it up . The feeback was always there - clear, unmistakable, universal across sites. Boom, "No Internet", site's gone. Press "back" to get the previous state and click again/resubmit later. And it was nice that you could actually do that - use the "back" button to revert to the last correct state even without an Internet connection. Can't do that with almost any S…

The feeback was always there - clear, unmistakable, universal across sites.

It wasn't clear for lots of users. There were common stories of people getting a connection error and refreshing a page only to find their order on an ecommerce site had been taken twice, or that a comment they'd made had been submitted a second time, or that a request to delete something had actually worked but the second request threw up an error because it couldn't be deleted again so it looked like it had failed. These aren't so much of an issue today because browsers warn about form resubmission, but let's not forget that server-side rendered websites in the past were absolutely riddled with UX problems and bugs.

That's not a defence of SPAs, far too many still get the basics wrong, but if you believe it was better when devs made "classical" sites I think there's some decidedly rose-tinted nostalgia going on.

Re: Second-Guessing the Modern Web

#340

Post by dilandau »

runawaybottle wrote: post #139

I’m tempted to step back and evaluate this on another level. Our industry is very big, and any industry that gets that big will be able to house a lot of people just for the sake of it. If you think we have a large amount of fresh frontend people, understand they are hired almost with a one to one correspondence with fresh product/business people. Modern product development is essentially a polishing job on every com…

Nice take. Yes design/frontend has rarely been about actual design. Backend web has rarely been about engineering either, I'd say. Just look at all the elastic search engines left open to the public internet as proof of unconscionable levels of ignorance.
Post reply on HN