Live data from Hacker News

Second-guessing the modern web (2020)

macwright.com

41–50 of 309 posts

Re: Second-guessing the modern web (2020)

#41

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, resulting in the need to override all the basics with bulky JavaScript that doesn't load until some time after rendering. Which, as a user, has bitten me many times. I hate hate hate when a page seems loaded, but something has stalled, and I can't interact with anything. As much as I hate Jav…

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

Re: Second-guessing the modern web (2020)

#42
post #37

Earlier quoted context omitted.

Which ways are those?

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

from the author of Mithril ;)

Re: Second-guessing the modern web (2020)

#44

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…

[deleted]

Re: Second-guessing the modern web (2020)

#45
post #35

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…

> gray boxes simulating text This is one of the worst UI trends in the last decade. Mock content gives devs permission to ship slow APIs, and they can even look janky when your API is too fast. It feels like watching a half hour of trailers before the movie starts.

You want to know why they exist? Because of Google Core Web Vitals metrics!

CLS (Cumulative Layout Shift) can go to zero if you place proper skeletons.

I still prefer it to content jumping around when the API response is done.

Re: Second-guessing the modern web (2020)

#47
post #18

This is the money quote for me: > Frameworks should lure people into the pit of success, where following the normal rules and using normal techniques is the winning approach. > I don’t think that React, in this context, really is that pit of success. A naïvely implemented React SPA isn’t stable, or efficient, and it doesn’t naturally scale to significant complexity.

It is a pointless generalization. Not every React SPA is the same. Some scale, some don't. Some use server rendering, some don't. React may be a perfect fit for your app, or it may not. It's not like a "naively implemented" app using vanilla JS or server templating or any other framework will be automatically fast and scalable. Quality of input = quality of output, regardless of what abstractions you decide to use in…

I thought the original article had a lot of nuance, actually, and did a good job describing where React reasonably fits in the scheme of things.

I would argue your statement that “every React app is different” is part of the problem. There are so many react apps that are essentially the same but each one is implemented with some bespoke cocktail of parts because React isn’t really a framework, and it doesn’t solve the “rest of the app.” This isn’t inherently a bad thing, but it contributes to the general confusion and churn that had made front-end engineering significantly harder and less fun - at least in my experience - over the last 5 years or so.

Re: Second-guessing the modern web (2020)

#48

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…

> Imagine a newbie that never developed a normal website and now thinks React/client-side rendering is how the web is supposed to work.

I had the luck of learning the web "the old way" at the university. First HTML, then CSS, then PHP where we cobbled together a small website (our end projet was a recipe website where you could create an account and post recipes, so there was database usage too). All of this was made in WAMP/XAMP. We had a course on JavaScript the next year but I honestly didn't understand anything. Some time after though, when I started working again on the web, having an understanding of HTML, CSS and what you had to do by yourself made me understand fundamental web technologies on a deeper level than most of my peers that started with the MERN/MEAN/MEVN stack. I'm sure they'll be more attractive to employers though.

Re: Second-guessing the modern web (2020)

#49

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.

Re: Second-guessing the modern web (2020)

#50

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, there's so much tooling around it and the libraries available seem to be miles ahead of other options. I'm hoping Redux and TypeScript can make it moderately bearable. Fingers crossed.

Seriously, what is there? Microsoft doesn't even have a clear direction for desktop apps - their most recent stuff like VS Code and Teams are built on Electron.

Post reply on HN