Live data from Hacker News

Second-guessing the modern web (2020)

macwright.com

241–250 of 309 posts

Re: Second-guessing the modern web (2020)

#241

Earlier quoted context omitted.

I would say the traditional distinction between a library and a framework, to the extent that the industry has any settled definition for these terms at all, is about who dictates the application architecture and the control flow. A framework typically establishes a runtime environment and then calls into your code to respond to specific events. Common examples are GUI applications that run an event loop responding t…

I think you’re being too pedantic. In 99% of React apps, React “establishes a runtime environment and then calls into your code to respond to specific events”, as you put it.

In 99% of React apps, React “establishes a runtime environment and then calls into your code to respond to specific events”, as you put it.

I don't know what the true proportion is, but obviously a lot of people do choose to use React that way. This has never been in dispute.

My point is that you don’t have to. You can keep things simple with React and keep responsibilities cleanly separated within your code. If you do, you will never have a lot of the problems that people who choose to tangle everything together within their React components can run into.

This whole discussion is about whether modern web development practices are good practices, so I think that’s a fair point to make regardless of how many people currently choose to do things the other way.

Re: Second-guessing the modern web (2020)

#242
post #122

Earlier quoted context omitted.

Well... improving performance because otherwise your server is being slowed down by the load from SSR? That's still saving money in disguise.

No. That's not it at all. If your page takes 3 seconds to show anything at all, your bounce rate will be stupid high. If your page loads nearly instantaneously with placeholders, and then the content loads in over the span of 4 seconds. Your bounce rate will be significantly better. Even though your page loads slower, it will be perceived as faster resulting in less users navigating away before your page starts rende…

I've never had the second scenario feel faster.

Re: Second-guessing the modern web (2020)

#243

Earlier quoted context omitted.

How? It's the most painful, difficult, slow, frustrating, confusing programming experience I've ever had in my 25 years. It's made me want to leave the industry completely and I honestly think I will after this project. It has single handedly slaughtered and destroyed my quarter century love affair with programming. It's a wildly inflexible architecture that aggressively forces their users to conform to an orthodoxy…

I'm sorry you have this experience. I think the most confusing part of React for me was that even though JSX looks like HTML, you're actually not interacting with HTML at all. At its most basic you're just giving React a `[{ type: 'div' }]` and it will create and manage an actual for you.

But you also never had to use JSX and the old docs showed without.

Re: Second-guessing the modern web (2020)

#244

I choose React for personal projects because it's easy. I'm not too concerned with performance. This article doesnt spend much time on developer experience.

And to me this is the root of the problem. Developer experience is awesome so fuck the users, the usability, the performance, the scalability of the business, the time it take to build anything, the stability, the security, the robustness, and whoever will come in 2 years after we left to maintain this. I'll be gone by then.

Sounds like a plan. Developer experience rules!

Re: Second-guessing the modern web (2020)

#245

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…

"Newgrads were trained in hadoop. New tools were Hadoop first. New research was all hadoop."

Reminds me of a job about four years ago: New hire, right out of college, "I studied Java". Surprise! Your team is PHP! Now learn that without any help from your team leader or we're gonna fire you. And they did. Poor kid.

Re: Second-guessing the modern web (2020)

#246

Earlier quoted context omitted.

How? It's the most painful, difficult, slow, frustrating, confusing programming experience I've ever had in my 25 years. It's made me want to leave the industry completely and I honestly think I will after this project. It has single handedly slaughtered and destroyed my quarter century love affair with programming. It's a wildly inflexible architecture that aggressively forces their users to conform to an orthodoxy…

I find it slightly incredible that someone can describe React as "the most painful, difficult, slow, frustrating, confusing programming experience I've ever had in my 25 years", have a whole bunch of complaints about how bad it is, and how it makes no sense, and how it reduces their productivity by a factor of 100 ... and then also use it for 5 years.

Sorry, did you want to get on a call? My email is in my bio

I can go over all of it with you.

Really. Maybe 30 minutes, I'm pretty fast

Re: Second-guessing the modern web (2020)

#247
post #232

Earlier quoted context omitted.

I have a really hard time relating to the conclusion of this. In a big React codebase there are certainly a lot of indirection and "artificial" barriers. The React ecosystem is indeed turbocharged and confusing, atleast if you are trying to follow the latest trends. However, there is atleast a method to the madness. Compared to the bowls of jQuery spaghetti that was used to bring SSR apps to life back in the days, th…

The alternative to React is not jQuery spaghetti or full page reloads. You have solutions that cost a third or less of the effort of doing an SPA (and not as little as throwing in some jQuery) such as Unpoly, or Hotwire.

I'm only bringing up jQuery because the transition from homegrown jQuery madness to React is still a common upgrade path (even more so five years ago). I'm not claiming React is the optimal choice for anything. In many cases it is objectively the most pragmatic one, though. It has arguably the most momentum and mind share of any frontend technology ever. And it just isn't as horrible as the parent and other posts make it out to be.

Re: Second-guessing the modern web (2020)

#248
post #151

I've seen the issue of new hires, time after time, getting a small ui ticket and immediately asking, "where is the client store?" or "Why aren't we using Redux, it'll clean up our code a bunch." Of 20+ applicants I've interviewed this year, only 2 knew about element.dataset and how to create a basic state scoped to that vanilla JS "component". The issue is groupthink and using the hammer on everything.

It's probably because invoking DOM APIs is terribly slow and if you're accessing those fields with any frequency you're better off using a JS object.

The point was that there are many ways to solve the problem. For say, a simple tab layout where you add click handlers to the tabs and hide/ show the contents, you would never notice any latency using the DOM apis. The DOM apis are the core of web development. You need to know them and consider them before moving into the abstraction atop.

Re: Second-guessing the modern web (2020)

#249

Earlier quoted context omitted.

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

To extend your point, I think the linked article suffers from a common trend in web dev editorialism, which is over-generalisation of problems, and reducing the domain into simple binary thinking. A lot of these arguments talk about the dangers of SPAs, but don't talk to the reason why first class interactivity/reactivity exists on the web. It's because for average users, they want to see feedback to their actions im…

But in the wild, on end user machines, many times the SPAs perform worse/slower than SSR ¯\_(ツ)_/¯

And users don't actually want SPAs, users don't care how it's implemented. But users want performance and reliability, and want their pages to feel natural and work fully with all the features other sites have. Anecdotally SPAs often load slowly, break subtly standard web features, and often are slow to use.

Not all SPAs, but a significant amount of them.

As someone who's fluent with SSR and SPAs (react/vue), who consults in the enterprise space, I reach for SSR solutions, about 2/3+ of the time as the appropriate architecture. Of course ymmv but you need to be fluent with all the options to be in position to pick the best tool for the job!

Re: Second-guessing the modern web (2020)

#250
post #36

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…

I liked the overview i remember myself having 15 years ago, today there's a new library/API/service to learn everyday to keep even the simplest things working. Everything is sluggish, everything takes ages to load, to compile, to understand. Also simple web apps i try to prototype takes ages to make and debug. Anyone else feel this? It's like something always goes wrong with some dependency, some build process, some…

What's happened is the philosophy has been that more layers allows less experienced developers to write business systems. This situation with layers on layers of cruft is the result of that.
Post reply on HN