The advantage of frameworks is to have a "common language" to achieve some goals together with a team. A good framework hides some of the stupid mistakes you would do when you would try to develop that "language" from scratch.
When you do a project from scratch, if you work enough on it, you end up wishing you would have started differently and you refactor pieces of it. While using a framework I sometimes have moments where I suddenly get the underlying reasons and advantages of doing things in a certain way, but that comes once you become more of a power user, than at start, and only if you put the effort to question. And other times the framework is just bad and you have to switch...
I used Claude to document, in great detail, a 500k-line codebase in about an hour of well-directed prompts. Just fully explained it, how it all worked, how to get started working on it locally, the nuance of the old code, pathways, deployments using salt-stack to AWS, etc.
I don't think the moat of "future developers won't understand the codebase" exists anymore.
This works well for devs who write their codebase using React, etc., and also the ones rolling their own JavaScript (of which I personally prefer).
It's funny how Lisp has been criticized for its ability to create a lot of macros and DSLs, then Java & JavaScript came along and there was an explosion of frameworks and transpiled languages in JVM, Node or the Browser.
So, use the framework for the prototype and maybe thru v1.x, then after you have better understanding of how it is actually used in the field and what architecture and patterns would work best in your team's situation, fully write the real app yourself (or, if the framework really works best, keep using it).
I've found taking the throwaway approach a bit further down the line pays big benefits; delaying full commitment to a particular path until you have a lot more information tends to work better.
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: unrefactorable, large components, you probably want to break these down into smaller pieces. This talk ("Composition is all you need") is an excellent guide on the topic: https://youtu.be/4KvbVq3Eg5w?si=1esmAtrJthois1uf
Re: performance, people overstate the performance overhead of VDOM. Badly performing React applications are virtually always due to bad implementations. React Scan is an excellent tool for tracking down components that need optimizing: https://react-scan.com/
Re: getting other people on the team to write good code, this is the biggest struggle IMO. Frontend is hard because there's a lot of bad ways to solve a problem, and co-workers will insist that their changes work so why invest more time into building things correctly. I've only found success here by first writing an entire feature with good patterns and pointing to it as reference for other teams. People are more willing to make changes if they find precedent in the codebase.
I dunno, AI tools love adding not only useEffect but also unnecessary useMemo.
> I don't know why people think the virtual DOM is a performance boost.
It was advertised as one of the advantages when React was new, due to the diffing browsers would only need to render the parts that changed instead of shoving a whole subtree into the page and the having to do all of it (because remember this came out in the era of jquery and mustachejs generating strings of HTML from templates instead of targeted updates).
I get the sentiment, but "I don’t like magic" feels like a luxury belief.
Electricity is magic. TCP is magic. Browsers are hall-of-mirrors magic. You’ll never understand 1% of what Chromium does, and yet we all ship code on top of it every day without reading the source.
Drawing the line at React or LLMs feels arbitrary. The world keeps moving up the abstraction ladder because that’s how progress works; we stand on layers we don’t fully understand so we can build the next ones. And yes LLM outputs are probabilistic, but that's how random CSS rendering bugs felt to me before React took care of them
The cost isn’t magic; the cost is using magic you don’t document or operationalize.
When everything is magic I think we need a new definition of magic or maybe a new term to encapsulate what's being described here.
The key feature of magic is that it breaks the normal rules of the universe as you're meant to understand it. Encapsulation or abstraction therefore isn't, on its own, magical. Magic variables are magic because they break the rules of how variables normally work. Functional components/hooks are magic because they're a freaky DSL written in JS syntax where your code makes absolutely no sense taken as regular JS. Type hint and doctype based programming in Python is super magical because type hints aren't supposed to affect behavior.
The AI pilled view is coding is knitting and AI is an automated loom.
But it is not quite the case. The hand coded solution may be quicker than AI at reaching the business goal.
If there is an elegant crafted solution that stays in prod 10 years and just works it is better than an initially quicker AI coded solution that needs more maintenance and demands a team to maintain it.
If AI (and especially bad operators of AI) codes you a city tower when you need a shed, the tower works and looks great but now you have 500k/y in maintaining it.
Thanks for this! I've mostly avoided getting too into React and its ilk, mainly because I hate how bloated the actual code generated by that kind of application tends to be. But also I am enjoying going through this. If I can complete it, I think I will be more informed about how React really works.
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 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.
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.
Did someone ask about Intel processor history? :-) The Intel 8080 (1974) didn't use microcode, but there were many later processors that didn't use microcode either. For instance, the 8085 (1976). Intel's microcontrollers, such as the 8051 (1980), didn't use microcode either. The RISC i860 (1989) didn't use microcode (I assume). The completely unrelated i960 (1988) didn't use microcode in the base version, but the floating-point version used microcode for the math, and the bonkers MX version used microcode to implement objects, capabilities, and garbage collection. The RISC StrongARM (1997) presumably didn't use microcode.
As far as x86, the 8086 (1978) through the Pentium (1993) used microcode. The Pentium Pro (1995) introduced an out-of-order, speculative architecture with micro-ops instead of microcode. Micro-ops are kind of like microcode, but different. With microcode, the CPU executes an instruction by sequentially running a microcode routine, made up of strange micro-instructions. With micro-ops, an instruction is broken up into "RISC-like" micro-ops, which are tossed into the out-of-order engine, which runs the micro-ops in whatever order it wants, sorting things out at the end so you get the right answer. Thus, micro-ops provide a whole new layer of abstraction, since you don't know what the processor is doing.
My personal view is that if you're running C code on a non-superscalar processor, the abstractions are fairly transparent; the CPU is doing what you tell it to. But once you get to C++ or a processor with speculative execution, one loses sight of what's really going on under the abstractions.
And actually further to your point, I would assume that many more people who code in Javascript have read the React codebase and not the v8 codebase.
I've read the react source, and some of v8. Imagine how you'd implement hooks, you're probably not too far away. It's messier than you'd hope, but that's kind of the point of an abstraction anyway. It's really not magic, I really dislike that term when all you're doing is building on something that is pretty easy to read and understand. v8 on the other hand is much harder, although I will say I found the code better organised and explained than React.
Are you seriously saying that you can't understand the concept of different abstractions having different levels of usefulness? That's the law of averages taken to cosmic proportions.
If this is true, why have more than one abstraction?
A good abstraction relieves you of concern for the particulars it abstracts away. A bad abstraction hides the particulars until the worst possible moment, at which point everything spills out in a messy heap and you have to confront all the details. Bad abstractions existed long before React and long before LLMs.
his line (admittedly he acknowledges) is just purely arbitrary and thus basically boils down to his own comfort and opinion. i guess we are all entitled to that, so maybe nothing to really take away from all this. has he read the whole react codebase line by line to understand what works and doesn't? just handwaves it away as some unneeded "abstraction".
I also don't like magic, but React is the wrong definition of magic in this case. It's an abstraction layer for UI and one that is pretty simple when you think about it conceptually. The complexity is by third party library that are building on top of it, but proposing complex machineries instead of simple ones. Then you have a culture of complexity around simple technology.
But it does seems that culture of complexity is more pervasive lately. Things that could have been a simple gist or a config change is a whole program that pulls tens of dependencies from who knows who.
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.
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 assembly, elf, etc.) to open up, both in "engineeering" land and "theory" land, if you so choose.
Part of good engineering as well is deciding exactly when the boundary of "don't cares" and "cares" are, and how you allow people to easily navigate the abstraction hierarchy.
That is my impression of what people mean when they don't like "magic".
I'm not sure this is a useful way to approach "magic". I don't think I can build a production compiler or linker. It's fair to say that I don't fully understand them either. Yet, I don't need a "full" understanding to do useful things with them and contribute back upstream.
LLMs are vastly more complicated and unlike compilers we didn't get a long, slow ramp-up in complexity, but it seems possible we'll eventually develop better intuition and rules of thumb to separate appropriate usage from inappropriate.
This kind of "magical UX design" is the most common source of me cursing equipment I interact with. A good example
When I design hardware interfaces one of my main rules is that user agency should be maximized where needed. That requires the manufacturer to trust (or better: ensure) that the user has a meaningful mental model of the device they are using. Your interface then has to honor this mental model at all times.
So build a hammer and show the user how to use it effectively, don't build a SmartNailPuncher3000 that may or may not work depending if the user is holding it right and has selected the wrong mode by touching the wrong part.
> I’ve always avoided client-side React because of its direct harm to end users (over-engineered bloated sites that take way longer to load than they need to).
A couple of megabytes of JavaScript is not the "big bloated" application in 2026 that is was in 1990.
Most of us have phones in our pockets capable of 500Mbps.
The payload of an single page app is trivial compared to the bandwidth available to our devices.
I'd much rather optimise for engineer ergonomics than shave a couple of milliseconds off the initial page load.
React + ReactDOM adds ~50kb to a production bundle, not even close to a couple of mbs. React with any popular routing library also makes it trivial to lazy load js per route, so even with a huge application your initial js payload stays small. I ship React apps with a total prod bundle size of ~5mb, but on initial load only require ~100kb.
The idea that React is inherently slow is totally ignorant. I'm sympathetic to the argument that many apps built with React are slow (though I've not seen data to back this up), or that you as a developer don't enjoy writing React, but it's a perfectly fine choice for writing performant web UI if you're even remotely competent at frontend development.
> And so now we have these “magic words” in our codebases. Spells, essentially. Spells that work sometimes. Spells that we cast with no practical way to measure their effectiveness. They are prayers as much as they are instructions.
Autovectorization is not a programming model. This still rings true day after day.
I've used React on projects and understand its usefulness, but also React has killed my love of frontend development. And now that everyone is using it to build huge, clunky SPAs instead of normal websites that just work, React has all but killed my love of using the web, too.
the advantage of frameworks is that there are about 20-ish security/critical usage considerations, of which you will remember about 5. if you don't use a framework, you are so much more likelihood of getting screwed. you should use a framework when theres just shit you dont think of that could bite you in the ass[0]. for everything else, use libraries.
[0] this includes for example int main(), which is a hook for a framework. c does a bunch of stuff in __start (e.g. in linux, i don't know what the entrypoint is in other languages) that you honestly don't want to do every. single. time./ for every single OS
If you are the only person who ever touches your code, fine, otherwise I despise this attitude and would insta-reject any candidate who said this. In a team setting, "I don't like magic" and "I don't want to learn a framework" means: "I want you to learn my bespoke framework I'm inevitably going to write."
Predicated upon the definition of "magic" provided in the article: What is it, if anything, about magic that draws people to it? Is there a process wherein people build tolerance and acceptance to opaque abstractions through learning? Or, is it acceptance that "this is the way things are done", upheld by cargo cult development, tutorials, examples, and the like, for the sake of commercial expediency? I can certainly understand that seldom is time afforded to building a deep understanding of the intent, purpose, and effect of magic abstractions under such conditions.
Granted, there are limits to how deep one should need to go in understanding their ecosystem of abstractions to produce meaningful work on a viable timescale. What effect does it have on the trade to, on the other hand, have no limit to the upward growth of the stack of tomes of magical frameworks and abstractions?
> What is it, if anything, about magic that draws people to it?
Simple: if it's magic, you don't have to do the hard work of understanding how it works in order to use it. Just use the right incantation and you're done. Sounds great as long as you don't think about the fact that not understanding how it works is actually a bug, not a feature.
I think it's "this is the way things are done in order to achieve X". Where people don't question neither whether this is the only way to achieve X, nor whether they do really care about X in the first place.
It seems common with regard to dependency injection frameworks. Do you need them for your code to be testable? No, even if it helps. Do you need them for your code to be modular? You don't, and do you really need modularity in your project? Reusability? Loose coupling?
This person's distinction between "library" and "framework" is frankly insane.
React, which just is functions to make DOM trees and render them is a framework? There is a reason there are hundreds of actual frameworks that exist to make structure about using these functions.
At this point, he should stop using any high level language! Java/python are just a big frameworks calling his bytecode, what magical frameworks!
This is such a strange take. The definition of "magic" in this post is apparently "other people's code" and it even admits that that no practical program can avoid depending on other people's code. I think what the author is really saying that they like to minimize dependencies and abstractions, particularly in web client development, and then throws in a connection to coding assistants.
I don't see it, either the notion that other people's code is to be avoided for its own sake nor that depending on LLM-generated code is somehow analogous to depending on React.
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.
>> 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.
100% agree with this. Name it well, maintain it in one place ... profit.
It's the not abstracting up front that can catch you: The countless times I have been asked to add feature x, but that it is a one-off/PoC. Which sometimes even means it might not get the full TDD/IoC/feature flag treatment (which aren't always available depending upon the client's stack).
Then, months later get asked to created an entire application or feature set on top of that. Abstracting that one-off up into a method/function/class tags and bags it: it is now named and better documented. Can be visible in IDE, called from anywhere and looped over if need be.
There is obviously a limit to where the abstraction juice isn't worth the squeeze, but otherwise, it just adds superpowers as time goes on.
> I get that. But I still draw a line. When it comes to front-end development, that line is for me to stay as close as I can to raw HTML, CSS, and JavaScript. After all, that’s what users are going to get in their browsers.
No it’s not. They will get shown a collection of pixels, a bunch of which will occupy coordinates (in terms of an abstraction that holds the following promise) such that if the mouse cursor (which is yet another abstraction) matches those coordinates, a routine derived from a script language (give me an A!) will be executed mutating the DOM (give me a B!) which is built on top of more abstractions than it would take to give me the remaining S.T.R.A.C.T.I.O.N. three times over. Three might be incorrect, just trying to abstract away so that I don’t end up dumping every book on computers in this comment.
Ignorance at a not so fine level. Reads like “I’ve established myself confidently in the R.A.C. band, therefore anything that comes after is yucky yucky”.
vladms|8 days ago
When you do a project from scratch, if you work enough on it, you end up wishing you would have started differently and you refactor pieces of it. While using a framework I sometimes have moments where I suddenly get the underlying reasons and advantages of doing things in a certain way, but that comes once you become more of a power user, than at start, and only if you put the effort to question. And other times the framework is just bad and you have to switch...
jv22222|8 days ago
I don't think the moat of "future developers won't understand the codebase" exists anymore.
This works well for devs who write their codebase using React, etc., and also the ones rolling their own JavaScript (of which I personally prefer).
sodapopcan|8 days ago
But ya, I hate when people say they don't like "magic." It's not magic, it's programming.
goatlover|8 days ago
toss1|7 days ago
I've found taking the throwaway approach a bit further down the line pays big benefits; delaying full commitment to a particular path until you have a lot more information tends to work better.
overgard|8 days ago
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..
nosefurhairdo|7 days ago
Re: unrefactorable, large components, you probably want to break these down into smaller pieces. This talk ("Composition is all you need") is an excellent guide on the topic: https://youtu.be/4KvbVq3Eg5w?si=1esmAtrJthois1uf
Re: performance, people overstate the performance overhead of VDOM. Badly performing React applications are virtually always due to bad implementations. React Scan is an excellent tool for tracking down components that need optimizing: https://react-scan.com/
Re: getting other people on the team to write good code, this is the biggest struggle IMO. Frontend is hard because there's a lot of bad ways to solve a problem, and co-workers will insist that their changes work so why invest more time into building things correctly. I've only found success here by first writing an entire feature with good patterns and pointing to it as reference for other teams. People are more willing to make changes if they find precedent in the codebase.
Izkata|8 days ago
I dunno, AI tools love adding not only useEffect but also unnecessary useMemo.
> I don't know why people think the virtual DOM is a performance boost.
It was advertised as one of the advantages when React was new, due to the diffing browsers would only need to render the parts that changed instead of shoving a whole subtree into the page and the having to do all of it (because remember this came out in the era of jquery and mustachejs generating strings of HTML from templates instead of targeted updates).
thestackfox|8 days ago
Electricity is magic. TCP is magic. Browsers are hall-of-mirrors magic. You’ll never understand 1% of what Chromium does, and yet we all ship code on top of it every day without reading the source.
Drawing the line at React or LLMs feels arbitrary. The world keeps moving up the abstraction ladder because that’s how progress works; we stand on layers we don’t fully understand so we can build the next ones. And yes LLM outputs are probabilistic, but that's how random CSS rendering bugs felt to me before React took care of them
The cost isn’t magic; the cost is using magic you don’t document or operationalize.
dnautics|8 days ago
Spivak|7 days ago
The key feature of magic is that it breaks the normal rules of the universe as you're meant to understand it. Encapsulation or abstraction therefore isn't, on its own, magical. Magic variables are magic because they break the rules of how variables normally work. Functional components/hooks are magic because they're a freaky DSL written in JS syntax where your code makes absolutely no sense taken as regular JS. Type hint and doctype based programming in Python is super magical because type hints aren't supposed to affect behavior.
unknown|8 days ago
[deleted]
est|7 days ago
Hmm, they aren't if you have a degree.
> Browsers are hall-of-mirrors magic
More like Chromium with billions LoC of C++ is magic. I think browser shouldn't be that complex.
tokenless|8 days ago
But it is not quite the case. The hand coded solution may be quicker than AI at reaching the business goal.
If there is an elegant crafted solution that stays in prod 10 years and just works it is better than an initially quicker AI coded solution that needs more maintenance and demands a team to maintain it.
If AI (and especially bad operators of AI) codes you a city tower when you need a shed, the tower works and looks great but now you have 500k/y in maintaining it.
james_marks|8 days ago
Anything that can be automated can be automated poorly, but we accept that trained operators can use looms effectively.
socalgal2|8 days ago
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.
xp84|8 days ago
yellowapple|8 days ago
Klonoar|8 days ago
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)
insin|8 days ago
noelwelsh|8 days ago
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.
kens|8 days ago
As far as x86, the 8086 (1978) through the Pentium (1993) used microcode. The Pentium Pro (1995) introduced an out-of-order, speculative architecture with micro-ops instead of microcode. Micro-ops are kind of like microcode, but different. With microcode, the CPU executes an instruction by sequentially running a microcode routine, made up of strange micro-instructions. With micro-ops, an instruction is broken up into "RISC-like" micro-ops, which are tossed into the out-of-order engine, which runs the micro-ops in whatever order it wants, sorting things out at the end so you get the right answer. Thus, micro-ops provide a whole new layer of abstraction, since you don't know what the processor is doing.
My personal view is that if you're running C code on a non-superscalar processor, the abstractions are fairly transparent; the CPU is doing what you tell it to. But once you get to C++ or a processor with speculative execution, one loses sight of what's really going on under the abstractions.
jemmyw|7 days ago
I've read the react source, and some of v8. Imagine how you'd implement hooks, you're probably not too far away. It's messier than you'd hope, but that's kind of the point of an abstraction anyway. It's really not magic, I really dislike that term when all you're doing is building on something that is pretty easy to read and understand. v8 on the other hand is much harder, although I will say I found the code better organised and explained than React.
pessimizer|8 days ago
If this is true, why have more than one abstraction?
kalterdev|8 days ago
Yeah, JavaScript is an illusion (to be exact, a concept). But it’s the one that we accept as fundamental. People need fundamentals to rely upon.
unknown|8 days ago
[deleted]
sevensor|8 days ago
ookblah|7 days ago
unknown|8 days ago
[deleted]
skydhash|8 days ago
But it does seems that culture of complexity is more pervasive lately. Things that could have been a simple gist or a config change is a whole program that pulls tens of dependencies from who knows who.
SirMaster|8 days ago
mgaunard|8 days ago
sigbottle|8 days ago
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 assembly, elf, etc.) to open up, both in "engineeering" land and "theory" land, if you so choose.
Part of good engineering as well is deciding exactly when the boundary of "don't cares" and "cares" are, and how you allow people to easily navigate the abstraction hierarchy.
That is my impression of what people mean when they don't like "magic".
eleventyseven|8 days ago
wa008|8 days ago
AlotOfReading|8 days ago
LLMs are vastly more complicated and unlike compilers we didn't get a long, slow ramp-up in complexity, but it seems possible we'll eventually develop better intuition and rules of thumb to separate appropriate usage from inappropriate.
zem|8 days ago
atoav|7 days ago
When I design hardware interfaces one of my main rules is that user agency should be maximized where needed. That requires the manufacturer to trust (or better: ensure) that the user has a meaningful mental model of the device they are using. Your interface then has to honor this mental model at all times.
So build a hammer and show the user how to use it effectively, don't build a SmartNailPuncher3000 that may or may not work depending if the user is holding it right and has selected the wrong mode by touching the wrong part.
unknown|8 days ago
[deleted]
cbeach|8 days ago
A couple of megabytes of JavaScript is not the "big bloated" application in 2026 that is was in 1990.
Most of us have phones in our pockets capable of 500Mbps.
The payload of an single page app is trivial compared to the bandwidth available to our devices.
I'd much rather optimise for engineer ergonomics than shave a couple of milliseconds off the initial page load.
nosefurhairdo|8 days ago
The idea that React is inherently slow is totally ignorant. I'm sympathetic to the argument that many apps built with React are slow (though I've not seen data to back this up), or that you as a developer don't enjoy writing React, but it's a perfectly fine choice for writing performant web UI if you're even remotely competent at frontend development.
blturner|8 days ago
sigbottle|8 days ago
Autovectorization is not a programming model. This still rings true day after day.
vandahm|8 days ago
dnautics|8 days ago
[0] this includes for example int main(), which is a hook for a framework. c does a bunch of stuff in __start (e.g. in linux, i don't know what the entrypoint is in other languages) that you honestly don't want to do every. single. time./ for every single OS
unknown|8 days ago
[deleted]
sodapopcan|8 days ago
llbbdd|8 days ago
xantronix|8 days ago
Granted, there are limits to how deep one should need to go in understanding their ecosystem of abstractions to produce meaningful work on a viable timescale. What effect does it have on the trade to, on the other hand, have no limit to the upward growth of the stack of tomes of magical frameworks and abstractions?
pdonis|8 days ago
Simple: if it's magic, you don't have to do the hard work of understanding how it works in order to use it. Just use the right incantation and you're done. Sounds great as long as you don't think about the fact that not understanding how it works is actually a bug, not a feature.
3form|8 days ago
It seems common with regard to dependency injection frameworks. Do you need them for your code to be testable? No, even if it helps. Do you need them for your code to be modular? You don't, and do you really need modularity in your project? Reusability? Loose coupling?
hyperhopper|8 days ago
React, which just is functions to make DOM trees and render them is a framework? There is a reason there are hundreds of actual frameworks that exist to make structure about using these functions.
At this point, he should stop using any high level language! Java/python are just a big frameworks calling his bytecode, what magical frameworks!
dnautics|8 days ago
calling a framework necessarily magic is the weird thing.
nickm12|7 days ago
I don't see it, either the notion that other people's code is to be avoided for its own sake nor that depending on LLM-generated code is somehow analogous to depending on React.
lo_zamoyski|8 days ago
> 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.
ompogUe|8 days ago
> 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.
100% agree with this. Name it well, maintain it in one place ... profit.
It's the not abstracting up front that can catch you: The countless times I have been asked to add feature x, but that it is a one-off/PoC. Which sometimes even means it might not get the full TDD/IoC/feature flag treatment (which aren't always available depending upon the client's stack).
Then, months later get asked to created an entire application or feature set on top of that. Abstracting that one-off up into a method/function/class tags and bags it: it is now named and better documented. Can be visible in IDE, called from anywhere and looped over if need be.
There is obviously a limit to where the abstraction juice isn't worth the squeeze, but otherwise, it just adds superpowers as time goes on.
antonvs|8 days ago
huflungdung|8 days ago
[deleted]
kosmotaur|8 days ago
No it’s not. They will get shown a collection of pixels, a bunch of which will occupy coordinates (in terms of an abstraction that holds the following promise) such that if the mouse cursor (which is yet another abstraction) matches those coordinates, a routine derived from a script language (give me an A!) will be executed mutating the DOM (give me a B!) which is built on top of more abstractions than it would take to give me the remaining S.T.R.A.C.T.I.O.N. three times over. Three might be incorrect, just trying to abstract away so that I don’t end up dumping every book on computers in this comment.
Ignorance at a not so fine level. Reads like “I’ve established myself confidently in the R.A.C. band, therefore anything that comes after is yucky yucky”.
dang|8 days ago
This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
unknown|8 days ago
[deleted]