Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Second-guessing the modern web (2020)

macwright.com

Post reply on HN
Print view View original

21–30 of 309 posts

Re: Second-guessing the modern web (2020)

#21

Post by [deleted] »

epistasis wrote: post #14
svachalek wrote: post #6

Earlier quoted context omitted.

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.

The problem with SSR, as I understand it according to this article, is that it still removed native link handling from clicks, resulting in the need to override all the basics with bulky JavaScript that doesn't load until some time after rendering. Which, as a user, has bitten me many times. I hate hate hate when a page seems loaded, but something has stalled, and I can't interact with anything. As much as I hate Jav…

[deleted]

Re: Second-guessing the modern web (2020)

#22

Post by breckenedge »

Programming is always trade-offs. Having programmed interactive web UIs for over a decade now, I really enjoyed it the most when programming using BackboneJS. Enough structure to avoid the JQuery spaghetti, but the library didn’t treat you like a moron. Coffeescript was popular back then too, glad to see the better parts of it make it back into JS (and not the semantic whitespace).

Re: Second-guessing the modern web (2020)

#23

Post by madeofpalk »

epistasis wrote: post #14
svachalek wrote: post #6

Earlier quoted context omitted.

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.

The problem with SSR, as I understand it according to this article, is that it still removed native link handling from clicks, resulting in the need to override all the basics with bulky JavaScript that doesn't load until some time after rendering. Which, as a user, has bitten me many times. I hate hate hate when a page seems loaded, but something has stalled, and I can't interact with anything. As much as I hate Jav…

> The problem with SSR, as I understand it according to this article, is that it still removed native link handling from clicks

This is not true.

SSR React still returns HTML. You can set hrefs on a tags. They all work fine.

Re: Second-guessing the modern web (2020)

#24

Post by nemothekid »

One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time.

React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SPAs. Now if you aren't building an SPA you look around and find almost every resource is around building an SPA. Even if you know you don't need an SPA, it's easier to hire, iterate, and even use other open source solutions if you are building an SPA, so you try to hamfist your project into an SPA.

It's a bit like having a bike commute in America. A bike might be the best thing for you to do - cheaper than a car, keeps you healthy and you don't need a garage. But you quickly find that everything is built for cars and it's easier to deal with the disadvantages of a car than try to commute with a bike.

I remember thinking the same thing about Hadoop 5-6 years ago. If you had "small data" you could get what you wanted with SQL and fast disks. But everything else assumed you were on Hadoop. Newgrads were trained in hadoop. New tools were Hadoop first. New research was all hadoop. If you hit a small issue with your DB, almost every solution would be "this is how it's solved in Hadoop". It was hard to even know if what you were trying to do what even possible without Hadoop.

The only optimism I have is that maybe in 5 years we will all collectively wake up and stop trying to shove React everywhere just like we stopped with Hadoop.

Re: Second-guessing the modern web (2020)

#25

Post by danappelxx »

frosted-flakes wrote: post #19
rched wrote: post #15

Earlier quoted context omitted.

React famously claims not to be a framework. Many, myself included, would argue that it is very much a framework in every way that matters.

Which ways are those?

React forces you to write code a certain way. jQuery does not force you to write your code a certain way. In my experience, that’s the single biggest difference between a library and a framework.

Re: Second-guessing the modern web (2020)

#26

Post by mod »

young_unixer wrote: post #20

I have a very good idea of how the web used to work 10 years ago. But when I try to learn Modern Javascript frameworks, the tutorials rarely do a good job of explaining that they won't teach me how to create a normal, traditional website, or if it's even possible to create a normal website with the framework. They simply assume that the modern way is the standard way. I want a modern alternative to PHP, but the JS co…

> modern alternative to PHP

Try...well, PHP. It's pretty modern now and a lot better than it used to be.

I'm not a PHP guy but I do have a few sites running on it and it's nice to go back to my roots.

Re: Second-guessing the modern web (2020)

#27

Post by edgyquant »

epistasis wrote: post #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 slo…

Easier said than done. When you have to load a number of components, each with possibly multiple rows within them, it can take awhile to pull all the data and it is better to break them into a bunch of smaller backend calls that can be cached as needed than trying to return a single json object containing all the data needed to be displayed on a user generated app.

Re: Second-guessing the modern web (2020)

#28

Post by Zababa »

nemothekid wrote: post #24

One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time. React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SP…

I see a big difference between Hadoop and React though: React pushes the costs on the client. This is something that's not often mentionned, but with a traditional SPA, a good part of your code runs on the client, which is server costs you don't have to pay. I don't know if it's something that people do consciously to reduce costs and just never talk about, or if it's an unintended consequence, but it's here. If your React app is too slow/unoptimized, the client will pay the cost, not you. If your Hadoop cluster is too big/not efficient enough/not useful, you're directly paying for it.

Re: Second-guessing the modern web (2020)

#29

Post by qbasic_forever »

theteapot wrote: post #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"?

JQuery document ready handler that makes a XMLHttpRequest and then a pile of jquery DOM manipulation calls to make the DOM state reflect the data you just got back from the server. Basically just a lot of imperative DOM manipulation calls. No templating, no MVC patterns, etc. This is the kind of frontend JS that was all over the web in the early 2000's.

Re: Second-guessing the modern web (2020)

#30

Post by acdha »

frosted-flakes wrote: post #19
rched wrote: post #15

Earlier quoted context omitted.

React famously claims not to be a framework. Many, myself included, would argue that it is very much a framework in every way that matters.

Which ways are those?

You’re still writing code which is based on React’s view of the world, not standard web APIs. Saying it’s not a framework just means that people are cobbling together their own frameworks using some popular libraries, which gives more flexibility at the cost of the various combinations being less tested and harder for someone else to support.

To be clear, this can be a reasonable trade off – but there’s a cost which people often discount until they realize they just spent a week wrestling with abstraction layers.

Post reply on HN