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

171–180 of 309 posts

Re: Second-guessing the modern web (2020)

#171

Post by mixmastamyk »

arsome wrote: post #50
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…

Yep. We recently did an assessment of available UI libraries and pretty much concluded the best maintained libraries with a modern look and feel are all web-focused and we're likely to have to settle for building an electron app if we want to be able to take advantage of the best selection of 3rd party libraries without building as much ourselves. As much as I don't like the ecosystem or Javascript as a language, the…

Think of MS stuff from top to bottom as on maintenance, plus a little extra. Less investment than in the old days as foundational tech is becoming commoditized.

The focus and revenue is from cloud now, since MS has comparatively little hardware or advertising profits.

Develop desktop apps in something focused on it, such as QT. Flutter may mature.

Re: Second-guessing the modern web (2020)

#172

Post by edgyquant »

epistasis wrote: post #110
edgyquant wrote: post #27

Earlier quoted context omitted.

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.

That seems like a good excuse for when there are multiple lists of things, but when it becomes the standard behavior for pagination of a single table of 10 rows, it's ridiculous. > can be cached as needed For requests of > trying to return a single JSON object Certainly there are some cases where JSON might make sense to return to a browser, but the cases that I'm frustrated by should never be serialized as JSON when…

Both caching and json I’m referring to as coming from the backend, not going to the browser from the frontend. I’m saying you break out large data objects (from the backend) into multiple calls and then render them as they respond so you can then see which ones are slowest and should be cached (on the backend.) I get what you’re saying about loading screens for a few rows but I didn’t think that’s what we’re talking about.

Re: Second-guessing the modern web (2020)

#173

Post by catlifeonmars »

1vuio0pswjnm7 wrote: post #99

"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." Wonder how many people using "GraphQL" realise those decent patterns are from the 1970's, i.e., QBE. https://en.wikipedia.org/wiki/Query_by_Example

Huh? I’m not sure how the page you linked is related to GraphQL, except maybe that they are both querying paradigms. They seem largely orthogonal. Am I missing something?

Re: Second-guessing the modern web (2020)

#174

Post by edgyquant »

epistasis wrote: post #155
dntrkv wrote: post #118

Earlier quoted context omitted.

Not sure I get what your comment is saying, but: > making a web app that's great for users That's what the goal is, and that's what SPAs enable. You can't build a modern web app without it being a SPA. The two are basically synonymous, I don't understand how there is even a discussion around this. No user wants to navigate to another page and lose their context. That's why the industry moved to SPAs. If you ever trie…

> The two are basically synonymous, I don't understand how there is even a discussion around this. This erroneous belief is the very source of the problem. Here's a user, telling you that I'm sick of lag from weird multistage loads in apps that gain nothing from keeping local state in browser JavaScript variables. I have never, literally never, thought that a good experience came from a SPA. Give me HN and it's 2000s…

As a counter point: were I to write a hacker news clone it would be an SPA. You wouldn’t know from using it, because I’d break it down into routes using e.g. react router (but that’s really just for organizational reasons) and it’s simple HTML and plain text so there’s really no need to have loading screens. An SPA doesn’t have to be bloated and show loading screens and the aforementioned grey boxes.

I’ll also add that Reddit’s problem doesn’t stem from being an SPA, it still loads state, etc from url navigation just as much as it keeps the state as you browse (depending on where you go on the site.) Reddit’s problems stem from (for some reason I can’t fathom) being the worst UI implementation I’ve had the displeasure of using recently and constantly adding features (before bugs from the last round of useless features are fixed) in an effort to converge towards some kind of weird Facebook clone.

Re: Second-guessing the modern web (2020)

#175

Post by girvo »

acemarke wrote: post #143
girvo wrote: post #75

Earlier quoted context omitted.

Tbh if you're living in React-land and understand Redux, useReducer with useContext has subsumed the need for it in nearly all cases for myself and my team. For the parts it doesn't match, truly global stuff or tonnes of mutation, MobX is nicer out of the box than Redux. Redux can be just as nice and in some ways more powerful, but thats only after installing and configuring X amount of middlewares, with all the type…

Fortunately, you no longer need to "install a bunch of middleware" yourself - Redux Toolkit's `configureStore` gives you a good default setup out of the box [0], and we have TypeScript usage guidelines that infer all the needed state and dispatch types automatically [1] It's also worth noting that there are some significant difference between `useReducer+useContext` and Redux. Not saying those are bad and that you sh…

You bet there’s a big difference! In my experience, too many teams misunderstood what Redux is excellent at, and made a mess of things due to that misunderstanding. In those teams, useReducer alone gets us 80% of the way there, useContext combined with a well constructed reducer solves another 10-15% — and for most of the projects I’ve worked on across different teams with differing skill sets, often 100%.

I’m glad to hear the Typescript inference issues I ran into a year, year and a half ago are solved. That wasn’t Redux’s fault per se, but composing middleware in such a way that the types flowed through correctly was such a hassle previously. Nice to hear it’s better now

Re: Second-guessing the modern web (2020)

#177

Post by dntrkv »

epistasis wrote: post #155
dntrkv wrote: post #118

Earlier quoted context omitted.

Not sure I get what your comment is saying, but: > making a web app that's great for users That's what the goal is, and that's what SPAs enable. You can't build a modern web app without it being a SPA. The two are basically synonymous, I don't understand how there is even a discussion around this. No user wants to navigate to another page and lose their context. That's why the industry moved to SPAs. If you ever trie…

> The two are basically synonymous, I don't understand how there is even a discussion around this. This erroneous belief is the very source of the problem. Here's a user, telling you that I'm sick of lag from weird multistage loads in apps that gain nothing from keeping local state in browser JavaScript variables. I have never, literally never, thought that a good experience came from a SPA. Give me HN and it's 2000s…

> Here's a user, telling you that I'm sick of lag from weird multistage loads in apps that gain nothing from keeping local state in browser JavaScript variables.

You do realize the alternative is the same amount (or more) of waiting with a blank screen, right?

> Or compare the absolute shit-show of new Reddit in an SPA to old Reddit.

You are conflating bad design / UX with SPAs. You can build a SPA that is exactly the same as the old Reddit. Reddit is trying to monetize their site, many of their shitty UX decisions are done with that goal in mind.

> Managing complex UI state is the problem.

...What? Unless you are talking about stripping web apps of their functionality, you can't avoid this. You will have complex UI state. It's just a question of whether you use some shitty, convoluted approach of the olden days, or you use a modern solution that makes this faster and easier.

Anyways, you do realize you are in the minority, right? Most users have an expectation of how modern web apps should function. Redirecting a user for simple tasks doesn't cut it. If SPAs didn't provide a better experience, and in turn, better conversions, companies would not adopt them.

Re: Second-guessing the modern web (2020)

#178

Post by cosmotic »

Zababa wrote: post #28
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 optimization problems are more than just CPU; React encourages lots of little requests in such a way that no amount of computing power can tackle. Coupled with other flawed but popular design antipatterns like skeleton screens, performances is abysmal. Not just long page loading times but browser and machine freezing slowdowns.

BitBucket and Jira have gotten so much worse since they moved to React. With all my computers resources at its disposal, it takes longer now to load a single jira ticket than it did when it was all handled server side 10 years ago. If you look at the chrome debugger, its no wonder why. React fans can stand back, cross their arms, and explain about how atlassian must be doing it the wrong way, but it seems pretty consistent behavior across many react apps.

Re: Second-guessing the modern web (2020)

#179

Post by tusharpandey13 »

m1el wrote: post #163
scrollaway wrote: post #63

Earlier quoted context omitted.

It's absolutely possible, dare I say easy, to do old school SSR wrong. You start with an honest to god html file. Your IDE lints it. You are happy, life is easy. Then you need a second page. So you copy some things over. Then you need a third page, and it becomes apparent that you need a way to share parts of your html pages across multiple files, in a generic way. And kids, that's the story of how I met your templat…

> ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful. Hard disagree. Lisp family of languages have tree templates that are easy to lint, test and get right. They also scale as well as- or better than React. See: https://github.com/yokolet/hiccup-samples

It again raises the issue that you need to learn a new language. Most web developers are not going to learn lisp when js is already available.

Re: Second-guessing the modern web (2020)

#180

Post by phist_mcgee »

m1el wrote: post #163
scrollaway wrote: post #63

Earlier quoted context omitted.

It's absolutely possible, dare I say easy, to do old school SSR wrong. You start with an honest to god html file. Your IDE lints it. You are happy, life is easy. Then you need a second page. So you copy some things over. Then you need a third page, and it becomes apparent that you need a way to share parts of your html pages across multiple files, in a generic way. And kids, that's the story of how I met your templat…

> ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful. Hard disagree. Lisp family of languages have tree templates that are easy to lint, test and get right. They also scale as well as- or better than React. See: https://github.com/yokolet/hiccup-samples

Lisp has had 50 years to catch on, and unfortunately, it has not had the uptake a lot of its proponents would like. I think part of this is the different mental model you need to build around programming when you use these family of languages.
Post reply on HN