Live data from Hacker News

Second-guessing the modern web (2020)

macwright.com

1–10 of 309 posts

Re: Second-guessing the modern web (2020)

#2
> "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. There’s great documentation for everything else, but old-fashioned data loading is relegated to one example of how to mock out ‘fetch’ for testing, and lots of Medium posts of varying quality."

What is "old-fashioned data loading"?

Re: Second-guessing the modern web (2020)

#3
This is the money quote for me:

> Frameworks should lure people into the pit of success, where following the normal rules and using normal techniques is the winning approach.

> I don’t think that React, in this context, really is that pit of success. A naïvely implemented React SPA isn’t stable, or efficient, and it doesn’t naturally scale to significant complexity.

Re: Second-guessing the modern web (2020)

#6

> "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. There’s great documentation for everything else, but old-fashioned data loading is relegated to one example of how to mock out ‘fetch’ for testing, and lots of Medium posts of varying quality." What is "old-fashioned data loading"?

The truly old fashioned way is to load your data and render the page with it in the server. A simplicity that was lost in the SPA, but that's what SSR gives back to you. But since this is an anti-SSR piece I'm not sure what it's getting at.

Re: Second-guessing the modern web (2020)

#7
As mostly a user that doesn't develop web apps anymore, all this feels very true to me.

I'm soooooo sick of interfaces that load an empty useless shell of UX chrome and then slowly trickle in content at some later time, and leave spinners, or even worse, gray boxes simulating text.

Send the text content in the initial reply, please! It's bad enough having to wait for webfonts, but when you wait to start doing the slow database query for content until after an html shell has been loaded, and after a huge JavaScript bundle has been parsed and executed, you're just wasting time. Reminds me of the Google Web Toolkit of yore. We really haven't progressed much in the decade for single-page apps since then, when it comes to the user. And that's a horrifying thought.

Re: Second-guessing the modern web (2020)

#8
post #5

One day browsers will natively support modules and "Bundle Splitting" as the article calls it will just be the intuitive and automatic thing to do. Until then we have webpack.

Most browsers do support js modules today but it's kind of an awkward situation to say the least. And if you need to support older browsers you may as well not bother, you probably use Webpack and/or Babel (or TypeScript) anyway for other reasons. Especially if you're trying to do isomorphic stuff for an SSR app, as NodeJS then has its own pile of idiosyncrasies and baggage around module support.

This situation has been playing out for many years and it has only gotten more confusing.

Re: Second-guessing the modern web (2020)

#9

> "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. There’s great documentation for everything else, but old-fashioned data loading is relegated to one example of how to mock out ‘fetch’ for testing, and lots of Medium posts of varying quality." What is "old-fashioned data loading"?

JSON or XML, using REST or websocket maybe? One request per "page load" is an anti-pattern in SPA's though - you should send all static data once, lazy load large assets like images, and sync only the dynamic non cacheable data.
Post reply on HN