Live data from Hacker News

Second-guessing the modern web (2020)

macwright.com

271–280 of 309 posts

Re: Second-guessing the modern web (2020)

#271

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

> Redux is a good example of this. It requires a load of boilerplate and seemingly contrived ways of reacting to interactions. What most people don't understand is that this is the primary feature of it. It is a rigid flow of data that enforces you to go through the same steps each time. As such, you can get into a Redux powered app and understand it relatively quickly.

No this is totally completely wrong.

Tools don't make the programmer competent.

The person that created a mess of jquery will create a mess of react, ember, vue or whatever they are using. They don't become better programmers with more authoritarian tools.

This delusional attribution was supposed to happen with OOP in the 80s, RAD in the 90s, it doesn't work. You can't shove competency into people by enforcing upon them more complicated systems. In programming, bureaucracies, companies, governments, any human system.

Instead what you get is more complicated messes. Look at any Java code for a great example. Or bureaucratic institutions or anything else structured under supposedly all-encompassing ideas. All you've given is a shinier and longer rope to hang themselves with.

It's a long promulgated empirical claim with lots of empirical evidence stating it's dead wrong and does not work.

Javascript, the browser, html, and css, that is a stack. I say and a button appears. I don't have to poke addresses for graphics, implement a line algorithm, a flood fill, define hit points, create the abstraction of a document that moves with a scrollbar or that flows around a page ... literally millions of things are solved.

These tools (JS, HTTP, HTML, CSS) seek to empower and enable, not constrain and dictate. That's the difference. This is why TBLs open system kicked Ted Nelson's Xanadu's ass and why 30 years later he still doesn't have shit to show.

The baseline supposedly "raw" tools are already incredibly high level and sophisticated.

What about your "MVC"? HTML is the model, CSS is the view, Javascript is the controller ... that's why there's 3, that's why they do what they do, that's why they are there.

It already exists. It's already there.

What these frameworks do is go in and break all of that. It becomes one big garbled mess again. Solved problems become unsolved and the programmer gets blocked from using any reasonable solution to get back there. All in the name of the authoritarian appeal that this will produce better code.

It's utterly absurd. It doesn't produce better systems or code, it hasn't ever, and it will continue to not.

Instead it will produce deprecated unusable messes that need full-time staff to babysit the complexities of all the parts and make sure the cathedral of interacting dependencies doesn't catastrophically collapse. That's why these projects have 6-figure salaried engineers on "maintenance". Look at the batshit insanity on the server side with k8s and tools like prometheus these days. It's trying to solve problems by tossing a bag of hurdles and complexity at it. Before that it was chef/puppet.

Sometimes these days I see both k8s and chef on systems that have become magically more broken and have more people working on them with more downtime than they were before.

It's why these things are constantly "rewritten". Because the old authoritarian complex thing is finally acknowledged to be inadequate when enough reality finally seeps in and then they run off to the next one hoping that once again, documentation that reads like a book on astrology or homeopathy will be the silver bullet to their problem.

Fred Brooks lobbed this same criticism in 1987 and it's still true today because although technology has changed, humans haven't. https://en.wikipedia.org/wiki/No_Silver_Bullet

Re: Second-guessing the modern web (2020)

#272
post #64

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

oh sorry, one other thing, jkaplan, are you THE Jerry Kaplan of Go? The writer of the fantastic 1994 book "Startup" that I have on my shelf?

Nope (if only!)

Re: Second-guessing the modern web (2020)

#273

I have to admit, I’ve been avoiding TypeScript and React for any professional projects. TypeScript due to lack of experience, but I understand the benefits. React due to many reasons, but most of which is that I don’t agree with the “benefits”. I have been working with the Frontend for over a decade and have been on the forefront of its progression. KnockoutJS was a pivotal moment and cemented what followed with Back…

I’ve been using typescript for years and I’m still constantly learning new things. Certainly has benefits, but also a large conceptual (and often syntax) hump.

On the frontend, maybe look at Svelte? I’m not going to try and sway you from your current chosen stack, but my personal experience with it (compared to the others) is that it’s like coming home. More like the natural evolution of early web tech, imo.

Re: Second-guessing the modern web (2020)

#274
post #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!

But lots of the developer experience is actually awful. Some is good, but there's so much needless complexity that is just painful. Stockholm syndrome applies if you don't realise there's easier ways, of course.

Re: Second-guessing the modern web (2020)

#275

Earlier quoted context omitted.

oh sorry, one other thing, jkaplan, are you THE Jerry Kaplan of Go? The writer of the fantastic 1994 book "Startup" that I have on my shelf?

Nope (if only!)

The book is pretty great. I'll put it with "The soul of a new machine", Ferguson's "Computer Wars" and Lapsley's "Exploding the phone" as top narrative tech books.

Re: Second-guessing the modern web (2020)

#276
post #64

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

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…

There are for sure lots of bad ways to use React, and lots of bad React developers. I actually had a very poor experience with React my first project using it.

But that's true for any framework (or lack thereof.) It's definitely possible to find good React patterns too. My 2nd project with React was a great experience, and was infinitely more maintainable and reusable than the framework-free frontends I had worked on.

Sounds like you've worked in really bad React projects (and/or really good non-React projects). All I can say is that my experience has been different! Redux + Redux Toolkit (https://redux-toolkit.js.org/) helped me and my team establish React patterns that were organized, concise enough, and performant -- although we did still have to tinker and try some things out until we found the patterns that worked for us. Hope it helps!

Re: Second-guessing the modern web (2020)

#277
post #36

Earlier quoted context omitted.

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.

Probably true, but for me it's sucking the fun out of developing. I like optimisation, removing stuff, making to code shorter, clearer, faster. Small neat pieces that are fun to write, like little machines working together. That to me is the beauty of coding, just as in music, design etc.

The meticulousness, the creativity and the dogmas you set up for yourself is what makes it exciting and fun - it doesn't have to be perfect but at least you "know the code", and can look at the little machine that you built.

In framework/service hell, you have zero idea what's going on. It's like directing an orchestra on the other side of a valley, or clicking a button to create a painting instead of painting.

Re: Second-guessing the modern web (2020)

#278

Earlier quoted context omitted.

From the Wikipedia page: "It is the first graphical query language, using visual tables where the user would enter commands, example elements and conditions. Many graphical front-ends for databases use the ideas from QBE today." GraphQL seems to borrow the name. Graph [ical] Q [uery] L [anguage] It could be a pure coincidence, but then, further down: "GraphQL a QBE for JSON front-ends." As evidenced by the reply, the…

Absolutely I can understand QBE being prior art for a number of querying paradigms. However, the two aren’t closely related. As far as the name goes, the “graph” in GraphQL likely refers to the data graph (as opposed to “graphical”) as data graph traversal is one of the key selling points of the language. The other one being homoiconicity between request and response.

"prior art"

Are you suggesting GraphQL is novel and non-obvious? The term "prior art" of course comes from the patent law.

Are you suggesting that the term "prior art" does not imply any relation (as in "relate to")? If so, that's false.

Re: Second-guessing the modern web (2020)

#279
post #259

Earlier quoted context omitted.

Oh la .. >> You can't build a modern web app without it being a SPA. Lots of people can >> I don't understand how there is even a discussion around this. This is the difference that makes the difference

> lots of people can Let’s see some links.

It's funny. A few years ago I proposed myself to make a list of nicely working SPAs. So far, this is my list:

1. twitter.com

That's it.

Re: Second-guessing the modern web (2020)

#280

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…

> Redux is a good example of this. It requires a load of boilerplate and seemingly contrived ways of reacting to interactions. What most people don't understand is that this is the primary feature of it. It is a rigid flow of data that enforces you to go through the same steps each time. As such, you can get into a Redux powered app and understand it relatively quickly. No this is totally completely wrong. Tools don'…

I don't really understand what you are suggesting. If everyone would stop using mainstream frameworks, the result would be endless bespoke ones. As long as programmers want to simplify, innovate and accelerate their work, they're going to leverage and implement abstractions if there is room for it.

I have worked on plenty of projects using their own, homegrown bespoke frameworks, and it ain't pretty. On top of that it is absolutely wasted knowledge that won't translate to any other code base. If you want to argue that it's all incompetence, I guess that's fine. To me it's about familiarity.

Post reply on HN