
Statements about the Mobile Web - bceagle
http://jlongster.com/Radical-Statements-about-the-Mobile-Web
======
underbluewaters
Let's not kid ourselves here. Most people download exactly zero apps per
month:

[http://www.slate.com/blogs/future_tense/2014/08/25/a_comscor...](http://www.slate.com/blogs/future_tense/2014/08/25/a_comscore_study_shows_that_most_people_download_zero_new_apps_per_month.html)

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 "educates" 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.

Nobody gives two shits about your app and it's smooth animations when they are
just trying to pull up a recipe for chicken tikka masala.

~~~
forrestthewoods
Are native apps more popular than the web? Probably not. Is it harder to make
a web app to the same level of quality as a native app? Absolutely.

Making a "proper responsive website" for mobile is far more difficult than it
needs to be. Assuming it can even be done. Some things you simply can't do.
Can you reach just short of native quality by expending significantly more
time and effort? Yes! Is that stupid and wasteful? Absolutely.

~~~
woah
It's definitely hard to do animations and touch interactions as good as native
apps. Making responsive websites is really really easy for an experienced
designer and/or html coder.

~~~
mbesto
> _Making responsive websites is really really easy for an experienced
> designer and /or html coder._

Migrating old websites that do not respond + adapting web based apps to mobile
is however, not very easy. These two cases are probably 90% of the use cases,
as opposed to the other 10% that are "really really easy".

~~~
tomelders
You can't retro fit responsiveness. Or at least you can, but it's such a bad
idea that no one should try it. It's the quickest route to legacy CSS that no
one will every want to touch again.

It means starting again, from design and UX all the way up to build. So for
the entity that owns the website/web app it's going to be painful, but for
every new website/web app, it's the norm and is pretty easy.

------
diminish
Here'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/js with "BabyHTML" 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.

And all this repeats ad infinitum.

~~~
carapace
Everything old is new again.
[http://cva.stanford.edu/classes/cs99s/papers/myer-
sutherland...](http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-
design-of-display-processors.pdf)

~~~
hoggle
The introduction alone just made my day, thanks for sharing.

It's about time that we take history more seriously.

~~~
carapace
Cheers

------
nwienert
I hope 2015 is the year JS devs really start pushing for real async/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.

Switching to display: 'block' and it's under 100ms. I think now I'll look at
using css-layout to just spit out absolute positions.

I also appreciate the shout out in the article to reapp. I'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/main thread, which I'll be
exploring.

Long and short of it is this: We've gotten pretty damn close with the web
these days. For anything that doesn't use exceeding long lists of media-heavy
content, you can actually get 60fps with react. But you have to be _careful_.

I'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.

[0] [http://hn.reapp.io](http://hn.reapp.io)

~~~
davedx
Yup.

I'm currently working on a React-like interface over WebGL, and everything is
just "absolute positioned" \- read, it's just GL matrices all the way down. It
just works.

~~~
frik
Interesting! Can you share more about it?

~~~
davedx
I've done the very basic ground work:
[https://github.com/davedx/lustro](https://github.com/davedx/lustro)

------
janfoeh
To me, this "60fps or bust" notion that seems to have come up recently is
complete and utter nonsense. It's masturbatory technofetishism.

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 & family, I have found the vast majority of people to be tolerant
towards the inconveniences and failures of technology to the point of
defeatism.

The things people put up with sometimes boggles the mind. Eight minute boot
time to a usable desktop? _" Oh, I just tap the power button and get coffee"_.
Half a dozen browser toolbars they never installed willingly. Popovers and
popunders. Nagging Java updaters and upselling "security software". Forced
reboots that kill your unsaved changes over lunch when Windows decides to
install updates. And, and, and…

That story hasn't changed one bit on mobile. _" Well, I know know that I have
to restart my phone [for two minutes] before I can play this game, because it
crashes otherwise"_.

There's a good chance that this is the majority of people interacting with
your app, site or gadget.

If you can squeeze out silky animations and buttery scrolling out of a complex
web app, go for it. I'm the first to marvel at your ingenuity and applaud.

But if you honestly think that these people care enough about "60fps
scrolling" that it warrants reinventing pretty much the whole of HTML and CSS
in Javascript — badly —, then I don't know what to tell you.

------
fny
And beyond the performance issues, app design on the web is a massive pain.

Despite the advances with CSS3, we'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'm referring
to issues that flexbox doesn't resolve such as aligning/sizing elements
relative to each other rather than to their parents.]

On top of that, we're seriously in need of better tooling. It feels like we'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...

...and that's the whole point really, isn't it?

~~~
woah
Just use flexbox. I've recently started doing iOS dev, and I really miss the
simple, declarative, consistent web layout tools. In iOS, there's a broken
drag and drop editor that can do about 80% of what you need. You then need to
go in and call a bunch of arbitrary methods that do various things to
different UI modules, with no consistency between modules. Everything is very
ad-hoc and one-off and you don't have much choice in what to use. I will say
that all the animations are pretty smooth once you call the right combination
of weird arbitrary methods to do what you need.

What is this legendary interface system that is better than the web? I'd like
to use it.

EDIT: As for tooling, I guess it's just a difference of opinion, but I love
the fact that there is none for the web. It forces everything to actually
implement elegant and understandable API's. Too many IDE-based systems use the
IDE as a crutch allowing them to create inelegant systems that would not be
possible to use with it.

~~~
fny
I should have been more clear with the centering issue: I'm looking at
something like GSS [0] as a model of what would be incredibly useful.

As for IDEs, I've always used a text editor for web dev, but there's something
incredibly fun about being able to draw components and move them around on
your screen as opposed to having to mess around with something like the Canvas
API. I built fairly complicated little apps with Flash when I was 10 that
would take me 10x longer (at least) to implement in HTML5.

0: [http://gridstylesheets.org/](http://gridstylesheets.org/)

~~~
woah
Yes I definitely agree on GSS. Can't wait to try it!!

~~~
hiphopyo
CSS grids ([http://caniuse.com/#feat=css-grid](http://caniuse.com/#feat=css-
grid)) are on the rise too I think.

------
fidotron
This is dead right.

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.

Google and co will have to actually run web browsers in the cloud and use OCR
to do indexing if they aren't already.

~~~
ovulator
My guess is we'll come up with a sort of standard API using JSON or such that
we will make available the information and ultimately mimic what HTML does
now.

~~~
Touche
Let's use an xml-like (but not really xml) syntax instead. And we'll make it
so the browser can view this format natively (with no javascript).

------
EdSharkey
So, there is a cheap way to communicate between the DOM thread and web worker
threads. It's called Transferable Objects. The technique involves
postMessage()'ing a Typed Array's ArrayBuffer as your message payload. Rather
than making a copy of the bytes in your sending thread's Typed Array, the byte
buffer is "detached" from the sender's ArrayBuffer and "attached" 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.

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.

[http://updates.html5rocks.com/2011/12/Transferable-
Objects-L...](http://updates.html5rocks.com/2011/12/Transferable-Objects-
Lightning-Fast)

The DOM/Layout/CSS is a crufty document engine. Is it reasonable with today'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.

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().

\-- edits clarifying ArrayBuffer

~~~
vjeux
The problem with Transferable Objects is that they only work for raw buffers.
This is great for math intensive tasks such as image processing, but not that
great for UI related tasks.

We want to be able to share js objects, arrays and strings in a fast way.
Otherwise you either need to build your entire app on-top of raw buffer but
that doesn't look like JS anymore, or you've got to do a serialization step
and you're not gaining much compared to JSON serialization.

I'm super excited about immutability because it lets us share objects between
different threads very cheaply and still letting us use normal js constructs.
I'm not sure anyone is working on it though :(

------
steveklabnik
Nice to see the random Servo reference drop, it's cool to see it gain
recognition outside of Rust circles. They're doing so much cool stuff.

~~~
jlongster
I used to think Servo would just make the web a little faster, and never
understood the true impact it might have until this comment:
[https://news.ycombinator.com/item?id=9011215](https://news.ycombinator.com/item?id=9011215)
and pcwalton's response in that thread.

Servo is going to completely expose the worst parts of our current web. I'm
hopeful it will start influencing standards to expose sane APIs that make it
easier for current engines to parallelize.

~~~
pcwalton
Another neat, releated, thing we can do in Servo is to run all CSS animations
off the main thread, even ones that require reflows. I actually think that may
be one of the biggest, if not the biggest, wins of Servo's architecture…

~~~
jlongster
While that sounds really interesting, CSS animations are somewhat limited and
its hard to do gesture or physics-based animations with them. We really need
good, fast JS-based animations. Also, whatever handles touch input needs to
apply the animation in the same thread.

The React Native devs have a lot of reasons for the above, if you want more
reasoning might be good to check it out when its released soon.

Still, that sounds really cool!

------
redindian75
I wish it wasn't true - but if there is a native app available for a
website/service i wish to use - I choose native app almost all the time. Each
of these services have a 100% work website & 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't have
a feeling that I will loose my shopping cart or be logged out due to an
error/network connection etc.

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: "Do they have an iPhone app?"

~~~
imissmyjuno
I think this also speaks to the effort these companies have put into their
mobile web apps. For a while I used the web FB app because their iPhone one
was fubar.

~~~
rimantas
No, it just speaks how far behind (and the wrong origin) of the mobile web
apps tech is compared to native SDKs.

~~~
imissmyjuno
You're right, that is the only possibility ¬_¬

------
ForHackernews
The 60 fps thing is super weird to me. Do people really care if their
website/mobile app is 60 fps? Who are these people?

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).

~~~
mcmillion
Yes. Anything less than this becomes perceptible and starts to make the UX
feel janky or sluggish. That is a huge turn-off for a lot of users, even if
they can't pin down the exact cause being low framerate.

And framerate in UI is a different beast compared to video. A menu animation
running at 24fps feels much choppier and sluggish than a video running at
24fps.

~~~
teamhappy
No. The amount of fames you need depends on the distance an object moves per
frame.

I really don't want to argue about this so I figured I just let you experience
it yourself:
[http://jsbin.com/qizatugepo/1/edit?js,output](http://jsbin.com/qizatugepo/1/edit?js,output)

Frame _drops_ are a different story entirely. The swap_control_tear extension
for OpenGL takes care of that to some degree though.

~~~
MrScruff
Typically in a mobile app I'm flick scrolling at speed through lists. So the
maximum distance travelled per frame is pretty high.

~~~
teamhappy
Same here. I was trying to point out that frames per second alone isn't a
useful metric for "animation quality." Ideally, you'd want to compare the
frames per second to how many pixel something moves per second (or something
similar).

Having said that, shooting for your monitors refresh rate isn't a bad idea —
it's just that you could use those cycles (and watts) for something else. And
even worse, if your app is running at 60 fps most of the time but drops to 30
fps every now and then, then it's gonna look a lot worse than the one that
runs at 30 fps consistently.

------
digdug2k
I'm pretty skeptical of React Native, for the same reasons you'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'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't see React being good at that (maybe I'm wrong
though, I haven't dug into it).

Those problems aren't that far from the web. There's no reason you can't draw
entire pages made of canvas[top="0"][left="0"] and then measure
position/transform everything by hand. You'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. "You wrote a custom layout engine! Are you
nuts!" is not something you'll hear from Android or iOS devs.

------
dts
Layout and performance of the mobile web is a red herring in the argument of
why mobile web is losing. It's not just this. There are so many other factors
that I rarely see mentioned. Encrypted / 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.

Apps integrate with the entire rich ecosystem of the device and web apps
barely / 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.

~~~
frik
_local databases_ :

SQLite is available on Android and iOS by default, and available for WinPhone
8.

Yet, some die-hard NoSQL lovers stopped the HTML5 _Web SQL Database_ API:
[http://en.wikipedia.org/wiki/Web_SQL_Database](http://en.wikipedia.org/wiki/Web_SQL_Database)

It's still available in all WebKit based browsers incl. Android and iOS. But
famously Firefox/FirefoxOS and IE/WinPhone don't support it. The proposed
NoSQL replacement _IndexedDB_ has a complicated API and never got traction,
one has to basically use a shim library. Working with several tables and
indexes is trivial in SQL, but complicated and requires a lot of specific code
in IndexedDB (NoSQL).

There would be place for SQL as well as NoSQL in HTML5.

* The argument that WebSQL was tailored to a specific SQLite version is nonsense. SQLite supports the official SQL92 standard, as do several other SQL embedded engines like the SQL engines from MS Access, MS Outlook, MS SQL Embedded and many others. Also Firefox already ships with SQLite for its "awesome bar" and bookmark feature.

* Also the argument that it's "hard" to sync a client side database with a server side database is nonsense. But the two argument basically stopped Web SQL as HTML5 API :( The developers who voted against Web SQL were (former) employees of two big server side SQL db vendors (see the related mailing lists and blog).

Nowadays with the rise of NewSQL movement of people who burnt their fingers
with NoSQL, one can only hope someone gives some love to Web SQL.

To sum up, NoSQL has it's place and SQL has one too.

~~~
bphogan
Can't upvote this enough. If there's anyone here on the W3C, consider this an
upvote for bringing back WebSQL.

IndexedDB reminds me a lot of the Drag and Drop stuff the W3C settled on:
several different kinds of awful.

------
johnrob
Question: why didn'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.

~~~
frik
Really? If you use Windows, you should be familiar with Windows Explorer.
Since Win95 with Internet Explorer 4 desktop refresh (shipped also with Win98)
you have a trident (IE) web engine in Explorer. The side bar with the metadata
and info is DHTML in Win95(IE4), 98, ME, 2000. And a fork of trident code is
used in XP and newer. Also WinXP "Software" application to uninstall programs
is basically DHTML based. The newer control panel pages, the newer dialogs,
etc. The EU demanded that Microsoft has to document the new UI-engine, used in
IE "addons" dialog, Vista/7/8/10 Explorer bars & shell dialogs and Office
2007+, so that there no completive advantage. One has yet to find that in
MSDN.

------
cromwellian
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.

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.

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'll be forgoing the greatest values of the Web, Links and
Transparency.

We need to stop panicking over mobile native and FPS.

The idea that "60 fps is required" is a complete myth. Most triple-AAA game
titles people pay $50 for on consoles don't hit a solid 60fps, most of the
time, not even a solid 30fps -- typically frames are dropped in busy parts of
the game.

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't even 100% jank
free) is damaging.

------
throwaway41597
For performance, I agree with many here, it's not the number one priority. The
critical parts missing are:

(1) a way to install web apps that hasn't to be learned, like Mozilla's Intall
API, and unlike the bookmark to homescreen UI

(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

(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

(4) notification API: the users expect anything important your app displays,
they can be notified about, otherwise, your app seems unreliable

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, ...

Regarding image decoding, why can'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?

------
TheMagicHorsey
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 "Python Box" 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).

I know that on day one there won't be anyone on your "Python Web" 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'll see people
use it ... just like any good idea takes root in the long term.

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' desktops and
devices, but I am really surprised that we haven't seen any alternatives in
the two decades since we've figured out that Javascript/CSS/HTML really suck
for a whole class of applications.

I suppose you could say the JVM was one attempt to do this ... but the JVM was
proprietary and it wasn't properly marketed to end users.

The app box I'm talking about should be something that users feel they have to
download because it will be an infinite amount of fun.

Security is a huge problem I know. But surely we can figure out something
using containers/VMs etc. to airlock all the random code that will be
downloaded into the box by users.

~~~
aikah
There will be no support for any alternative here,it's over. Vendors will
never agree on what would be the right solution.

Furthermore. There is already a solution: bypassing the dom and using
canvas/webgl for the UI, and whatever language you want for the rest.If you
want to use Python or Java, i'm sure you'll find an implementation that
compiles to Js. The future imho is clearly C/C++ and EMSCRIPTEM with
canvas/Webgl which would allow gpu acceleration for the UI and asmjs
optimisation for the code. Which is totally ironic I must say. Using a low
level language on a "high level" plateform.

------
mstade
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.

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.

The web, for all its warts, is a wonderfully resilient system. It can break
any which way and it'll still probably mostly work. Most other systems simply
don't work that way, because it's damn difficult to build such systems. By
working within the constraints of the web, you're almost forced into it.

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'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's not be kids.

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't so broken. But we have to stop the in-fighting, zealotry
won't get us anywhere.

\---

It should also be noted that James' post while talking about the _web_ is
actually more about _rendering_ than anything. There is so much more to the
web, architectural principles that transcend platforms – such as hypermedia,
stateless message transfer, metadata. Let's not pretend rendering is the end-
all be-all that the web has to offer.

------
d0m
People keep saying "The DOM is slow", which is true, but they forgot to talk
about how "Everything else is also slow". I.e. even with React and make sure
every shouldComponentUpdate gets called, we're still getting slow performance.
We need to start using all kind of hack to make it faster. Sometimes it's
really frustrating to spend a day to make it look native while it'd take
10minutes with native android. I've been trying for years to develop cordova
apps to avoid duplicate codebases, but I feel like it's just not worth it.
It'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.

But also, to be fair, if Apple could fix their damn webview, performance would
be much much better. I've been told that they're not fixing it on purpose.

~~~
glasshead969
Apple provides a WebView API in iOS 8 with JIT enabled. Any one who uses the
new API will see same performance as Mobile Safari.

~~~
nolanl
The WKWebView is buggy/breaking enough that the Cordova team has still not
integrated it: [https://shazronatadobe.wordpress.com/2014/09/18/cordova-
ios-...](https://shazronatadobe.wordpress.com/2014/09/18/cordova-ios-and-
ios-8/)

------
bahmutov
About prediction #1 - here is micro angularjs demo showing angularjs digest
cycle running in separate worker [http://glebbahmutov.com/blog/run-angular-
digest-cycle-in-web...](http://glebbahmutov.com/blog/run-angular-digest-cycle-
in-web-worker/)

------
htilford
The DOM is to slow on mobile issue is what spawned
[http://famo.us/](http://famo.us/). They go beyond virtual DOM by creating
their own layout engine that then outputs to optimized DOM (or canvas/WebGL).

~~~
joewood1972
React also has its own implementation of the Flex layout system. Implemented
in JavaScript and C++ (for react native).

------
_greim_
There's a progression from _ignore mobile_ => _make it work on mobile_ =>
_responsive design_ => _adaptive design_ => _mobile first_. But that's not far
enough. Native mobile apps are _mobile only_ , so in order for web apps to
compete head-to-head, they need to be _mobile only_ too. That's a cultural
leap the web needs to make. "The web has failed to beat mobile because it
lacks 60 fps" seems premature until we finally figure that out. I'm not saying
all webapps should be mobile-only, just ones that truly want to compete with
native apps.

------
wedesoft
I am not a "web developer" 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?

~~~
pikzen
This is absolutely not related to the subject at hand though.

If you're talking in a general case, it's because it is actually hard. Send
the buffer to your gpu, have it execute the command, send it to your screen
which probably has a CPU of its own. Pushing a pixel is hard, and you have to
do it 60 times a second. That's also why you don't just push a pixel but the
entire screen at once. How hard it is for you depends entirely on the API.
While Direct3D/OpenGL expose all the details, others like XNA or even
Javascript's canvas do it rather painlessly.

What's really hard isn't pushing a pixel to the screen: it's doing it fast
enough (i.e. same as your screen's refresh rate ideally) so that the user
doesn't notice a visible delay. When 75% of the API is blocking AND you do
work on the UI thread (Which is absolutely insane that browser developers
haven't picked up this practice considering it's been advocated for more than
15 years on the native side of things), it's usually going to be visible.

------
robbyking
>> _The web isn 't close to competing with higher-end native apps._

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 _why are we wasting our time
with mobile web?_ "

------
lightblade
> By now it should be clear that too many users would choose a native app over
> a web app.

I, for one, don't.

Why install a 500MB Facebook app when I can get the same news feed with a 1kb
bookmark?

------
lorddoig
The point about religion is key. We _really_ need to go back to basics with
this stuff and reevaluate what exactly we're trying to achieve here from the
ground up. We simply cannot retain first-class support for 20 years of legacy
cruft _and_ make meaningful progress. So if we could start again today, what
would we want from a 'browser'? How about:

    
    
        - 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
    

I don't know about you, but none of these things scream HTML, JS, or CSS to
me. HTML is an arbitrary XML schema that's fixed and subject to
standardisation because it'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.

And I'm sorry if I'm offending your world-view here, but JavaScript is a
complete fucking mess. If you love it that's great - nothing to do with me -
but as the _only_ language on _the_ dominant end-user runtime environment?
What a sick, twisted joke. Honestly how much time has been wasted dealing with
it'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't
expect translates to hundreds if not thousands of _man-years_ shat away. I'm
not exaggerating either: shit adds up at scale (and if you don't believe me,
consider that the subset of British people who actually had reason to call the
government(?!) last year spent a cumulative _750 years_ on hold).

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's not just _mission critical_
that we get it right, it's _economy /happiness/progress-as-a-species_ 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's possible, we're just too
risk-averse to commit - but that's the short term view, in the long term
digging this hole any deeper carries significantly more danger.

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're (slowly) doing it with IPv6 because we
have little choice, let's not wait for that to happen here - let's get it done
before we're in a corner and are forced to make a tonne of half-baked
decisions in a hurry.

~~~
walterbell
_> A nice language that behaves well as a transpilation target_

Could you rank your preferences?

~~~
lorddoig
Lisp

------
zkhalique
Actually, we are building web-first. We believe we'll be able to optimize
enough locally by caching files in a bundle and intercepting requests PhoneGap
style. We've already tried it, but here's the web (non-cached) version:

[http://qbixstaging.com/Groups](http://qbixstaging.com/Groups)

Built with [http://platform.qbix.com](http://platform.qbix.com)

------
jkot
I think major problem is connectivity. Make your site work offline and with
slow connection and you are there.

500KB of javascript and CSS code is another problem

------
bceagle
I think James is on target in many ways, but I just wish it wasn't such a
bleak near term outlook for high end mobile web apps. I don't want to write my
app differently for different devices. I know that is the reality of today,
but it is an unfortunate reality.

That said, many apps don't need to push the limits and PhoneGap or a similar
solution is sufficient.

~~~
shawndumas
It would be lovely if this could get solved. Making an app that works across
platforms would be ideal. But every app needs to work smoothly and without
jank because engagement is key. Even if you don't mind it matters to more
people than anyone trying to avoid native apps likes to admit.

~~~
emodendroket
Yeah, if you have the resources. But so many native apps are a Web view with a
couple controls slapped on and extra ads that I am wary of installing anything
at this point.

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

------
shawndumas
"The DOM is slow": with all the advancement of the JS engines we'll hit a wall
if the DOM does not start improving by an order of magnitude.

Is this a fundamental problem or is this a case of JS being so bad that now
that it's faster it is exposing a need to focus on the DOM?

~~~
protonfish
I write a lot of mobile web apps and find that the DOM is blazing fast. I wish
I knew some examples of why people think that it is slow, but I have a few
guesses.

1\. Your mobile web framework is slow, not the browser DOM. Ditch your bloated
frameworks - writing JavaScript without external libraries is not rocket
science.

2\. There are deliberate pauses in the DOM. The _onclick_ event is very slow
and unresponsive. I get very fast UIs by replacing it with _ontouchstart_

3\. You are using too many animations. Smooth animations can work in mobile
web, to a degree. But honestly, if the big reason nobody wants to do mobile
web is because it doesn't support copious animations, I see that as a
positive. I'd rather have a UI that just does what it should without having to
wait through all the fanciness.

~~~
admyral
I'd love to see some examples of non-trivial apps written in pure JavaScript
which:

a) has decent browser compatibility b) is not a rat's nest of shims and
polyfills c) could be maintained by more than one person

~~~
ruricolist
Why browser compatibility? Why polyfills?

I don't understand the logic that goes from "Modern browsers with fast JS
engines make fancy web apps practical" to "let's make sure our fancy web apps
run in old browsers with slow JS engines."

~~~
admyral
The original commenter asserts the DOM feels slow because we use bloated
frameworks rather than pure JS. Sure, you certainly can use pure JS to target
a select few modern browsers, but I've yet to see a practical story on how to
build apps for the rest of the web at large this way.

Are we saying in order to go fast, we should eschew the progress we've made in
compatibility to accomplish it?

~~~
ruricolist
In some cases, yes.

If you are committed to doing everything in JS, then you have two choices:

1\. Deliver a degraded experience to modern browsers and a terrible experience
to older browsers.

2\. Deliver a good experience to modern browsers and no experience at all to
older browsers.

Depending on your business model, #1 may be the best choice. But if you're
trying to compete with native apps then #2 is the only thing that makes sense.

------
whytry
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.

------
z3t4
Once you go Canvas, you never go back!

~~~
stardrive
Hell yeah! Noticed opentype.js is merging in some of that new Path2D sass too.
Lets just use the DOM for what its good for, the slower more form based
aspects of an app. Then use canvas for what matters most and be done with it.

IMHO state is where its at. Separate state from function and feed the
component changed state and render as fast as possible. Much depends on what
you need to render too. In my case I have a ton of rules for variations, which
can be exchanged for even more variations, its its own injection solution.

Therefore I'm super happy about the dumb as nails canvas, it just does its
thing and the state does its thing, really snappy. I don't need a scenegraph
either, just a hit detection system, but hey, thats custom and thats fine.

