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

291–300 of 467 posts

Re: Second-Guessing the Modern Web

#291

Post by krapp »

richthegeek wrote: post #289
krapp wrote: post #281

Earlier quoted context omitted.

>Show me the HTML standard that supports SPA submissions that don't reload the page. Any HTML form that uses a standard button element rather than a submit button. Attach a JS event listener to it, read the form, post by AJAX. That was a thing long before React came along.

You can actually do that with React. Nothing is stopping you. It's not the recommended way because as soon as you want validation or dynamic fields you need state anyway. And there're easy libraries like Formik that handle all the annoyances for you (although taking you away from raw HTML at the same time). Do you miss punch-cards too?

Of course you can do that with React. GP implied that it was impossible without React, because standard HTML didn't support it, but wasn't correct.

There may be plenty of advantages to using React but it isn't necessary for "SPA submissions that don't reload the page."

Re: Second-Guessing the Modern Web

#292

Post by jordn »

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.

what flexibility does it lack compared to React? I've played with Svelte and love it, but I'm cautious that momentum with React is so great.

Re: Second-Guessing the Modern Web

#293

Post by onion2k »

xorcist wrote: post #288
onion2k wrote: post #278

Earlier quoted context omitted.

I don't agree. A classic PHP-as-it-was-used-15-years-ago site either loads or fails for every user request . That isn't good enough any more. An SPA either loads or fails for the first request, but then they do a lot of things that can mitigate a patchy internet connection - prefetching content, offline mode, bundling things to reduce the number requests, etc. A server-side rendered app doesn't take advantage of thos…

Very few SPAs give proper user feedback. There could be any number of silent errors in the background. It's even evident for relatively basic things such as infinite scroll. Users on sketchy connections won't even see all the items in a web store if their mobile connection is sketchy enough, and they will never even know it. There are some real costs here. Had anyone seriously A/B tested these things they wouldn't be…

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.

Re: Second-Guessing the Modern Web

#294

Post by azangru »

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

> client-side technologies like React have a pretty clear advantage... they're easier to work with and they save us time.

> it worries me that they create a sort of gatekeeping effect on the industry

Aren't these two quotes contradicting one another? If frontend frameworks make frontend developers' job easier, then how can they be regarded as contributing to gatekeeping? If it had not been for them, frontend development job would have been harder and would have required more expertise.

Re: Second-Guessing the Modern Web

#295

Post by fastball »

mellow2020 wrote: post #84
fastball wrote: post #63

Earlier quoted context omitted.

I personally liked how easy it was to install Discourse thanks to Dockerization, and don't care one whit about requiring 10GB of space (cheapest DigitalOcean droplet comes with 25GB).

Fine, but that kinda falls under "without even caring what mountains of code end up running as a result". You use 10 GB instead of a few MB, and get an easy installation vs. an easy installation. It's like driving a huge truck everywhere, even to get the mail from our mailbox, because it starts up real fast and we don't have it far to the garage from our living rooms, and then later on because we haven't walked in so…

Discourse and software like it was not as easy to install. This was literally one-click. Installing wordpress and such in the past required installing PHP, MySQL, yada yada on your server to get everything running.

Re: Second-Guessing the Modern Web

#296

Post by forgotmypw17 »

saagarjha wrote: post #25
forgotmypw17 wrote: post #4

Wikipedia has been taking some strides in this direction. For example, on the "mobile" site, if you follow a link from an expanded page section and then go back, the section is no longer expanded, and you lose your place. (Then it re-expands, but you're in a completely different place on the page now.) This type of stuff is one of the reasons why I choose to support older browsers like Netscape, IE, and Lynx. I think…

It turns out that aside from HTTPS, most older browsers can do quite well with HTML websites! If you do it right, all old browsers will be able to render it because it'll work in WorldWideWeb.app.

This is true to an extent, as I have discovered.

However, if you want universal html (no changing the html for individual browsers) and some half-decent web-app functionality and no-js compatibility and accessibility and for it to look pretty, be prepared to spend many hours tweaking it.

Here's a video of some testing I did recently. Here, I discover that IE doesn't play nice with being forwarded to a URL which has an anchor at the end.

https://www.youtube.com/watch?v=M5tGkDgpq7w

Re: Second-Guessing the Modern Web

#297

Post by 1337shadow »

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 me the real subject would be "the death of templates in favor of decorator based objects", which could have been predicted by the GoF that recommended the decorator pattern for GUIs, and makes great sense for the tag-based language that HTML is.

Template languages often impose language limitations to make easier for HTML/CSS coders to work with, without breaking the backend code, isolating their codebase from the backend codebase.

These limitations make them less composable and reusable than functions or objects, and obviously show more drawbacks than advantages for one-man-development, and reuse across projects.

My wild guess is that if we replace templates by components on the server side, we will see less React & friends, for me they mainly demonstrate the clear win of component based patterns against template spagetti.

Re: Second-Guessing the Modern Web

#298

Post by kitd »

pjmlp wrote: post #213
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 have been developing all sorts of native and Web applications for a couple of decades now, and SPAs is something I avoid as much as possible. And yes, I also implemented interactive desktop like applications as Web applications. Server side rendering frameworks, with support for components and just enough JavaScript go a very long way, and best of all, they are faster than SPAs in every kind of device that customer…

Server-side rendering + Turbolinks [1] + jQuery-or-equivalent gives you an SPA experience anyway, without the client-side bloat. With judicious use of markup, it can be massively more responsive.

[1] - https://github.com/turbolinks/turbolinks

Re: Second-Guessing the Modern Web

#299

Post by inapis »

chipotle_coyote wrote: post #183
luxphl wrote: post #115

Earlier quoted context omitted.

I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more. It's certainly faster to use jQuery to change a CSS attribute than it is to setup a React project but what's not considered in that calculation is maintaining the state of that attribute or making changes to the logic in the future. Especially on code you didn't write originally. If all you have to do…

I think the problem/frustration is simply this: there are a lot of web sites out there that are, well, web sites, not web applications. Looking back at the linked article, it goes out of its way to talk about many ways that React is "pretty great" and "for a particular scope of use cases it's the best tool you can find," but then goes on: > There are a lot of problems for which I can't see any concrete benefit to usi…

Your argument hinges on the assumption that the products have a final conclusion. I can start building a product in hugo, say - I’m just displaying information in charts and generating predefined reports. Time passes more users are added and now I need to identify each users reports. Now I need a server and at this stage I can get away with SSR. More time, more organizations, more complexity. All of this can still be handled by SSR. The real kicker happens when people start demanding the ability to generate their own reports by supplying their parameters. They want the ability to write their own queries. They want WYSIWYG building blocks. They want to define their own templates.

Very quickly we are in a territory well done with react than with Hugo.

Most products, especially if it’s a company, are like this. Products are constantly evolving. Whether products should be constantly evolving is a different discussion and tools are only a small part of that discussion.

Re: Second-Guessing the Modern Web

#300

Post by austincheney »

chipotle_coyote wrote: post #183
luxphl wrote: post #115

Earlier quoted context omitted.

I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more. It's certainly faster to use jQuery to change a CSS attribute than it is to setup a React project but what's not considered in that calculation is maintaining the state of that attribute or making changes to the logic in the future. Especially on code you didn't write originally. If all you have to do…

I think the problem/frustration is simply this: there are a lot of web sites out there that are, well, web sites, not web applications. Looking back at the linked article, it goes out of its way to talk about many ways that React is "pretty great" and "for a particular scope of use cases it's the best tool you can find," but then goes on: > There are a lot of problems for which I can't see any concrete benefit to usi…

My problem is that developers seem to be generally afraid of the technology and employers allow fragile products due to a talent deficit.

https://news.ycombinator.com/item?id=23137367

Post reply on HN