HN user

iuvcaw

63 karma
Posts2
Comments10
View on HN

The vast majority of time spent building software has little to do with optimization. Sky-high abstracted brain rot languages are useful precisely because usually you don’t need to worry about the type of details that you would if you were optimizing performance

And then if you are optimizing for performance, you can make an incredible amount of progress just fixing the crappy Java etc code before you need to drop down a layer of abstraction

Even hedge funds, which make money executing trades fractions of milliseconds quicker than others, use higher level languages and fix performance issues within those languages if needed

The React team really does not like SPAs, which I think is a bit of a shame. I'm not a big fan of the mish-mash approach of client and server components that Next et al now encourage.

For the type of app that React excels at, or at least the type I like to build, the performance issues with a SPA aren't a big deal.

The Future of Htmx 2 years ago

Right… I think HTMX is cool and would like to try it. But the argument that “we need to go back to when things were simpler” just falls so flat to me. I remember the Web 20 years ago. It was pretty bad and ugly and slow and clunky and unintuitive.

We’ve made a lot of progress since then thanks in part to the powerful front-end state management and rendering solutions that are now standard. And if the argument is “we don’t need all that, I prefer simpler web pages…” then I just think you may have a totally different preference set from the average user. Normal non-engineers like sleek modern interfaces, not Web 1.0 forms and links and reloads

Guessing its intended use case is business analytic queries without write permissions —- particularly for non-programmers. I don’t think it’d be advisable to use something like this for app logic

Leaving the Cloud 4 years ago

The HN community 1) likes building and hacking, and 2) has nostalgia for old technology. This makes them feel a lot of affinity toward "doing things themselves" -- server infrastructure, running desktop linux, avoiding dependencies in their code.

The reality, though, is that the steady march of progress encourages us to outsource what we can to people who are better at the thing that is auxiliary to what we do. I don't grow food because I'm bad at growing. I don't repair my car because I'm bad at auto repair.

I do build software, and my company builds a very specific type of software to solve very specific problems. I'm happy to focus on that, because that's how we make money. Other people are much better at building infrastructure than I am, and so I let them do it for me. If there comes a time when the cloud offerings are either worse than what I can build or too expensive, then I trust someone else will come along and fill the gap in the market before it becomes worthwhile for me to do it.