Statements about the Mobile Web

Let&#x27;s not kid ourselves here. Most people download exactly zero apps per month:<p><a href="http://www.slate.com/blogs/future_tense/2014/08/25/a_comscore_study_shows_that_most_people_download_zero_new_apps_per_month.html" rel="nofollow">http:&#x2F;&#x2F;www.slate.com&#x2F;blogs&#x2F;future_tense&#x2F;2014&#x2F;08&#x2F;25&#x2F;a_comscor...</a><p>This matches my experience IRL exactly. The whole Native Apps are more popular than the web narrative is a self fulfilling prophecy. People have trouble using websites on mobile because everyone puts up stupid splash pages on sites to force them to download their app. It &quot;educates&quot; people that the web is somehow inferior, when really those sites should be making a proper responsive website so their users can get on with their lives.<p>Nobody gives two shits about your app and it&#x27;s smooth animations when they are just trying to pull up a recipe for chicken tikka masala.

Here&#x27;s my guess for the future of the canvas web. JS will render to canvas. Later it will be discovered that the code becomes unmaintainable and multi tiered architectures will go in the browser&#x2F;js with &quot;BabyHTML&quot; used as a template view language for the canvas to have a more standardized rendering - finally who wants to render pixels or vector graphics?. Then a BabyJS will be introduced inside BabyHTML to manipulate an object model called BabyDOM for the canvas to make more maintainable code and optional animation. BabyJS will be so fast that everything that can be written in BabyJS will be written in BabyJS. Then BabyHTML and BabyDOM will be claimed slow with frameworks based on BabyJS rendering directly to BabyCanvas which will be inside canvas which will be inside browser webview.<p>And all this repeats ad infinitum.

I hope 2015 is the year JS devs really start pushing for real async&#x2F;threaded support in the browser. I was working on the reapp HN reader app[0] for the last few days attempting to find out why Safari would choke for up to 20 seconds on displaying ~500 DOM nodes, and this article just sparked an idea which turned out to be true: flex-box was causing it.<p>Switching to display: &#x27;block&#x27; and it&#x27;s under 100ms. I think now I&#x27;ll look at using css-layout to just spit out absolute positions.<p>I also appreciate the shout out in the article to reapp. I&#x27;ve spend the last few days working with WebWorkers, which have some interesting potential, but without access to the UI are going to be tricky to implement. Again, the React guys have gotten something working, and we had an interesting conversation about using Flux to communicate between Workers&#x2F;main thread, which I&#x27;ll be exploring.<p>Long and short of it is this: We&#x27;ve gotten pretty damn close with the web these days. For anything that doesn&#x27;t use exceeding long lists of media-heavy content, you can actually get 60fps with react. But you have to be <i>careful</i>.<p>I&#x27;d love to see UI workers, async DOM ops, and even Canvas support for better accessibility. Web developers should all be writing and voting up articles like this.<p>[0] <a href="http://hn.reapp.io" rel="nofollow">http:&#x2F;&#x2F;hn.reapp.io</a>

To me, this &quot;60fps or bust&quot; notion that seems to have come up recently is complete and utter nonsense. It&#x27;s masturbatory technofetishism.<p>In the eight or so years that I worked as a system administrator and the many more years that I have been the go-to guy for all things computer-y for friends &amp; family, I have found the vast majority of people to be tolerant towards the inconveniences and failures of technology to the point of defeatism.<p>The things people put up with sometimes boggles the mind. Eight minute boot time to a usable desktop? <i>&quot;Oh, I just tap the power button and get coffee&quot;</i>. Half a dozen browser toolbars they never installed willingly. Popovers and popunders. Nagging Java updaters and upselling &quot;security software&quot;. Forced reboots that kill your unsaved changes over lunch when Windows decides to install updates. And, and, and…<p>That story hasn&#x27;t changed one bit on mobile. <i>&quot;Well, I know know that I have to restart my phone [for two minutes] before I can play this game, because it crashes otherwise&quot;</i>.<p>There&#x27;s a good chance that this is the majority of people interacting with your app, site or gadget.<p>If you can squeeze out silky animations and buttery scrolling out of a complex web app, go for it. I&#x27;m the first to marvel at your ingenuity and applaud.<p>But if you honestly think that these people care enough about &quot;60fps scrolling&quot; that it warrants reinventing pretty much the whole of HTML and CSS in Javascript — badly —, then I don&#x27;t know what to tell you.

And beyond the performance issues, app design on the web is a massive pain.<p>Despite the advances with CSS3, we&#x27;re still working with a layout engine that was designed for documents rather than applications (mobile and otherwise), so many seemingly trivial tasks (e.g. centering and vertical alignment) involve an unintuitive mess that I after 10+ years of experience, I still need to lookup from time to time. [Edit: I should have been more clear--I&#x27;m referring to issues that flexbox doesn&#x27;t resolve such as aligning&#x2F;sizing elements relative to each other rather than to their parents.]<p>On top of that, we&#x27;re seriously in need of better tooling. It feels like we&#x27;ve spend the past 10 years developing a set of powerful primitives but ignored building tools that truly empower our creativity on the web. Sometimes I really miss how fun and simple it was to use Flash to build things when I was a kid...<p>...and that&#x27;s the whole point really, isn&#x27;t it?

This is dead right.<p>The fun begins when you think about how this impacts anything that tries to scrape web pages, because the side effect is going to be a lot of impenetrable data silos.<p>Google and co will have to actually run web browsers in the cloud and use OCR to do indexing if they aren&#x27;t already.

So, there is a cheap way to communicate between the DOM thread and web worker threads. It&#x27;s called Transferable Objects. The technique involves postMessage()&#x27;ing a Typed Array&#x27;s ArrayBuffer as your message payload. Rather than making a copy of the bytes in your sending thread&#x27;s Typed Array, the byte buffer is &quot;detached&quot; from the sender&#x27;s ArrayBuffer and &quot;attached&quot; to a new ArrayBuffer on the receiver thread. This allows you to do huge bulk operations on a worker thread, generating megabytes of data for the DOM thread and not taking a penalty of allocating memory, copying the data, and garbage collecting a big allocation on the sender thread.<p>Transferable Objects are not as useful as, say, being able to access the DOM from a worker thread. But there are many tasks that ultimately feed DOM updates, are data intensive, and could be mostly offloaded to a worker thread with the final update payload fed to the DOM thread via Transferable Objects.<p><a href="http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast" rel="nofollow">http:&#x2F;&#x2F;updates.html5rocks.com&#x2F;2011&#x2F;12&#x2F;Transferable-Objects-L...</a><p>The DOM&#x2F;Layout&#x2F;CSS is a crufty document engine. Is it reasonable with today&#x27;s hardware to have a 60Hz scroll rate benchmark of quality? I think expanding mobile main memories and CPU advances this decade will make it more reasonable.<p>How about framelocking us to 30Hz on mobile, could we be satisfied with that? Makes me wonder if there is a way to framelock a browser scroll with requestAnimationFrame().<p>-- edits clarifying ArrayBuffer

Nice to see the random Servo reference drop, it&#x27;s cool to see it gain recognition outside of Rust circles. They&#x27;re doing so much cool stuff.

I wish it wasn&#x27;t true - but if there is a native app available for a website&#x2F;service i wish to use - I choose native app almost all the time. Each of these services have a 100% work website &amp; maybe a mobile-web: - Ebay, Amazon, Mint, SigFig, Homejoy, MerillEdge, BofA BillPay, PizzaHut, Dominos... Somehow using their native app feels solid, real and not flakey. I don&#x27;t have a feeling that I will loose my shopping cart or be logged out due to an error&#x2F;network connection etc.<p>I am a big advocate of truly native mobile web, but honestly the first thing i look for when i love a service or website is: &quot;Do they have an iPhone app?&quot;

The 60 fps thing is super weird to me. Do people really care if their website&#x2F;mobile app is 60 fps? Who are these people?<p>The only place I could possibly imagine that mattering is for fast-twitch video games, or theoretically videos (though most of those are still 24 or 30 fps).

I&#x27;m pretty skeptical of React Native, for the same reasons you&#x27;re nervous about the web. The great thing about Native development is you can drop down pretty low and optimize. During native development you do it alot. The native widgets don&#x27;t suck, but performance can be awful as soon as you want to draw anything remotely special. So you drop down and start writing custom layout and drawing routines. I don&#x27;t see React being good at that (maybe I&#x27;m wrong though, I haven&#x27;t dug into it).<p>Those problems aren&#x27;t that far from the web. There&#x27;s no reason you can&#x27;t draw entire pages made of canvas[top=&quot;0&quot;][left=&quot;0&quot;] and then measure position&#x2F;transform everything by hand. You&#x27;d probably get great performance that way. Its basically what Flipboard did from what I read. Its what native app developers do as well. Phones suck. They have no power. You basically have to do this stuff to make them work. I have no idea why the web-dev community freaks out when someone does it. &quot;You wrote a custom layout engine! Are you nuts!&quot; is not something you&#x27;ll hear from Android or iOS devs.

Layout and performance of the mobile web is a red herring in the argument of why mobile web is losing. It&#x27;s not just this. There are so many other factors that I rarely see mentioned. Encrypted &#x2F; protected caches, local databases, far more persistent logins and UUIDS, sensor integration without the annoying Browser requests x feature modals, launching from the home screen, consistency of experiences because of standard human-interface guidelines, background sync and notifications, integrated payment systems, and on and on.<p>Apps integrate with the entire rich ecosystem of the device and web apps barely &#x2F; inconsistently do. There is work happening on all of the above things (kind of), but the experiences arent competitive, the work is piecemeal and the pace is far too slow for people who have the webs best interests at heart. The web is losing because the consensus model for standardising and making available the tools for building the web is antiquated and terribly ineffective. Unless there is a massive change in incentives for standards committees and mobile browser providers this wont change.

Question: why didn&#x27;t any of these issues prevent the web from taking over the desktop during the years between 1995-2005? Native has always been faster and more feature rich, on every platform and at every point in time.

Besides accessibility, if you replace everything with JS and Canvas, you lose transparency. Content then becomes opaque, siloed behind services, and requires running code to discover.<p>If we are to replace with a native-app style model, it needs to be far far more transparent that what is on iOS and Android with respect to exposing links and content in a way that is transparent.<p>If we convert the Web into a Web of Binary Applications, who query all of their information through private silos, we may as well just close up shop, because we&#x27;ll be forgoing the greatest values of the Web, Links and Transparency.<p>We need to stop panicking over mobile native and FPS.<p>The idea that &quot;60 fps is required&quot; is a complete myth. Most triple-AAA game titles people pay $50 for on consoles don&#x27;t hit a solid 60fps, most of the time, not even a solid 30fps -- typically frames are dropped in busy parts of the game.<p>The ideology that Apple has foisted on design, that somehow no one will use your app if it is not perfectly rock solid 60fps (iOS isn&#x27;t even 100% jank free) is damaging.

For performance, I agree with many here, it&#x27;s not the number one priority. The critical parts missing are:<p>(1) a way to install web apps that hasn&#x27;t to be learned, like Mozilla&#x27;s Intall API, and unlike the bookmark to homescreen UI<p>(2) offline APIs: ServiceWorkers seem great but, Safari support could come as late as fall 2016 I guess, and be botched up for a year or two like they did with the history API and IndexedDB; in the meantime, offline web apps are screwed<p>(3) full screen API: not having the ugly address bar all the time which reminds users this app is unlike others and may be substandard; and being able to lock screen orientation<p>(4) notification API: the users expect anything important your app displays, they can be notified about, otherwise, your app seems unreliable<p>Except, the notification API, both iOS and Android had all of those from the start. Only then should we worry about performance, sensors, frameworks, layouts, ...<p>Regarding image decoding, why can&#x27;t browser vendors do it today off the main thread? Is a change in web standards required? It seems no one has implemented it, so if it was a low-hanging fruit material to performance, it would be done already. In my experience, image decoding is only an issue for infinite scrolling, when javascript inserts images too late for the browser to have smooth scrolling. Infinite scrolling is nice sometimes but not all lists have to be infinite, have they?

I realize the web has a huge headstart on anything else, but what prevents someone (or us, as a community) form creating application containers that are not web browsers. Why not something like a &quot;Python Box&quot; where you can download and run applications written by developers in Python, and where the UI is rendered asynchronously in just the ways people say they want it (at least in this thread).<p>I know that on day one there won&#x27;t be anyone on your &quot;Python Web&quot; or whatever alternative browsing box you make, but if its nice to developers, and if it really does give users a better experience, then eventually we&#x27;ll see people use it ... just like any good idea takes root in the long term.<p>I know the web is already here, and it makes a lot of sense to leverage the fast V8 engines we already have pre-installed on all our users&#x27; desktops and devices, but I am really surprised that we haven&#x27;t seen any alternatives in the two decades since we&#x27;ve figured out that Javascript&#x2F;CSS&#x2F;HTML really suck for a whole class of applications.<p>I suppose you could say the JVM was one attempt to do this ... but the JVM was proprietary and it wasn&#x27;t properly marketed to end users.<p>The app box I&#x27;m talking about should be something that users feel they have to download because it will be an infinite amount of fun.<p>Security is a huge problem I know. But surely we can figure out something using containers&#x2F;VMs etc. to airlock all the random code that will be downloaded into the box by users.

The points raised are good, but I think web vs. native is a false dichotomy to be honest. It is quite possible for both to co-exist. The problem I see here is that, by losing the shackles of backwards compatibility, native vendors are able to move much more quickly and that upsets developers in much the same way kids get upset when their sibling gets a shiny new toy.<p>The pragmatic kid will try to find ways of sharing the toy, or get one of their own, but the stubborn kid will convince the others that their toy is batter, faster, smarter, stronger, and all of the things. The analogy breaks down a bit, but I hope my point gets across.<p>The web, for all its warts, is a wonderfully resilient system. It can break any which way and it&#x27;ll still probably mostly work. Most other systems simply don&#x27;t work that way, because it&#x27;s damn difficult to build such systems. By working within the constraints of the web, you&#x27;re almost forced into it.<p>What we can do to help developers better leverage the web, regardless of whether their UI is native or HTML, is to not be religious about the things that don&#x27;t really matter – which I think is what James is trying to really say. His points are clear and good, but the underlying (and in some parts quite explicit) message is one of: let&#x27;s not be kids.<p>Our toys are sometimes broken (DOM, CSS layouts, single thread execution models) and we should consider changing them for better models or even new ones, that aren&#x27;t so broken. But we have to stop the in-fighting, zealotry won&#x27;t get us anywhere.<p>---<p>It should also be noted that James&#x27; post while talking about the <i>web</i> is actually more about <i>rendering</i> than anything. There is so much more to the web, architectural principles that transcend platforms – such as hypermedia, stateless message transfer, metadata. Let&#x27;s not pretend rendering is the end-all be-all that the web has to offer.

People keep saying &quot;The DOM is slow&quot;, which is true, but they forgot to talk about how &quot;Everything else is also slow&quot;. I.e. even with React and make sure every shouldComponentUpdate gets called, we&#x27;re still getting slow performance. We need to start using all kind of hack to make it faster. Sometimes it&#x27;s really frustrating to spend a day to make it look native while it&#x27;d take 10minutes with native android. I&#x27;ve been trying for years to develop cordova apps to avoid duplicate codebases, but I feel like it&#x27;s just not worth it. It&#x27;s supposed to save money and time, but in the end it just take more resources to get a shittier experience. So, definitely looking forward for background task and faster DOM manipulation.<p>But also, to be fair, if Apple could fix their damn webview, performance would be much much better. I&#x27;ve been told that they&#x27;re not fixing it on purpose.

About prediction #1 - here is micro angularjs demo showing angularjs digest cycle running in separate worker <a href="http://glebbahmutov.com/blog/run-angular-digest-cycle-in-web-worker/" rel="nofollow">http:&#x2F;&#x2F;glebbahmutov.com&#x2F;blog&#x2F;run-angular-digest-cycle-in-web...</a>

The DOM is to slow on mobile issue is what spawned <a href="http://famo.us/" rel="nofollow">http:&#x2F;&#x2F;famo.us&#x2F;</a>. They go beyond virtual DOM by creating their own layout engine that then outputs to optimized DOM (or canvas&#x2F;WebGL).

There&#x27;s a progression from <i>ignore mobile</i> =&gt; <i>make it work on mobile</i> =&gt; <i>responsive design</i> =&gt; <i>adaptive design</i> =&gt; <i>mobile first</i>. But that&#x27;s not far enough. Native mobile apps are <i>mobile only</i>, so in order for web apps to compete head-to-head, they need to be <i>mobile only</i> too. That&#x27;s a cultural leap the web needs to make. &quot;The web has failed to beat mobile because it lacks 60 fps&quot; seems premature until we finally figure that out. I&#x27;m not saying all webapps should be mobile-only, just ones that truly want to compete with native apps.

I am not a &quot;web developer&quot; at the moment but rather into signal processing and I can only agree. Why is it so hard to just draw a pixel on the screen? Or why are there so many ways of doing it?

&gt;&gt; <i>The web isn&#x27;t close to competing with higher-end native apps.</i><p>I made the switch from web development to native app development after leaning this fact at the HTML 5 conference a couple years ago. Every framework, rendering engine, etc., touted its strength in terms of a percentage of native app performance: this renders 80% as fast as native code, that responds 90% as fast, etc., etc. At the end all I could think was <i>why are we wasting our time with mobile web?</i>&quot;

&gt; By now it should be clear that too many users would choose a native app over a web app.<p>I, for one, don&#x27;t.<p>Why install a 500MB Facebook app when I can get the same news feed with a 1kb bookmark?

The point about religion is key. We <i>really</i> need to go back to basics with this stuff and reevaluate what exactly we&#x27;re trying to achieve here from the ground up. We simply cannot retain first-class support for 20 years of legacy cruft <i>and</i> make meaningful progress. So if we could start again today, what would we want from a &#x27;browser&#x27;? How about:<p><pre><code> - A cross platform execution environment - Hot code loading - Fetch, load, run in seconds - Source based; inspectable by user - Complete separation from the host OS except via well-defined, permission-based APIs - A mechanism for including 3rd party code and UI modules, fetched at runtime, and appropriately sandboxed - A suite of strong, high-level, declarative UI APIs - A suite of strong, low-level, UI APIs - Good crypto support - Pain-free concurrency - A nice language that behaves well as a transpilation target - Ints, floats, and all the other wonderful number types (and not just in arrays) - Strong support for displaying structured information - Accessibility, extraction, etc - etc, etc, etc </code></pre> I don&#x27;t know about you, but none of these things scream HTML, JS, or CSS to me. HTML is an arbitrary XML schema that&#x27;s fixed and subject to standardisation because it&#x27;s trying to do too much: it cares about layout, content, semantics, accessibility, and programmatic stuff. All of that needs to be parsed out into separate, much simpler data structures anyway to actually be used.<p>And I&#x27;m sorry if I&#x27;m offending your world-view here, but JavaScript is a complete fucking mess. If you love it that&#x27;s great - nothing to do with me - but as the <i>only</i> language on <i>the</i> dominant end-user runtime environment? What a sick, twisted joke. Honestly how much time has been wasted dealing with it&#x27;s deficiencies? With a language that has a monopoly, every little quirk, every tiny failure in the design process that makes it do something you didn&#x27;t expect translates to hundreds if not thousands of <i>man-years</i> shat away. I&#x27;m not exaggerating either: shit adds up at scale (and if you don&#x27;t believe me, consider that the subset of British people who actually had reason to call the government(?!) last year spent a cumulative <i>750 years</i> on hold).<p>So much of everything we do (in the western world, at least) is dependent on the technology we have for creating, moving, and consuming information, and the browser is the king of this world. So it&#x27;s not just <i>mission critical</i> that we get it right, it&#x27;s <i>economy&#x2F;happiness&#x2F;progress-as-a-species</i> critical too. A big shift here would be in the same ballpark as the switch from steam to internal combustion! And we already know it&#x27;s possible, we&#x27;re just too risk-averse to commit - but that&#x27;s the short term view, in the long term digging this hole any deeper carries significantly more danger.<p>I suggest we take the plunge and commit to a wholesale overhaul to something correctly designed by the best minds around, and with an aim to deprecate the current system in 5-10 years. We&#x27;re (slowly) doing it with IPv6 because we have little choice, let&#x27;s not wait for that to happen here - let&#x27;s get it done before we&#x27;re in a corner and are forced to make a tonne of half-baked decisions in a hurry.

Actually, we are building web-first. We believe we&#x27;ll be able to optimize enough locally by caching files in a bundle and intercepting requests PhoneGap style. We&#x27;ve already tried it, but here&#x27;s the web (non-cached) version:<p><a href="http://qbixstaging.com/Groups" rel="nofollow">http:&#x2F;&#x2F;qbixstaging.com&#x2F;Groups</a><p>Built with <a href="http://platform.qbix.com" rel="nofollow">http:&#x2F;&#x2F;platform.qbix.com</a>

I think major problem is connectivity. Make your site work offline and with slow connection and you are there.<p>500KB of javascript and CSS code is another problem

I think James is on target in many ways, but I just wish it wasn&#x27;t such a bleak near term outlook for high end mobile web apps. I don&#x27;t want to write my app differently for different devices. I know that is the reality of today, but it is an unfortunate reality.<p>That said, many apps don&#x27;t need to push the limits and PhoneGap or a similar solution is sufficient.

Aren&#x27;t the browser vendors better placed to fix these issues? Why can&#x27;t they implement a virtual DOM with super cool DOM diffing? Of course they can, and of course they will.

&quot;The DOM is slow&quot;: with all the advancement of the JS engines we&#x27;ll hit a wall if the DOM does not start improving by an order of magnitude.<p>Is this a fundamental problem or is this a case of JS being so bad that now that it&#x27;s faster it is exposing a need to focus on the DOM?

Why is the obvious so radical? Probably because YCombinator loves to delete anti-js comments on here? I mean hellbanning is one thing but completely removing the comments is another.

Once you go Canvas, you never go back!