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

71–80 of 309 posts

Re: Second-guessing the modern web (2020)

#71

Post by zabzonk »

zabzonk wrote: post #49
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…

Sorry, what's a "SPA" - can't seem to find it by Googling.

BTW, I'm not a web developer and don't see why I should have known what "SPA" means.

Re: Second-guessing the modern web (2020)

#72

Post by Zababa »

nexuist wrote: post #62
Zababa wrote: post #28

Earlier quoted context omitted.

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…

I think this is a good assumption, but it breaks down when you look at bandwidth costs. A large reason why these apps take so long to load is because of the kb of dependencies and bundles they have to download. That adds up quickly with many visitors, and there's practically no way you would be accruing the same amount of bandwidth costs with a bland PHP or direct HTML response.

You're absolutely right. You can put the files on a CDN at least but I'm not sure if it's enough.

Re: Second-guessing the modern web (2020)

#73

Post by theteapot »

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…

Redux?! Bearable?! What is happening?!

Re: Second-guessing the modern web (2020)

#74

Post by reaperducer »

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…

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.

It's very deliberate. It's even what is taught in colleges.

I've had debates with recent graduates who believe the proper way to build anything from a web site to an app is to offload as much of it as possible on the client. If the client doesn't have the latest gear? Too bad. They're an "edge case" and shouldn't be allowed to be on the internet. Go curl up in a corner and die, you old and poor people.

The tech world would be an entirely different world if ethics were part of the required curriculum.

Re: Second-guessing the modern web (2020)

#75

Post by girvo »

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…

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 confusion that can add :(

Re: Second-guessing the modern web (2020)

#76

Post by waingake »

jkaplan wrote: post #64

I agree with a lot of these points, but differ slightly in two regards: 1. In my experience React DOES lure people into the "pit of success" in at least one important aspect -- modular and re-usable front-end code. React is certainly not the only way to get this, but it does help force you into some good patterns. 2. The "sweet spot" for React is pretty large. If your site is truly static (e.g. a blog, a product land…

Yes this. The article mentions the following as poor candidates for client side rendering. I can agree with blog, but suggesting a tool like React is a poor choice for a shopping cart is naive.

> Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites.

Re: Second-guessing the modern web (2020)

#77

Post by sergiotapia »

I tried to go the old-school route of server rendered pages. But then I thought to myself: I would need to write an API later so that's double the amount of work. What if I'm also going to make a mobile app?

I can spin up a graphql API, use create-react-app, and react native, use apollo client to share lots of code and be done with it.

The alternative is more "pure" I guess but it's a lot of double work.

Re: Second-guessing the modern web (2020)

#78

Post by waiseristy »

zabzonk wrote: post #71
zabzonk wrote: post #49

Earlier quoted context omitted.

Sorry, what's a "SPA" - can't seem to find it by Googling.

BTW, I'm not a web developer and don't see why I should have known what "SPA" means.

Downvotes on HN are not at all related to the quality of your question. It's fine

Re: Second-guessing the modern web (2020)

#79

Post by tshaddox »

The part about API changes being incompatible with old versions of the frontend (that are still loaded in someone's tab somewhere) is a valid problem, but honestly isn't significantly worse for SPAs than for traditional server-rendered HTML websites. Your basic HTML web form will break too, if your API has changed in an incompatible way!

It's true that traditional websites would coincidentally get a new version if the visitor happened to click a link, but relying on them to do that to avoid seeing an error isn't a better solution than an SPA notifying the visitor that they need to refresh to avoid seeing an error.

Also, I don't really agree with the author's view that needing to refresh an SPA to get a new version is "bizarre" or "something from the bad old days of desktop software." On the contrary, it's an extremely prominent UI element and a fundamental action in all web browsers!

That said, one "trick" is to have your SPA silently listen to your server for app version updates, and when there's a new version, just make your client-side Link component do a full page load (instead of a client-side route transition). Then at least you'll have the same behavior as traditional HTML websites.

Re: Second-guessing the modern web (2020)

#80

Post by sunsetSamurai »

mathgladiator wrote: post #32

I'm no fan of React, and I'm building a new back-end and front-end that is probably heretical to... well.. everything. What I have found is that if you have reactivity from your back-end, then front-end reactivity is... easy. My focus is on board games, but the idea generalized pretty well. As an example, my dumb chat room: https://github.com/mathgladiator/adama-lang/blob/master/demo... I really need to focus on this…

Hi, what type of board games are you working? I wanna create a makruk game server and don't even know where to start
Post reply on HN