FWIW I've been writing UIs using plain JavaScript and the DOM API for like 15 years and at a certain scale, I always ended up building an ad-hoc framework or being disgruntled when I had to reach for any of the pre-React UI frameworks whose APIs and approaches I didn't like. React changes this, nowadays I either start with pure DOM and then rewrite to React or just start with React. I see a lot of hate online for React these days and I agree with probably 99 % of it, but the problem in my eyes is not React itself, but the ecosystem that spurred around it. If you stick to just React and take some care with your craft, React is a joy to use IME.
Not everything needs to be a SPA. I genuinely believe that the web would've been a much better place today on most important metrics (performance, simplicity, accessibility etc.) if this SPA shift would've never happened. The opportunity cost seems massive to me.
Most software I've used could have been a few hundred lines of PHP. But then they'd be done in like a day, which is great if you're a business owner (and the reason Pieter Levels uses PHP, for example), but not so great if you need to get paid to keep churning the code indefinitely (i.e. most people's situation)... and ideally hire all your friends to help too ;)
There are indeed less user-centric metrics with surprising weight when it comes down to it. I've also noticed that "We read a FAANG blog post and got enchanted" is easily remembered as "Everything was bad and we had to change it all" ;).
I don't find litigating this to be useful or interesting. Debating what is needed could show us lots of things we could cut. But would that bring real gain?
SPA's have really nice performance characteristics. Code is all loaded. The page can transition between states rather than total redraw. A good SPA should offer the same capabilities too, ought have URL routing and good history support.
I do think the web would be faster and simpler without SPAs. But it wouldn't be anywhere near as capable, as interesting, and as loved.
Personally, I like to look at the source for a page. And that, for anything React, winds up being useless (<go-suck-an-egg-because-EVERYTHYING-is-loaded-dynamically/>). I find React very hard to debug whenever anything doesn't work as expected.
I work on a React based web app in my Day Job and have genuinely enjoyed it.
That said, it always feels like so much boilerplate to get up and running for a greenfield project (and things like NextJS or even TanStack Start add a lot of things that might be overkill for a simple web app).
For some vibe coded side projects with Claude, I’ve been working with just using handlebars templates with Express and it has been pretty glorious!
I don’t think I’d recommend building a complex web app this way, but for some mild JS interactivity, form submission, etc, handlebars works.
Bonus: I find it much easier to get 100 across the board on Lighthouse scores this way.
For what it’s worth, I’ve used Vue and don’t like it (stuff like custom directives that are nonstandard html, not as explicit about event handling and data flow, etc).
I’ve seen a lot of buzz (particularly on HN) about Svelte but have lacked the motivation to try it.
I've tried both and disliked both. Already before I did I was wary of patronizing-feeling statements like these, though. The Vue community in particular, or at least the vocal pockets of it I've come across online, seem like a web dev counterpart to the Rust evangelism strike force.
I wanted to like Vue but when I tried it I didn't. For writing ordinary business applications I wish React reified lists more than it does, but what I like about React is that I know how to draw absolutely anything with it, including 3-d worlds, see
> it always feels like so much boilerplate to get up and running for a greenfield project
This is why I love Bun + React. The setup is so easy I can do it off memory. I always hated boilerplate, templates etc. so this is a huge selling point for me.
Hard feelings here. I like react and have to work with it, still it is all insanely wrong.
The best approach I've found so far is egui , and I hope people are moving that direction. Draw whole frame, collect events, process, update internal state.
My initial objections were: (a) circa 2006 I was making very demanding RIAs such as knowledge graph editors and GIS decision support software and I've yet to see any modern framework that is as good as what I was using then (not in JS but rather GWT and Silverlight w/ the same async comms) and (b) the React model is not a 100% match for the form-based applications that we usually write with it (but boy do I love react-hook-form)
React is like the code in Graham's On Lisp [1] in that functional programming is used to create a sort of DSL. There are a lot of ways to implement reactivity that usually require a special interpreter (spreadsheets) or compiler (Svelte). React's system does show seams (you really need to be on top of identity and equality) but it is remarkably simple.
React shines, in my mind, for things that aren't form applications. For instance, VR applications with AFrame -- it's somewhere between VRML and Unity. I am working on a (mainly) heart rate variability biofeedback application [2] and it is so easy to make dashboards that display real-time metrics as well as Poincare sections and time series. That is, I can slap together a few data processing functions and widgets and make a new dashboard with new metrics and charts or new sensors. One goal is to get it working on a tablet in a two player version.
The disadvantage of React is that it does not work so well for highly dynamic layouts. In my case I have a library of functions to "fetch" the data stream and put them into the top of the component (may even package as hooks) and then put the layout together with JSX. I'd like to have a version where the user can drag and drop the components to make a custom layout and the system figures out the dependencies for the data fetching, preparation and processing like the things I made in 2006 and that kind of application with a dynamic layout (think programs like Photoshop with lots of different little widgets and property sheets) wants a different approach to reactivity.
[1] use of macros in that book is a red herring, the one example in it where you really need macros is when he is implementing cooperative multitasking, a feature that Python and Javascript already have -- most examples from that book as with Norvig's Lisp book can be coded up just fine with
[2] see https://github.com/paulhoule/VulpusVision it might "just work" if you npm install, npm run dev, and look at it in Chrome and connect with a Polar H10 or other BT monitor
Claude Code is obsessed with using single letter names for inline function parameters and as loop control variables. I don't like it and I think it is sloppy, so I told it to stop in CLAUDE.md. In my experience, Claude Code will respect CLAUDE.md around 70 % of the time, it seems to cherry pick areas that it will respect more and less often and of course it kept ignoring this instruction. So I told it to add a pre-commit hook and invoke the TypeScript compiler and analyze the AST for single-letter variable names and tank the pre-commit check when it detects one with an error message indicating the offending symbols' locations. Now it can be non-deterministic as much as it wants, but it will never commit this particular flair of slop again as the adherence is verified deterministically. I already have a few more rules in mind I want to codify this way to prevent it from reproducing patterns it was trained on that I don't like and consider low quality.
Nice. The big picture strategy is figuring out the right mix of deterministic and probabilistic programming elements and how to mix them. I see agents ignore clear instructions all the time thus we need to codify the important instructions into deterministic rules, which probably take the form of tests or linters.
I am an ESL speaker but I don't see why the sentence fragment in parentheses couldn't be parsed as relating only to "Python stack" as opposed to "systems not using the Python stack". I read it that way, but again, as an ESL speaker, I might be missing intuition or actual grammatical knowledge that would tick off a native speaker such as, presumably, yourself.
It is based upon context, you are correct that it is ambiguious, as is the problem of most natural language.
-I believe that <inference systems not using the Python stack> (which I do not appreciate) are a way to free open models usage and make AI more accessible.
This reading of the text would lead one to believe they don't appreciate inferences systems not written in python. Given the inference system produced by the author is also not using the python stack (it is in C), we can assume this is not the correct reading.
-I believe that inference systems not using the <Python stack> (which I do not appreciate) are a way to free open models usage and make AI more accessible.
This reading says that the author does not like the python stack for inference, which given the author has produced this inference in C, would support the statement.
That is we have to take both readings and think which one fits the context around it, hopefully this helps :)
LFP batteries are as likely to burn down your house as a stack of wood is. I'd be worried about the inverter or botched DIY wiring (especially not to spec torque on terminal connections and botched crimps leading to hot spots), but not about the batteries themselves. For a person who wants to save some money, but doesn't know how to work with electricity, the best move is probably to get cheap LFP cells from China, but have a professional install a BMS and the remainder of the solar system.
> especially not to spec torque on terminal connections and botched crimps leading to hot spots
This was indeed my greatest concern. However the battery came with pre-crimped very solid DC wires, and nice push connectors for the battery itself. The battery also has an integrated DC breaker (great!).
The system runs 3KW max, so I just added an additional breaker (with RCD integrated) in the conduit box. In NL this is something a DIY-home owner easily can do themselves :) (just use the right solid/flex stranded cabling for the connectors, etc...)
And further, my position has been that learning the correct methods, paying a lot of attention to details, and not being cheap with tools is -still- cheaper and probably more reliable than paying contractors. I have only used my hydraulic crimper for a pair of cables, but it was the correct tool and did good work.
I'm not interfacing with a grid, and there are already code issues with my places- I'd probably feel different if I could get insurance on my place.
Cheap chinese tooling and youtube (plus pretty good general literacy) go a long way in this world.
And FWIW, I live in the US west and am way more worried about fire coming from outside than from the batteries.
> LFP batteries are as likely to burn down your house as a stack of wood is.
LFP batteries are much safer than past chemistries, but this statement is way too broad.
High power batteries are always more dangerous than something like a stack of wood, because batteries will gladly dump their entire energy capacity very rapidly into a short.
Even if the battery itself [mostly] won't self-immolate, the entire installation can be a fire hazard.
On a tangent, I’m amazed at how bad most random crimps I see on the internet are. Also, the number of people who debate the use of solder on crimps without discussing potential issues with said solder is too high.
I think it is an artifact of the optimizations he uses and while it's artistically limiting, I think a right game with the right visual language could make this work to its advantage in terms of uniqueness/distinctiveness. It's a one trick pony if not avoidable though.
I have a love-hate relationship with Home Assistant. I love its mission and I love it in spirit, but whenever I need to add or change something in it, I don't love the process. Without disparaging the work already done on improving it in recent years, I still find the UI and UX to be lacking. Claude Code has been shifting my perception much closer to the love end of the axis, because it allows me to side-step the boring parts of managing my Home Assistant instance and it is able to carry out the changes I want very reliably.
I still struggle with letting go of writing code and becoming only a full-time reviewer when it comes to AI agents doing programming, but I don't struggle in the slightest with assuming the position of a reviewer of the changes CC does to my HA instance, delegating all the work to it. The progress I made on making my house smart and setting up my dashboards has skyrocketed compared to before I started using CC to manage HA via its REST and WS APIs.
An account doesn't have to be problematic for you to not want to see their comments. I have several handles in mind where I'd add them to such a list if it were a feature. Nothing against the people in particular, but sometimes when I see a handle (like others said, very often old accounts with high karma), I already know what they will go on about merely just based off the title of the submission and having unintentionally gleaned what topics they usually comment on just by being on HN for a while. It's a waste of time to read those comments, at least for me. Wouldn't hurt them if they lost my attention. I am not bothered by it enough to vibe code a browser extension for it, though. That threshold is a bit higher, I did it for blocking certain domains; there is only so many times I can sit through an article or an "essay" which should have been a podcast.
It takes less than a minute to resubscribe to any of these devices. No need to burn 60 USD if I switch for a three month spell and then switch back. When a provider goes down, I do what I set out to do without their service. If the outage lasts too long, I'll cancel as not to support sloppy service.
I created a workspace local extension in VS Code that uses the VS Code API to let Claude Code open files in VS Code as tabs and save them (to apply save participants like Prettier in case it is not used via the CLI) and to get diagnostics (like for TypeScript where there is no option to get workspace-wide diagnostics and you have to go file by file). I taught Claude Code to use this extension via a skill file and it works perfectly, much more reliably than its own IDE LSP integration.
reply