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

281–290 of 467 posts

Re: Second-Guessing the Modern Web

#281

Post by krapp »

arvinsim wrote: post #276
theonething wrote: post #137

Earlier quoted context omitted.

And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.

> And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious. Show me the HTML standard that supports SPA submissions that don't reload the page. It seems that your problem is about SPAs, not React.

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

Re: Second-Guessing the Modern Web

#282

Post by ratww »

chrischen wrote: post #180
zerkten wrote: post #160

Earlier quoted context omitted.

> A lot things can be easier if you do things the "wrong way". > It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable... I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to…

I did address that it depends on your requirements. But my point is that it is highly unlikely that any requirements would be better served by vanilla JS + html than say writing your code with ES Next or React, unless you truly have some sort of limited use one-off thing. Tools like webpack, babel, and react are also orthogonal to whether or not you're doing an SPA. These new tools aren't just to make your app a SPA,…

> Tools like webpack, babel [...] but are meant to decouple the maintainability of your code from the implementation details.

Let's be real, the only reason we really need WebPack and Babel at this point is for IE11 compatibility and JSX.

Currently >90% of the browsers (that depends on the country) are evergreen, and have support for most ES6 features, including ES6 modules. As soon as we're able to drop IE11 (when will Google remove IE11 support from Youtube?), the only reason to keep those tools will be JSX, which is frankly a minor convenience compared to the rest of React, and there are multiple alternatives to it that are not that terrible. [2]

Apart from that, WebPack and Babel are extremely hit-and-miss and terrible slow for anything but small-ish projects.

If you're doing SaaS or enterprise, chances are most of your customer-base is already 99.9% on Chrome or, in the worst case, in enterprise Windows-centric companies, Edge and that 0.01% is just waiting for something to tip them off.

I really can't wait to get rid of those two shitshows. Or maybe replace them with something actually useful, like Typescript compiled directly to modules.

-

[1] https://www.npmjs.com/package/domz / https://www.npmjs.com/package/htm / https://www.npmjs.com/package/react-hyperscript

Re: Second-Guessing the Modern Web

#283

Post by eitland »

pvg wrote: post #270
TeMPOraL wrote: post #248

Earlier quoted context omitted.

I'd like to know which users desired a web-based e-mail client 20 years ago. It is my impression that this kind of software is very much push, not pull - i.e. the idea comes from the vendor, not from customers expressing a demand. Which is not a bad thing in itself (a big part of progress is speculative creation); I just don't like the unspoken assumption that companies do things because customers want them to, it's…

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.

Many of us only used it because it was free/available for everyone and we were students or stuck in another situation were it was the only option. If there was both a webmail interface and imap we chose imap.

Some of us still to this day prefer imap/jmap/exchange if the server support it in a meaningful way.

Re: Second-Guessing the Modern Web

#284

Post by richthegeek »

bryanrasmussen wrote: post #210
luxphl wrote: post #150

Earlier quoted context omitted.

That's fair. I have an app that is rendered server side (Node.js/Express) and the frontend is built with jQuery. Made sense at the time. But I ended up adding two very interactive modules and decided React was best for them and added it in piecemeal, and I was right. But now trying to integrate the new features with the older ones, I wish I started with React for everything. This happens more frequently than I'd like…

Currently the site I'm building is a pretty static site of about 30-50 pages that is just brochureware for a non-profit scientific organization, on one hand I feel sort of embarrassed because it feels like I'm back in 2004 and I have a hard time justifying my salary for something like this, on the other hand I'm really super embarrassed at making the wrong solution because a React SPA with a service worker has been o…

Gatsby (static-site generator powered by React) was a massive timesaver for me. Sure, you spend a bit longer setting up some basic components, but the trivial ability to share those components between pages more than makes up for it...

Re: Second-Guessing the Modern Web

#285

Post by richthegeek »

mosdl wrote: post #164
luxphl wrote: post #104

Earlier quoted context omitted.

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

You still have to debug those - if you set the wrong state/etc, things will break like before. All react does is remove the need to modify the DOM directly when you want to modify things.

But setting the wrong state is someting that happens far less and is much more traceable, because the encapsulation of state changes into a single place massively reduces the side effects (and global state) that were the cause of 90% of those bugs in the bad old days.

Re: Second-Guessing the Modern Web

#286

Post by mavhc »

pvg wrote: post #270
TeMPOraL wrote: post #248

Earlier quoted context omitted.

I'd like to know which users desired a web-based e-mail client 20 years ago. It is my impression that this kind of software is very much push, not pull - i.e. the idea comes from the vendor, not from customers expressing a demand. Which is not a bad thing in itself (a big part of progress is speculative creation); I just don't like the unspoken assumption that companies do things because customers want them to, it's…

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

Re: Second-Guessing the Modern Web

#287

Post by doteka »

chrischen wrote: post #180
zerkten wrote: post #160

Earlier quoted context omitted.

> A lot things can be easier if you do things the "wrong way". > It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable... I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to…

I did address that it depends on your requirements. But my point is that it is highly unlikely that any requirements would be better served by vanilla JS + html than say writing your code with ES Next or React, unless you truly have some sort of limited use one-off thing. Tools like webpack, babel, and react are also orthogonal to whether or not you're doing an SPA. These new tools aren't just to make your app a SPA,…

I have been working with various SPA frameworks for about 5 years now, from the bad old days of AngularJS to mostly React nowadays.

Your comment about 1990 seriously rubs me the wrong way because it seems to imply React et al. actually does something to address the points you make. It does not, at all. You still need to test your code on every viewport you support. And now you have to deal with an insane build process that rivals some C++ projects while doing it.

And there is absolutely an objective argument that staying close to the web platform is preferable than 200 layers of leaky abstraction and a 10MB uncompressed bundle of transpiled JS. The language itself is pretty okay in 2020, certainly not worse than anything else from the TIOBE top 10. I would definitely say writing a bunch of plain JavaScript is all that’s needed for most applications out there. If you can’t manage that without a frontend framework, the problem is certainly not with the platform or language.

Re: Second-Guessing the Modern Web

#288

Post by xorcist »

onion2k wrote: post #278
TeMPOraL wrote: post #249

Earlier quoted context omitted.

I'd say especially including these; plain, old, JS-independent, server-rendered sites handle these conditions much better than modern SPAs.

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 so widespread.

Re: Second-Guessing the Modern Web

#289

Post by richthegeek »

krapp wrote: post #281
arvinsim wrote: post #276

Earlier quoted context omitted.

> And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious. Show me the HTML standard that supports SPA submissions that don't reload the page. It seems that your problem is about SPAs, not React.

>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?

Re: Second-Guessing the Modern Web

#290

Post by cygx »

krapp wrote: post #281
arvinsim wrote: post #276

Earlier quoted context omitted.

> And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious. Show me the HTML standard that supports SPA submissions that don't reload the page. It seems that your problem is about SPAs, not React.

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

That was a thing even before AJAX came along, eg via forms targetting an iframe.

A long time ago, I wrote a single-page chat application that continuously updated through chunked transfers, with submission via a plain old HTML form that received a 204 response.

Post reply on HN