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

111–120 of 309 posts

Re: Second-guessing the modern web (2020)

#111

Post by jkaplan »

mbgerring wrote: post #94
dmalik wrote: post #87

Earlier quoted context omitted.

> design JS frameworks to not take over the entire application. Facebook did just that with React. React doesn't have to be used only as a single page app. Use it for just a single component on a page if you want.

Nobody does this in practice. Tooling, tutorials, frameworks, etc are all created around the idea that the entire application is an SPA with a single root element. I understand that it’s possible to do this in theory, and that’s why I said I want to see a framework where the idioms and best practices are geared for this kind of use.

I'd encourage you to give React a try for this use-case! I've done this exact thing -- slowly introducing React in certain places in a large web app -- and it's worked great.

You're right that tooling/tutorials are mostly geared towards SPA usage, but React itself is designed to work for both. You'll have to decide on a pattern for "bootstrapping" React in a given page or element, since there aren't well-established best practices, but after that it's smooth sailing.

Re: Second-guessing the modern web (2020)

#112

Post by dntrkv »

dmalik wrote: post #87
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…

> design JS frameworks to not take over the entire application. Facebook did just that with React. React doesn't have to be used only as a single page app. Use it for just a single component on a page if you want.

In fact, that's one of the major contributors to React's success. It's so easy to integrate into an existing application. If you take any major tech company (that's existed before React) that has adopted React as their main framework, I will bet the majority of them are, to this day, running React in parallel with another framework (and many are running it WITHIN another framework).

Re: Second-guessing the modern web (2020)

#113

Post by epistasis »

dntrkv wrote: post #104
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.

It's like all of these posters have never worked on a large-scale app, acting like the decision to lazy load content is made just because we don't have anything better to do.

Sure, there's lot of code to write, but is the end goal writing code, or making a web app that's great for users?

Re: Second-guessing the modern web (2020)

#114

Post by snarkypixel »

Personally I love SPAs and would still use them all the way instead of Django/Rails. The problem with server-side rendering is you need to start duplicating all the code the moment you need some front-end interaction. Also, I prefer when the interactions are snappy, and having to hit the server on every click to fetch some html feels so slow.

I do agree though that building SPAs is too complex and that we haven't yet found the perfect solution.

Re: Second-guessing the modern web (2020)

#115

Post by tshaddox »

theteapot wrote: post #4

For me the clear threshold for when you've gone too far with SSR is if it needs auth. Just do not go there. So this is not an SSR issue per se, it's poor SSR implementation issue IMO.

I'm not sure why that threshold needs to exist. It shouldn't be any harder for your SSR to check a cookie than it is for your REST API to check a cookie. There are some benefits of SSR that don't apply to pages with private content, namely being able to cache the HTML response in a CDN and (arguably) being treated better by search engine crawlers, but many of the benefits of SSR apply just as well to private content.

Re: Second-guessing the modern web (2020)

#116

Post by [deleted] »

1vuio0pswjnm7 wrote: post #107
arsome wrote: post #98

Earlier quoted context omitted.

The link you used directly brings up the wikipedia article on Spas. Not sure that's what you were going for. :)

You need to follow the Spa Disambiguation: https://en.wikipedia.org/wiki/Spa_(disambiguation) In that sense Wikipedia is a bit like Google in that they try to guess what the user is searching for, perhaps what is most popular. Thus, a search for "SPA" automatically redirects to the article on Spa as in therapeutic water treatment. A link to the Disambiguation page, if it exists, will always be provided (cf. "Did you…

[deleted]

Re: Second-guessing the modern web (2020)

#117

Post by tshaddox »

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…

Another big issue is the ability to seamless transition parts of your software between different programming models. We just don't have good solutions to this that I know of. The thing with SPAs is that you are probably worse off starting with a traditional server-rendered HTML web site and slowly introducing more and more interactivity, unless you know you won't eventually be better off with an SPA at the foundation (or unless you've planned and budgeted for that eventual rewrite).

React is actually great at embedding individual interactive components on a static HTML page (like an interactive chart or table component, or even a fancy button). You can go a long way just having your Rails app render a navigation menu and application shell, and each page just loads a big React component in the main content section. Great!

But then you need to update a little bit of that application shell in response to a visitor interaction or some newly-fetched data. Maybe one of your menu links needs a little red number next to it to indicate the number of unread messages. Still easy, with JQuery or whatever DOM manipulation library you're using. But then when the visitor clicks on one MessageRow component in your big MessageList React component and reads the message. The unread count didn't change! That's still easy to fix though. But pretty soon you're writing a lot of manual DOM manipulation code to sync every bit of data bidirectionally between every source of mutation and every UI element that depends on that bit of data. You'd be better off with an SPA, or at least with having React grow to own a little bit more of your application shell!

Where this line gets drawn is tricky, and I don't think the conclusion is "always use an SPA framework from the beginning of every web site project." But I do think the options to conveniently and maintainably use SPA frameworks to render traditional HTML pages on the server are improving a lot more than the options to gradually introduce whole-page-level interactivity to traditional server-rendered HTML frameworks.

Re: Second-guessing the modern web (2020)

#118

Post by dntrkv »

epistasis wrote: post #113
dntrkv wrote: post #104

Earlier quoted context omitted.

It's like all of these posters have never worked on a large-scale app, acting like the decision to lazy load content is made just because we don't have anything better to do.

Sure, there's lot of code to write, but is the end goal writing code, or making a web app that's great for users?

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 tried to manage complex UI state in the jQuery/Backbone/Knockout/etc days you would see that a React SPA is a huge improvement. It actually enables devs to build complex apps without getting bogged down in bugs.

Re: Second-guessing the modern web (2020)

#119

Post by themarkn »

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…

Web components have been a possible build target for Vue for a while. It seems totally possible to set up a Vue project like you’ve suggested, use all the Vue conventions & tooling, and output web components that you then use a la carte. Maybe I’m missing something about what you are looking for, but more details are here: https://vuejsdevelopers.com/2018/05/21/vue-js-web-component/

And I’m sure the same can be done in other frameworks.

Re: Second-guessing the modern web (2020)

#120

Post by h0l0cube »

scrollaway wrote: post #109
zozbot234 wrote: post #57

Earlier quoted context omitted.

The "server cost" of traditional SSR is heavily overrated. It can be made small enough to be basically a rounding error compared to everything else your backend is doing. Even more so since retrofitting SSR onto a JS single-page application is quite inefficient, so you end up paying for that load many times over.

This is only sometimes true. Other times, cutting the server rendering makes things a million times easier because maybe you're not contacting your database, or you're offloading large per-user objects to the client instead of keeping them in ram for thousands of uniques per minute, or, or ... Some calculations are less heavy on the client side. It's not building the html itself once you know what you need that is he…

> because maybe you're not contacting your database

Except you will anyway, to do all those API queries you need to fill the page. That involves multiple handshakes back the server, and yet more server-side resources tied up.

> or you're offloading large per-user objects to the client

This access happens either way, and will be discarded in short order by any cache, even using the most naive LRU policy.

Post reply on HN