Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Respectfully, those metrics are not proxies for productivity. They don’t seem to be grounded in a statical model either:

>They reduced the code base size by 67% (21,500 LOC to 7200 LOC)

> They increased python code by 140% (500 LOC to 1200 LOC), a good thing if you prefer python to JS

Literally what? So they rewrote their app, which was most definitely in a state of affairs that warranted a refactor, and then concluded it must’ve been the limits of React. Oh, and rewrite the back-end too while we sing the virtues of this library claiming a lower technical investment.

Believe me, I’ve got plenty of gripes with React. It’s very easy to build the wrong things with it. And the ecosystem is an overgrown mess. But I’d still prefer a problem of technical curation over debugging a library which marries HTML and server-side templates with an untyped DOM runtime.



¯\_(ツ)_/¯

there's always going to be an excuse if you want there to be

this is a real world situation (warts and all) where someone rewrote their whole app that had taken them two+ years to build and that was stalled with htmx in two months from a cold start w/no falloff in UX, they simplified the codebase tremendously, they improved performance in both dev & prod and it flipped their entire team to full stack, eliminating a flow bottleneck in their development process

i try to be balanced about things, outlining when hypermedia is a good choice (it was in this case) and when it isn't, but c'mon... if a more conventional reactive library showed this sort of improvement you'd be interested in learning more.

So, maybe it's worth a more serious look, despite your priors? The ideas are interesting, at least:

https://hypermedia.systems


Comparing percentages can be misleading. 8,400 total LOC vs. 22,000 total LOC is an incredible win.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: