Have a few friends who work there. But they have no needs for a subpar php backend developer :(

Well okay, but guess which one I'd rather have to maintain in a big codebase? Clearly written by a theoretical engineer.

For a large codebase, this would be encapsulated and heavily commented, etc. It's something that you pull out when you need to make something "go to eleven" kind of thing.

Exactly. You could have some exhaustive unit tests as well, and after that there would be nothing to maintain.

Plenty of library functions are already going to be optimised in this type of way - just because they're not visible in your codebase doesn't mean they are not there.

So if your big codebase were profiled, and the 99th percentile case happened to spend 80% of its time in this function, you would still stick to the old function unwaveringly? Even if your system was latency sensitive, and your 99 percentile spikes were far from acceptable?

Sure, there are many cases where this is a premature optimization. This blog never said otherwise. But that doesn't mean there is never a time for optimization. And if profiling points at this, then this speedup can be valuable.

> rather have to maintain

Well, as long as it works, what difference does it make? As long as it's prefixed with a

// This compares the matching number of bytes

comment, you should never have to mess with it.

With a compiler or architecture change, I guess this could create awkward to handle performance regressions.

It's about use cases.

There was an old lady 6 about unoptimized behavior in VB6 and why is wasn't necessary to do so. I had to write a wrapper for it which was optimized in my code. Was it harder to read? Yes. Did it produce a significant performance improvement? Also yes.

Software development is about tradeoffs. Demoing one way to improve a simple function helps others trunk how they write code, and more importantly why they wrote specific code

I've worked with engineers that must read these blogs and try to out-clever everyone.

They succeed, and that's the problem.

sometimes != always

makes sense that he would want to strengthen his credibility in an article like this, no?

Am I not getting this or is this just a slightly different way of using breakpoints like bootstrap some years ago? I think we've come full circle.

What makes this one different is that, for example, if you want to set the width, you just do it once. Other approaches (including bootstrap) you have to type "width" once for every break point where it's different.

The resulting code from this approach looks a little cleaner and nicer compared to bootstrap or normal CSS, at first glance. I'd have to test it before commenting further though.

The thing is most companies would want to have a web presence anyway. It's just easiest exposure and people have to be willing to install a software - visiting a website not so much. So if you're building these cross-platform apps on anything other than the Web stack people will still have to have different code bases for native and web which kinda defeats their purpose.

So I don't think you have any real alternatives until there's other technologies on the web or wasm can do everything.

As I kind of alluded to in my comment, I'm not sure many of these things need to be web apps. OS level sandboxing has come a long way in the last ~10 years, and need fewer of the benefits of the web (like publicly addressable resources), and more of the benefits of desktop apps (like filesystem access). Web tech is improving its support for the latter, but I think we could do better if we designed a system today, rather than using one mostly designed between 95-05.