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

61–70 of 309 posts

Re: Second-guessing the modern web (2020)

#61

Post by tekstar »

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…

Looks like you're trying to reinvent some wheels there.

No harm in doing so but just so you know, React (or my preference, a tinier version called Preact) would let you update new chat contents without blowing away all the other InnerHTML content. The way you're doing it now will result in a flicker, and mess with things like highlighted text will unhighlighted when replaced. And that's just with the basic dumping of the chat text into a DOM innerHTML. I'm pretty sure what you're doing there would also be susceptible to XSS without additional filtering.

Re: Second-guessing the modern web (2020)

#62

Post by nexuist »

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

Re: Second-guessing the modern web (2020)

#63

Post by scrollaway »

ian1321 wrote: post #40

The amazing part to me is that SPAs are so much harder to do right compared to old-school server-side rendered HTML. One could be forgiven if they think a "simple" SPA is a good starter project, but they'd be very wrong. Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible. On top of this, understanding how data flows through these SPAs is no sm…

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

ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful.

It's easy to get things wrong in that world, because nothing gets things right.

There's kludges of course, things that generate html entirely programmatically from their own language, or some weird abstraction.

These all suck too. You have to learn new languages, or weird shorthands, or at best new APIs. None of them truly took off either so the tooling is poor.

You know what's a language that already has tons of tooling? JavaScript.

You know what's a robust API for building HTML that you already know, that is already supported by virtually everything? The DOM.

And you know what's a markup language you already know and can intuitively parse without having to learn new things? HTML.

Well, guess what.

Re: Second-guessing the modern web (2020)

#64

Post by jkaplan »

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 landing page), then yes it's overkill... but so is something like Rails/Django! Just use a static site (+ generator, if needed.) If you're building an "app"/you're interacting with a database, then you're almost certainly going to want end up wanting interactivity. And it snowballs -- a little state change here, an ajax call there, and all of a sudden your front-end is ballooning without structure or modularity.

Re: Second-guessing the modern web (2020)

#65

Post by mbgerring »

There’s a really great fix for this, which is to design JS frameworks to not take over the entire application.

I have been waiting for a long time for the framework that will let me write a web component, and then include that web component in a regular HTML page, in a way that’s supported by the idioms and best practices of that framework.

It’s also worth pointing out that all of these drawbacks to rendering web pages on the front end via JavaScript were obvious the moment these frameworks were introduced. The critics at the time were right. But we still lack for easy-to-use alternatives.

Re: Second-guessing the modern web (2020)

#67

Post by bhauer »

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 making something "bearable" is confusing.

Re: Second-guessing the modern web (2020)

#68

Post by nahuel0x »

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…

was Flutter included in the comparison?

Re: Second-guessing the modern web (2020)

#69

Post by TZubiri »

mbgerring wrote: post #65

There’s a really great fix for this, which is to design JS frameworks to not take over the entire application. I have been waiting for a long time for the framework that will let me write a web component, and then include that web component in a regular HTML page, in a way that’s supported by the idioms and best practices of that framework. It’s also worth pointing out that all of these drawbacks to rendering web pag…

"There’s a really great fix for this, which is to design JS frameworks to not take over the entire application."

But then your framework wouldn't replicate itself with the prolific genius of Genghis Khan or the coronavirus.

Re: Second-guessing the modern web (2020)

#70

Post by austincheney »

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…

Yes there is a framework gravity. More directly it is Invented Here Syndrome: https://en.m.wikipedia.org/wiki/Invented_here

Due to missing leadership and absent mentorship many developers are hoping tools provide the guidance they need.

Post reply on HN