51–60 of 85 posts
The article is interesting but the Atwood article was mainly about how badly Android javascript performs vs iOS. If you have a 5x difference in performance between platforms it will be impossible to maintain feature parity.
I think a lot of developers wanted mobile web performance to catch up with desktop and mobile native that we believed it would happen, and much faster than was ever really likely. We're used to things getting better quickly when it comes to technology. Flagship phones improve things a little each year, but to quote William Gibson, the future is here, but unevenly distributed.
It doesn't help that some influential people in the software industry, like Joel Spolsky, told us to bet on the hardware improving fast. See for example:
http://www.joelonsoftware.com/items/2007/09/18.html
Particularly this part:
> a couple of companies, including Microsoft and Apple, noticed (just a little bit sooner than anyone else) that Moore’s Law meant that they shouldn’t think too hard about performance and memory usage… just build cool stuff, and wait for the hardware to catch up. Microsoft first shipped Excel for Windows when 80386s were too expensive to buy, but they were patient. Within a couple of years, the 80386SX came out, and anybody who could afford a $1500 clone could run Excel.
By contrast, he describes Lotus optimizing 1-2-3 so it could run in 640K of memory. Who would want to be today's equivalent of Lotus? So just pump out features and wait for the hardware to catch up, right?
Would be interesting to see Meteor stats there too
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/
or you could just write regular Javascript. Browsers seem to be pretty good at handling Javascript, CSS, and HTML. The default size of vanilla js is actually 0 KB and that's not even gzipped.
And after reaching a certain level of complexity what you have is an ad-hoc framework of about the same size but is a slow, bug ridden implementation of half of one of the ones in the OP.
Earlier quoted context omitted.
This is heartening. How do you deal with cross-browser differences, especially considering you're supporting older mobile devices?
You deal with them one at a time. It's not like there's magic involved. Our SPA isn't even using jQuery. Loadtimes are fast, app is very fluid. Many people seem to not understand that when you query the dom for a node, you can store that node and reuse it throughout your app.
Earlier quoted context omitted.
Sure but GWT == writing Java, downloading an heavy an complex SDK , and writing imperative UIs. Sure it comes with widgets but you can find the same widgets in JS. Compare with React,AngularJS and co : way more popular,declarative UIs , if you need static typing you can use Typescript which needs no heavy runtime. GWT might make sense for some LOB app for desktop but not for a mobile webpage.
Google Closure Compiler [1] can also perform dead code removal, but it requires extra work annotating all public APIs and naturally it can't cope with dynamic/indirect calls. [1]: https://developers.google.com/closure/compiler/
Earlier quoted context omitted.
I'm not sure I understand, how can a framework "solve" code performance? Do you mean that it's faster than other frameworks?
The article mentions load performance. Meaning the time it takes to download and setup the Framework. GWT compiles Java to JavaScript and leaves out code that will never run. JavaScript frameworks load functionality in case that functionality is required, even if you don't use it.
Unless you use something like webpack to segment your codebase.
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/
Just came back to mention that two of the most well-known Mithril-based projects, Flarum.org[1] and Lichess.org[2] are open source and have mobile UIs that you can try out, so if anyone's interested in seeing non-trivial codebases that use a "lighter approach" alluded to in this article, there you go. [1]( https://github.com/flarum/flarum ) [2]( https://github.com/veloce/lichobile )
http://lichess.org/ is an [f|F]ree online chess platform.
Rule #1 for optimisation: "You can't make code run faster. You can only make it do less." It's true for mobile devices as much as everything else.