Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Don't Like Magic

adactio.com

Post reply on HN
Print view View original

61–70 of 138 posts

Re: I Don't Like Magic

#61

Post by Mogzol »

yellowapple wrote: post #34
socalgal2 wrote: post #17

You could walk through the framework so you then understand it. There are several "let's create react from scratch" articles https://pomb.us/build-your-own-react/ Certain frameworks were so useful they arguably caused an explosion the productivity. Rails seems like one. React might be too.

Thanks to that page letting me see how many dozens of lines of code React needs to do the equivalent of const element = document.createElement("h1"); element.innerHTML = "Hello"; element.setAttribute("title", "foo"); const container = document.getElementById("root"); container.appendChild(element); I now have even less interest in ever touching a React codebase, and will henceforth consider the usage of React a code…

The "magic" of React though is in its name, it's reactive. If all you're doing is creating static elements that don't need to react to changes in state then yeah, React is overkill. But when you have complex state and need all your elements to update as that state changes, then the benefits of React (or similar frameworks) become more apparent. Of course it's all still possible in vanilla JS, but it starts to become a mess of event handlers and DOM updates and the React equivalent starts to look a lot more appealing.

Re: I Don't Like Magic

#62

Post by overgard »

React is a weird beast. I've been using it for years. I think I like it? I use it for new projects too, probably somewhat as a matter of familiarity. I'm not entirely convinced it's a great way to code, though.

My experience with it is that functional components always grow and end up with a lot of useEffect calls. Those useEffects make components extremely brittle and hard to reason about. Essentially it's very hard to know what parts of your code are going to run, and when.

I'm sure someone will argue, just refactor your components to be small, avoid useEffect as much as possible. I try! But I can't control for other engineers. And in my experience, nobody wants to refactor large components, because they're too hard to reason about! And the automated IDE tools aren't really built well to handle refactoring these things, so either you ask AI to do it or it's kind of clunky by-hand. (WebStorm is better than VSCode at this, but they're both not great)

The other big problem with it is it's just not very efficient. I don't know why people think the virtual DOM is a performance boost. It's a performance hack to get around this being a really inefficient model. Yes, I know computers are fast, but they'd be a lot faster if we were writing with better abstractions..

Re: I Don't Like Magic

#63

Post by yellowapple »

madeofpalk wrote: post #39
yellowapple wrote: post #34

Earlier quoted context omitted.

Thanks to that page letting me see how many dozens of lines of code React needs to do the equivalent of const element = document.createElement("h1"); element.innerHTML = "Hello"; element.setAttribute("title", "foo"); const container = document.getElementById("root"); container.appendChild(element); I now have even less interest in ever touching a React codebase, and will henceforth consider the usage of React a code…

All of that is the JavaScript equivalent of Hello I have even less interest in touching any of your codebases!

Well I'd hesitate to touch any of my codebases, too, so that's fair :)

Re: I Don't Like Magic

#64

Post by [deleted] »

noelwelsh wrote: post #7

If you have this attitude I hope you write everything in assembly. Except assembly is compiled into micro-ops, so hopefully you avoid that by using an 8080 (according to a quick search, the last Intel CPU to not have micro-ops.) In other words, why is one particular abstraction (e.g. Javscript, or the web browser) ok, but another abstraction (e.g. React) not? This attitude doesn't make sense to me.

[deleted]

Re: I Don't Like Magic

#66

Post by clnhlzmn »

mgaunard wrote: post #33
SirMaster wrote: post #31

So you don’t like compilers? Or do you really full understand how they are working? How they are transforming your logic and your asynchronous code into machine code etc.

I think most traditional software engineers do indeed understand what transformations compilers do.

I think you're mistaken on that. Maybe me and the engineers I know are below average on this but even our combined knowledge of the kinds of things _real_ compilers get up to probably only scratches the surface. Don't get me wrong, I know what compilers do _in principle_. Hell I've even built a toy compiler or two. But the compilers I use for work? I just trust that the know what they're doing.

Re: I Don't Like Magic

#67

Post by mananaysiempre »

sigbottle wrote: post #37
SirMaster wrote: post #31

So you don’t like compilers? Or do you really full understand how they are working? How they are transforming your logic and your asynchronous code into machine code etc.

[Autovectorization is not a programming model]( https://pharr.org/matt/blog/2018/04/18/ispc-origins ). Sure, obviously, we will not undersatnd every single little thing down to the tiniest atoms of our universe. There are philosophical assumptions underlying everything and you can question them (quite validly!) if you so please. However, there are plenty of intermediate mental models (or explicit contracts, like asse…

> Then, when it fails [...], you can either poke it in the right ways or change your program in the right ways so that it works for you again. This is a horrible way to program; it’s all alchemy and guesswork and you need to become deeply specialized about the nuances of a single [...] implementation

In that post, the blanks reference a compiler’s autovectorizer. But you know what they could also reference? An aggresively opaque and undocumented, very complex CPU or GPU microarchitecture. (Cf. https://purplesyringa.moe/blog/why-performance-optimization-....)

Re: I Don't Like Magic

#68

Post by [deleted] »

noelwelsh wrote: post #7

If you have this attitude I hope you write everything in assembly. Except assembly is compiled into micro-ops, so hopefully you avoid that by using an 8080 (according to a quick search, the last Intel CPU to not have micro-ops.) In other words, why is one particular abstraction (e.g. Javscript, or the web browser) ok, but another abstraction (e.g. React) not? This attitude doesn't make sense to me.

[deleted]

Re: I Don't Like Magic

#69

Post by lo_zamoyski »

This reads like a transcript of a therapy session. He never gives any real reasons. It's mostly a collection of assertions. This guy must never have worked on anything substantial. He also must underestimate the difficulty of writing software as well as his reliance on the work of others.

> I don’t like using code that I haven’t written and understood myself.

Why stop with code? Why not refine beach sand to grow your own silicon crystal to make your own processor wafers?

Division of labor is unavoidable. An individual human being cannot accomplish all that much.

> If you’re not writing in binary, you don’t get to complain about an extra layer of abstraction making you uncomfortable.

This already demonstrates a common misconception in the field. The physical computer is incidental to computer science and software engineering per se. It is an important incidental tool, but conceptually, it is incidental. Binary is not some "base reality" for computation, nor do physical computers even realize binary in any objective sense. Abstractions are not over something "lower level" and "more real". They are the language of the domain, and we may simulate them using other languages. In this case, physical computer architectures provide assembly languages as languages in which we may simulate our abstractions.

Heck, even physical hardware like "processors" are abstractions; objectively, you cannot really say that a particular physical unit is objectively a processor. The physical unit simulates a processor model, its operations correspond to an abstract model, but it is not identical with the model.

> My control freakery is not typical. It’s also not a very commercial or pragmatic attitude.

No kidding. It's irrational. It's one thing to wish to implement some range of technology yourself to get a better understanding of the governing principles, but it's another thing to suffer from a weird compulsion to want to implement everything yourself in practice...which he obviously isn't doing.

> Abstractions often really do speed up production, but you pay the price in maintenance later on.

What? I don't know what this means. Good abstractions allow us to better maintain code. Maintaining something that hasn't been structured into appropriate abstractions is a nightmare.

Re: I Don't Like Magic

#70

Post by Klonoar »

insin wrote: post #54
Klonoar wrote: post #48

I feel like a lot of the comments here are from people who either weren't around for, or didn't grow up in, the era where adactio and the wider web dev scene (Zeldman, etc) were the driving force of things on the web. If you've only been in a world with React & co, you will probably have a more difficult time understanding the point they're contrasting against. (I'm not even saying that they're right)

I was around for that era (I may have made an involuntary noise when Zeldman once posted something nice about a thing I made), but being averse to "abstraction in general" is a completely alien concept to me as a software developer.

Yes, but I'm in so many words stating that that particular era of web dev was notorious for the discussion of "is this software engineering or not".

It's just such a different concept/vibe/whatever compared to modern frontend development. Brad Frost is another notable person in this overall space who's written about the changes in the field over the years.

Post reply on HN