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

101–110 of 309 posts

Re: Second-guessing the modern web (2020)

#101

Post by edoceo »

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…

How much is that render cost? Would love to see the trade-off comparison. Does it really save any money?

Re: Second-guessing the modern web (2020)

#102

Post by tshaddox »

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…

Server-side Node.js still exists and, if you like, can be quite similar to good old PHP. A "Hello World" app in Express.js is pretty barebones and easy to get started with, and there are probably lots of comparable alternatives. I've always found Express.js to have a big community with lots of guides and info, although I admittedly haven't had the experience of coming to it as a newcomer to programming or the web.

Re: Second-guessing the modern web (2020)

#103

Post by webmaven »

dntrkv wrote: post #92
reaperducer wrote: post #74

Earlier quoted context omitted.

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 gea…

Nobody teaches that. You don't offload things to the client in order to save money. You offload things when it will improve performance. Most of the processing power and bandwidth will still be incurred by the server, just at a different time in the lifecycle of the app.

Well... improving performance because otherwise your server is being slowed down by the load from SSR?

That's still saving money in disguise.

Re: Second-guessing the modern web (2020)

#104

Post by dntrkv »

edgyquant wrote: post #27
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.

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.

Re: Second-guessing the modern web (2020)

#105

Post by tshaddox »

jdwyah wrote: post #43

Every Product Manager: “I dunno, ever since they started saying React, everything takes 3x longer to ship and we have 2 teams on very challenging technical projects to enable performance that doesn’t suck”.

What were they using before they started saying React? Backbone.js? JQuery? How big and how interactive was the website at the time they started using React?

Re: Second-guessing the modern web (2020)

#106

Post by lhorie »

Chris_Newton wrote: post #81
lhorie wrote: post #37

Earlier quoted context omitted.

- It "calls you" (i.e. you never explicitly call your React components, React does) - It permeates your codebase (e.g. migration from moment to date-fns is something you can realistically do piecemeal, React to Vue or vice versa not so much) - It enforces a specific architectural paradigm (components) to the exclusion of others (e.g. MVC, MVVM, etc) - Its direct competitors are frameworks (Angular, Vue, Backbone, Aur…

Almost everything in your first few points there depends on how you choose to use React, though, rather than being inherent in the library itself. It "calls you" (i.e. you never explicitly call your React components, React does) The starting point for doing anything with React is where you call it to render a certain component at a certain point in your document. There are things built on top of React, such as Next.j…

> The starting point for doing anything with React is where you call it to render a certain component at a certain point in your document

You're trying to use the literal meaning of "you call it" to make an argument but that argument doesn't support the position you think it does. Yes, React has `ReactDOM.render()`, but did you know Angular.js also has an entry point called `angular.bootstrap()`? Vue has `new Vue()` and Mithril has `m.mount()`. In all of these frameworks there are various callable APIs, but that fact doesn't oppose the fact that your React component code is called by React, not by you.

> It is possible to use React only as a convenient rendering library

This is also possible with Vue, Hyperapp, Choo, Mithril and many other frameworks.

> Nothing about that forces you to adopt any specific architecture in the rest of your application

Again, same can be said about various frameworks. You don't need to use Vuex. Lichess uses MVVM w/ Mithril. Etc. Ultimately, componentization offers a prescriptive organization pattern. Nobody complains about React code being spaghetti like they do about jQuery, and for a good reason (sagas and other auxiliary libraries aside)

Re: Second-guessing the modern web (2020)

#107

Post by 1vuio0pswjnm7 »

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

Earlier quoted context omitted.

firefox "https://en.wikipedia.org/w/index.php?limit=500&profile=all&search=spa" At the top is the link to the Disambiguation. https://en.wikipedia.org/wiki/Spa_(disambiguation) A more specific search, e.g., "single page", will not redirect. In some ways, for discovery, Wikipedia's search engine is better than Google's. For one, it is non-commercial and does serve ads based on past surveillance of the user's activity.…

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 mean ....").

However, change the search string "spa" to something more specific and then see all the search results.

For example:

https://en.wikipedia.org/w/index.php?limit=500&profile=all&s...

Increase limit= to a number greater 500 if desired, or smaller if want to speed up the search.

Re: Second-guessing the modern web (2020)

#108

Post by tshaddox »

epistasis wrote: post #41
madeofpalk wrote: post #23

Earlier quoted context omitted.

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

Aha, thanks. So when the author writes: > So, Server-Side Rendering runs your JavaScript frontend code on the backend, creating a filled-out HTML page. The user loads the page, which now has pre-rendered content, and then the JavaScript loads and makes the page interactive. Does this mean that one could make the page interactive with server side rendering, but it's not normally done? Or did I completely misunderstand…

If you click on an tag before the JavaScript has loaded and React has hydrated, the browser will do a full page load of the URL that you clicked on. Assuming that new page is also rendered on the server, it should work fine and feel just as good as if it was a traditional server-rendered HTML web site or if you had JavaScript turned off. (Of course, things that do require JavaScript for interactivity, like custom tooltips on hover, custom form validation, etc. won't work until the JavaScript has loaded.)

Re: Second-guessing the modern web (2020)

#109

Post by scrollaway »

zozbot234 wrote: post #57
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…

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 heavy, it's that awful dropdown menu with dozens of nested filters that rely on user-input data which is awful to build serverside, but incredibly easy to build client side.

Re: Second-guessing the modern web (2020)

#110

Post by epistasis »

edgyquant wrote: post #27
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.

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 sent to the client, and should be sent as tables or other HTML. Having JSON transformed by JS as the only method is displaying data feels like the fundamental architectural error that is degrading the web for users.

All these years later, huge advances in compute and bandwidth, and in many ways that good 'ol 28.8k modem in a Penguin box was as responsive.

Post reply on HN