Hacker News Reader

Comment by kristiandupont | Hacker News Reader

>These technologies really weren't designed to support this sort of complex dynamic UI

I used to think of this when I saw UI developed in C++ (instead of pure assembler. Jesus, they would just multiply with a scan width instead of shifting!). I thought it when I switched to Windows (they're running everything through a giant abstraction layer here! That will never perform!). And yes, I find myself thinking this again now that the final bits of software seem to be moving into the browser. But this time, I'm going to assume that I'm probably wrong :-)

View on HN

Bottom line: What is the end user experience?

I don't care how many abstraction layers, VMs, and scripting languages you do or don't use. I care that my UI doesn't lag or have choppy scroll animations, and that the battery doesn't drain 2x faster than expected.

Yeah, eventually these problems will likely disappear with more powerful hardware. But we're not the yet, and a good engineer realizes hardware limitations and designs software appropriately to achieve a great user experience.

"software is getting slower more rapidly than hardware becomes faster"[1]

I was showing a junior some plpgsql yesterday and he asked me what languages use BEGIN, END etc. So I pointed him to Pascal and ended up myself on wikipedia where I (re)found the above quote.

One of the points people normally make for HTML/JS/CSS is that the browser is sandboxed and there is already a well defined standard on how to serve dynamic content to a browser, across ALL platforms.

This might change with all platforms moving to a package manager or walled garden, and we then might start to see some "native" code again. But even the new platforms op-in for web tech like Metro etc.

But meh I'm rambling again so I will leave who ever will read this comment with a link to vsftpd[2] security section because I liked the idea of sandboxing a application with chroot and with that you can start to build a "Secure" native app.

[1]: https://en.wikipedia.org/wiki/Wirth%27s_law [2]: https://security.appspot.com/vsftpd.html#security

JavaScript is a slightly different situation. The degree of "sufficiently smart compiler" required to get C to run at assembly speed/power is nearly trivial (strength reducing multiply to shift? really not hard). On the other hand, the degree of "sufficiently smart compiler" required to map JS's type system and execution model to the machine is much higher and in some cases is impossible, which is why we have to use lots of JIT tricks (which takes power and time) just to get a mature, native-optimized JS program to run at half native speed at who-knows-what power.

Reply on news.ycombinator.com