Most modern smartphones run Android, which means they have a bastardized Java VM between your "native code" and actual metal... not unlike having a JS VM.

It's not that "native software" has become less efficient, but rather that it is slowly disappearing.

As of Android 5.0, the Android Runtime (ART) compiles Dex bytecode ahead of time to native code. That probably still isn't as efficient as C++ or the like, because there's still a garbage collector, and Java methods are virtual by default.

  how fast JS engines have become in the browser

I am not so sure. It is more like "JS barely runs a software that has a recommendation of 66 mhz CPU".

Maybe it is about emulation the whole system but still I was expecting better.

I agree it is a very cool demo.

Is there anyway I can find out the call flow of this JS program?

Like to see the actual dynamic call flow graph instead of just simple static flow analysis output.

That's because the Win98 code is that much simpler. It has less to do with speed and more to do with complexity.

Your phone is doing all sorts of weird shit behind your back as you poke about. Stuff that it's not supposed to be doing if app-makers were actually respectful of their users...

On that note, why does that crap take so long on smartphones anyway?

One tweak that made my G2 feel much more responsive is simply turning down the UI animation length in Dev Settings. That's not to say that app developers don't love their non-native webview apps crammed to the brim with ads, though...

UI animations have a lot to do with it, but I'm more referring to UI jank over simple stuff like 'enumerating a list of sharing targets' or 'swiping to the next page of the launchboard' when the phone is otherwise idle. Or, my favorites: the multi-second pause from unlocking my phone during a phone/skype call, or the taking of an actual eternity just to answer said fucking Skype call, of which half the time the call has already hung up once my phone is finally responding...

That's why I switched to windows phone. It's a whole new experience. I can actually answer my phone without the obligatory wait for catch up before I can swipe to answer.

Had a client who later wanted me to do add all sorts of nasty things to an Android app template that I had made for him: Locking out primary navigation buttons, partially replacing the home app, spying on the user, and the capability to send out very expensive SMS texts and auto dial long distance phone calls. Unfortunately I was unavailable to do the addons he wanted, despite him asking repeatedly over the next 18 months. Never trust an Android app...

I think a big part of it is simply loading in resources and the like. Smartphones try to keep a _lot_ of apps in memory, so there's a lot of switching around.

Another thing is that Windows would put certain native widgets (like file selection) on a higher priority than other program code. Android, at least, tries to put as much stuff in userspace as possible, so you might be experiencing the reality if everything run at the same priority.

I miss the shitty machinery of win9x days[1]. The weird part is that I was deep into CGI, and compositors made so much sense to allow for all kind of graphical operations; yet.. I miss the refreshed icons, blinking cursor .. as if I was one to one with that simple machine.

That's very subjective, I'm in a minimalist passeist phase.

[1] Except for the non isolated driver model.

> I'm in a minimalist passeist phase.

> ...one to one with that simple machine.

Recommendation: Forth (cf. colorForth)

Warning: Save snapshot of current mental state/perspective/worldview first, to guarantee sustained mental health :P

I regularly scan (ansi|gnu|color|*)Forth webpages. Thinking Forth is on my mental shelf for so long. ML and Lisps keep delaying reading it.

> I regularly scan (ansi|gnu|color|)Forth webpages.

I occasionally do too :P

> Thinking Forth is on my mental shelf for so long. ML and Lisps keep delaying reading it.

I know the feeling... but I'm still at the "Lisp looks like parenthetical line noise, and what even is* ML?" stage, so I haven't yet tackled those.

Forth, to me, seems to be bring out the "mechanicalness" of the computer, in a weird sort of way. Of course it's just another programming language, but the philosophy and mentality behind it seems to lean in that direction. I like it for that, and its minimalism. :D

I love lisp and ml to bits, it's more that there's a whole cosmos to learn from there (type systems, macros, logic resolution, you name it).

I kinda understand the mechanicalness of Forth, if you mean that there's only a few principles and that even 'syntax' is built on that. The kind of less is more that frees your mind

I suspect smartphones to have crippled IO and memory subsystem. Marketing emphasize on "Hexa Core 128 bit Samsung silicon from the future" while the rest is subpar, leading to weird performance. JS engines are beautiful these days, especially given the adhoc nature of js, but a JVM should beat it hands down (based on blogs claiming reaching 1-3x C perf).

I ran this successfully on my smartphone...

You might think it's a great demonstration if you try it in a desktop browser.

Meanwhile, on actual mobile hardware, the performance is so atrocious it's completely unusable.

No knock on the implementors of course. But the idea that this demo has some deep insight about the performance of native smartphone software is just inaccurate.

http://cl.ly/2O0L3t290s37

I didn't mean to compare native mobile apps to web apps (though I see now how it could be read that way). I'm talking about native software in general. I chose smartphones for the comparison because they're the most notorious about being slow, even as their hardware performance approaches what PCs were like just a few years ago. Although even some desktop apps manage to be as janky and dog slow as almost anything from the Win98 era, e.g. iTunes until a couple of years ago. By contrast, the cheapest Third World market smartphone would run Win98 apps blinding fast.

In general there's an arms race between hardware getting faster and native developers getting more and more lazy about efficiency. On the desktop, the hardware is finally winning--it's just too damn fast. Hopefully that will happen with smartphones too.

> Although even some desktop apps manage to be as janky and dog slow as almost anything from the Win98 era, e.g. iTunes until a couple of years ago. By contrast, the cheapest Third World market smartphone would run Win98 apps blinding fast.

It is easy to take potshots at e.g. iTunes, but the real reason software "got worse" is not developers getting lazy. What happened is that expectations for CPU-intensive features rose (memory protection, ASLR, NX, encryption, low-latency audio, high-efficiency codecs, ClearType) while willingness to pay vanished. In Win98 times, you bought your music player from the developer (remember Winamp?) whereas now it comes free with your OS, which is itself probably free. So of course it is all half-assed now, but it's not "lazy" to spend resources on software someone will pay for, and not on software nobody will pay for.

You could absolutely reverse this, but it has nothing to do with native or web technology, and everything to do with changing consumer attitudes about choosing software.

> On the desktop, the hardware is finally winning--it's just too damn fast. Hopefully that will happen with smartphones too.

From 1995 until today, power consumption in desktop processors grew about 5-15x, depending on how exactly you measure. 5-15x more power on mobile devices is simply not an option, unless we have a "new physics" kind of breakthrough in both battery and thermal technology.

Willingness to pay didn't vanish, it's just that how we pay has changed. No, we don't pay for iTunes, but iTunes is the entry point to the iTunes store, so there's plenty of revenue coming in through that. And while iTunes and OSX are free, the hardware that OSX runs on makes up for that by being more expensive.

It's getting better (particularly on high-end phones) but single-threaded performance is still nowhere near circa-2013 desktop x86_64 (3.5ghz+ haswell). And it'll probably never catch up due to the thermal and battery life constraints.

"Never" is a very dangerous word to use considering that just 70 years ago, the ENIAC was created and that about 20 years ago, we were using Pentiums with 150-200MHz. The fact that we've come such a long way in such a short time means we probably have quite a ways to go, too.