This is where small frameworks like Mithril shine. The site says 12KB, for some reason, but minimized and gizipped, the latest version is closer to 7 or 8 KB IIRC. http://mithril.js.org/
[deleted]
The viability of JavaScript frameworks on mobile
61–70 of 85 posts
Re: The viability of JavaScript frameworks on mobile
#62This is where small frameworks like Mithril shine. The site says 12KB, for some reason, but minimized and gizipped, the latest version is closer to 7 or 8 KB IIRC. http://mithril.js.org/
I don't say Mithril is bad but code size is no indicator for performance. Counterexample: The minified Box2D code is ~760kB large and impressively performant.
Re: The viability of JavaScript frameworks on mobile
#63This is where small frameworks like Mithril shine. The site says 12KB, for some reason, but minimized and gizipped, the latest version is closer to 7 or 8 KB IIRC. http://mithril.js.org/
I like riot.js; a react-like library weighing in ~3.5 kb min+gzip. http://riotjs.com/ Browserify gives you modules. This technology can be used to structure the code & package only the bare essential functionality. http://browserify.org/
Riot looks a whole lot like Polymer.
Re: The viability of JavaScript frameworks on mobile
#64This is where small frameworks like Mithril shine. The site says 12KB, for some reason, but minimized and gizipped, the latest version is closer to 7 or 8 KB IIRC. http://mithril.js.org/
I don't say Mithril is bad but code size is no indicator for performance. Counterexample: The minified Box2D code is ~760kB large and impressively performant.
It is an indicator of load time. Most users bounce off pages that take longer than 3 secs to load.
Mithril isn't the fastest of the virtual DOM libraries out there, but it is usually good enough, even on mobile.
Re: The viability of JavaScript frameworks on mobile
#65What's the status of asm.js in mobile? It would be nice if there was a front-end framework in some other language that could compile to asm.js.
Re: The viability of JavaScript frameworks on mobile
#66Earlier quoted context omitted.
It's relevant; iOS may be faster but the user experience still sucks when web devs rely on heavy JS frameworks. Rather than bemoan how much JS sucks on Android, devs should realize that JS sucks everywhere and use it as sparingly as possible. This is especially relevant since the fragmentation on Android means this problem won't be going away soon. Even if Google fixed its JS performance tomorrow, so many phone manuf…
It's not JS that sucks; V8 performance is actually pretty competitive with Dalvik, if not faster. It's two other things: 1. There is a cost to download frameworks, and most webdevs ignore that cost. A native app has the Android class libraries already on the device, oftentimes already loaded into memory. A webapp that pulls in 600K of JS code + framework has to read that all over the network, parse it, and JIT it bef…
When browsers support stale-while-revalidate we'll have the opportunity to make web apps update in the background the way native apps do.
Weight still matters; I just thought this worth mention.
Re: The viability of JavaScript frameworks on mobile
#67Earlier quoted context omitted.
It's relevant; iOS may be faster but the user experience still sucks when web devs rely on heavy JS frameworks. Rather than bemoan how much JS sucks on Android, devs should realize that JS sucks everywhere and use it as sparingly as possible. This is especially relevant since the fragmentation on Android means this problem won't be going away soon. Even if Google fixed its JS performance tomorrow, so many phone manuf…
It's not JS that sucks; V8 performance is actually pretty competitive with Dalvik, if not faster. It's two other things: 1. There is a cost to download frameworks, and most webdevs ignore that cost. A native app has the Android class libraries already on the device, oftentimes already loaded into memory. A webapp that pulls in 600K of JS code + framework has to read that all over the network, parse it, and JIT it bef…
JS does indeed suck on mobile; since it's single-threaded by design, all those blocking operations (you already mentioned some examples) add up. Hence where you get both issues you mentioned - those refreshes are only necessary because the single-threaded nature of JS causes a few dozen event handlers in your framework to fire on every change you make. It also doesn't help that most mobile devices aren't exactly pushing the envelope on single-threaded performance.
And let me be clear: JS being single-threaded isn't a bad thing in itself (the thought of a multi-threaded language in the browser gives me nightmares). It just makes the user experience of JS suck on mobile. And that's not going to change any time soon given the glacial pace of patch/update deployment on Android.
> It basically involved treating the browser as an OpenGL canvas, where certain combinations of CSS + HTML would render text and boxes into a texture and then other combinations would let you move textures around and fade them together in the window.
That approach -- while interesting from a technical standpoint -- kind of defeats the purpose of a browser :) I mean, you're basically building another browser inside the OpenGL window...
Re: The viability of JavaScript frameworks on mobile
#68Earlier quoted context omitted.
It's not JS that sucks; V8 performance is actually pretty competitive with Dalvik, if not faster. It's two other things: 1. There is a cost to download frameworks, and most webdevs ignore that cost. A native app has the Android class libraries already on the device, oftentimes already loaded into memory. A webapp that pulls in 600K of JS code + framework has to read that all over the network, parse it, and JIT it bef…
Why doesn't Chromium render more elements on the GPU?
Because rendering on the GPU isn't a panacea. On mobile platforms, it can have negative implications on battery life and performance, and given the sequential-dependent nature of CSS rendering, I'm not sure you'd even get the benefit of parallelization.
In many cases, you'd end up waiting for the main thread most of the time anyway (which you'd probably also get if you just spawned a few threads on another CPU core). It also adds a hell of a lot of complexity since SOCs have varying levels of capability in their GPUs, which your code now needs to identify, integrate and test against.
I'm not claiming there's no benefit, but there's a reason they don't just GPU all the things.
Re: The viability of JavaScript frameworks on mobile
#69With Microcosm we consciously chose to go the other direction: Do the work server-side and serve HTML. Basically... the old way of doing things. An example site https://www.lfgss.com/ is 280KB on first load (and most of that is Mozilla Persona) and subsequent requests are usually around 10KB. Even though that company is now dead, I'm still working on it and aim to strip out Persona (it's deprecated) and to set a firs…
Persona is not deprecated. It was moved to "community ownership", which is not "deprecated" just as much as the average open source project is not deprecated. It's a bit like saying that if Red Hat stopped paying it's developers to work on the Linux kernel then Linux itself must be deprecated.
I wish more sites would use Persona and so I'm heartily disappointed to hear someone expecting to strip it out of an existing usage.
(Aside, I gave a presentation on the subject, for what that is worth. http://blog.worldmaker.net/2015/05/13/mozilla-persona-talk/)
Re: The viability of JavaScript frameworks on mobile
#70Earlier quoted context omitted.
It's not JS that sucks; V8 performance is actually pretty competitive with Dalvik, if not faster. It's two other things: 1. There is a cost to download frameworks, and most webdevs ignore that cost. A native app has the Android class libraries already on the device, oftentimes already loaded into memory. A webapp that pulls in 600K of JS code + framework has to read that all over the network, parse it, and JIT it bef…
JS does indeed suck on mobile; since it's single-threaded by design, all those blocking operations (you already mentioned some examples) add up. Hence where you get both issues you mentioned - those refreshes are only necessary because the single-threaded nature of JS causes a few dozen event handlers in your framework to fire on every change you make. It also doesn't help that most mobile devices aren't exactly push…
Native apps are also effectively single-threaded: all of your code, by default, runs on the UI thread, and you need to use AsyncTask or explicitly spawn a Thread to do work in the background. If you need this functionality on the web, there's Web Workers, so it's functionally the same story.
CSS transitions/animations, BTW, run on a separate thread in Chromium. This is the primary difference between them and requestAnimationFrame, which always runs on the main thread.