2 ms·
> That's true. But that's up to the company deciding over the operating system and the browser in the end. The OS is far more powerful, and allows for deeper i
by voz_ 7y ago
> That's true. But that's up to the company deciding over the operating system and the browser in the end.
The OS is far more powerful, and allows for deeper integration and writing in far faster languages. The browser abstracts away the machine. Most JS writers today have no idea or understanding of the actual computer they are writing against. It's a sandbox for them, and it's the reason apps today bloat to hundreds of megabytes and burn CPU to do the most mundane thing. Less distance from the metal is better in my book.
> Native in this case means running on one platform. I would much rather focus on making something that works for a bigger part of the world.
Feels like a strawman / bad faith argument. As a user, I'd rather use one fast app on my device, I don't care if some guy on another platform can use this product. As an engineer, I want happy users, and if that means writing X clients, so be it.
- holoduke 7y agoWhat is native? On Android the native Java UI kit is slow and not native. You need a lot of fancy work to get fast c UI libs working on the 1000 different android devices. Goodluck with that. Browsers are probably the most optimized virtual UI machines out there. Sure not native, but I would argue that an integrated webview with proper css3 is much better optimized that using the android component framework or native draw operations. On ios things are slightly different, but also there the standard UI toolkit is a freaking nightmare. Creating general purpose UIs in a language like css feels so much better than most if not all UI toolkits out there.
- saagarjha 7y ago“Native” in this context almost always means “using the platform UI toolkit”.