15 ms·

Statements about the Mobile Web

273 points by bceagle 12y ago

ForHackernews 12y ago
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).
- shawndumas 12y ago
  Anything that maximises engagement increases impact/growth/revenue. When apps are joy-inducing people engage with them more. Jank works against joy.
- danabramov 12y ago
  >The only place I could possibly imagine that mattering is for fast-twitch video games, or theoretically videos It's about scrolling and animations. In videos it 24fps is enough because you have motion blur. In fact higher frame rate makes videos seem unnatural.. >Do people really care if their website/mobile app is 60 fps? Who are these people? People who prefer native apps to webapps. Quite a lot of them actually.
- mcmillion 12y ago
  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 12y ago
    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 12y ago
      Typically in a mobile app I'm flick scrolling at speed through lists. So the maximum distance travelled per frame is pretty high.
      - teamhappy 12y ago
        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.
- untog 12y ago
  60fps is more of a label than a measurement. Not 60fps, but "60fps", which translates to "as fast as native app transitions".
- mbrubeck 12y ago
  When you're manipulating things with a mouse and keyboard, maybe not. When you're directly scrolling/dragging/pressing things with your fingers on a touch screen, jank and latency and frame rate make a huge difference in how you perceive the device's response to your actions.
- jwmerrill 12y ago
  If you could run at a perfectly consistent 24 fps, that would probably often be okay. But the typical failure mode is not running at a perfectly consistent lower frame rate; instead, it's variable length pauses with the tail of them being painfully long.
- d0m 12y ago
  Valid question, not sure why you are getting down-voted. It's mostly related to the animations. I.e. scrolling, dragging. This is what makes the experience amazing. But also, it's because every time you do a costly operation, ti freezes the screen and the user loses control. This is a solved problems in so many environment, frustrating that it's not there yet while developing cordova apps.
shawndumas 12y ago
"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?
- kevincennis 12y ago
  It depends entirely on what your app does – but yes, I'd paint this as a fundamental problem for any app that needs to render a large amount of content (and keep it updated).
- danabramov 12y ago
  >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 We already hit that wall a long time ago. DOM is the bottleneck in any non-trivial app (unless your app mines bitcoins or something).
  - shawndumas 12y ago
    Agreed! Further, things like DOM diffing help but are an optimisation and can only take us so far. The answer is in the layout engine, no?
- untog 12y ago
  I don't know how fundamental the problem is in terms of fixing it, but it is fundamental in making mobile webapps. I remember making an auto-complete friend selector a while ago (the kind that filters as you type) - I had the JS filtering through names in less than 10ms, but the resulting DOM updates immediately brought every keypress to around 400ms, which is visibly slow, and worse, laggy. I started work on a canvas-powered alternative before giving up - but I'm glad to see the React Canvas has gone with it. When I have some free time I'll be playing around with it to see if it lives up to the hype.
- protonfish 12y ago
  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.
bceagle 12y ago
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 12y ago
  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 12y ago
    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.
fidotron 12y ago
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.
- MarcScott 12y ago
  This actually made me giggle. What a ridiculously backward situation we find ourselves in.
- ovulator 12y ago
  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 12y ago
    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).
- woah 12y ago
  Maybe Google could write a performant DOM in Chrome before it is too late?
  - nostrademons 12y ago
    See Project Ganesh, demoed at the Chrome summit late last year and apparently in Chrome 41: http://www.androidpolice.com/2014/11/19/project-ganesh-demoed-at-chrome-dev-summit-makes-chromes-page-rendering-a-lot-faster-by-working-directly-on-the-gpu/ http://www.androidpolice.com/2014/11/19/project-ganesh-demoe...
htilford 12y ago
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 12y ago
  React also has its own implementation of the Flex layout system. Implemented in JavaScript and C++ (for react native).
- woah 12y ago
  I built an app when that first came out, and it was literally insane. Not in a good way. 100 lines of code to make a 'view' (their version of a div).
steveklabnik 12y ago
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 12y ago
  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.
  - steveklabnik 12y ago
    Yes, it's true, it's already had a positive impact in this regard. I can't remember the exact CSS tweak that happened, but it's already done that one time.
  - pcwalton 12y ago
    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 12y ago
      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!
wedesoft 12y ago
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 12y ago
  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.
- acak 12y ago
  I'm not sure why you were downvoted but it's possible that your question was too basic from the point of view of a web developer. To answer your question: one reason is that the developer needs to express how elements on a page place themselves not just on the screen but with respect to other elements as well. As you can guess, calculating this "layout" will occur pretty often, and if you have only one thread running all your code, then your logic and communication with the server can interfere with the rendering of the UI - thus making the response choppy. On native apps, though some of them have borrowed web-type expressions of placement or layout, the entire calculation runs on a dedicated thread. Not on the same thread that also needs to respond to touch / slide / drag events! HTH.
jkot 12y ago
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
nwienert 12y ago
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
- taylorbuley 12y ago
  You perhaps won't be surprised that using layers/absolute positions ends up being faster with Canvas rendering too. Frame by frame is not so much layout calc and mostly painting and composition. I'm now using React and the Flux pattern to use a single source of truth to drive all absolute position math. I very much like the model's performance.
- davedx 12y ago
  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 12y ago
    Interesting! Can you share more about it?
diminish 12y ago
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.
- deleted 12y ago
  [deleted]
- woah 12y ago
  I C what U did there!!! EDIT: LOLOLOL
  - woah 12y ago
    Why the downvotes? This comment is of a similar intellectual caliber as its parent.
- carapace 12y ago
  Everything old is new again. http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...
  - agumonkey 12y ago
    Exactly. Which aims at organizing better and teaching better. I loved the fact that early display engines were memory deprived to the point where most of the logic was lazy and streamed. Framebuffers allowed progress but also regress. History rotations.
  - 12y ago
d0m 12y ago
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 12y ago
  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 12y ago
    The WKWebView is buggy/breaking enough that the Cordova team has still not integrated it: https://shazronatadobe.wordpress.com/2014/09/18/cordova-ios-and-ios-8/ https://shazronatadobe.wordpress.com/2014/09/18/cordova-ios-...
deleted 12y ago
[deleted]
whytry 12y ago
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.
fny 12y ago
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 12y ago
  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.
  - Animats 12y ago
    Flexbox: "The specification describes a CSS box model optimized for user interface design. In the flex layout model, the children of a flex container can be laid out in any direction, and can “flex” their sizes, either growing to fill unused space or shrinking to avoid overflowing the parent. Both horizontal and vertical alignment of the children can be easily manipulated. Nesting of these boxes (horizontal inside vertical, or vertical inside horizontal) can be used to build layouts in two dimensions." They just re-invented HTML tables. The replacement of HTML tables for layout with "float" and "clear" was a disaster. It replaced a 2D model with a 1D model. There were years of Javascript hacks to deal with that. Now, the 2D model of tables is back, but with a new name, because the cool kids won't use tables.
bahmutov 12y ago
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-worker/ http://glebbahmutov.com/blog/run-angular-digest-cycle-in-web...
TheMagicHorsey 12y ago
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.
- Kalium 12y ago
  Please don't try to handwave away security like that. It's much, much harder than it sounds and there still aren't great solutions to safe sandboxing. That said, what you're describing is native applications.
- aikah 12y ago
  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.
- 12y ago
digdug2k 12y ago
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.
underbluewaters 12y ago
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_comscore_study_shows_that_most_people_download_zero_new_apps_per_month.html http://www.slate.com/blogs/future_tense/2014/08/25/a_comscor... 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.
- Scarbutt 12y ago
  If only all web apps where as simple as providing food recipes.
  - underbluewaters 12y ago
    Very true. For some apps native is the only solution. I'd wager most apps are on that same order of complexity though. For example, I don't think Flipboard's use of Canvas to wrap content with fancy animations and magazine-style layout is really a damning indictment of the web platform. It's a failure to understand the medium on their part. We've got a mature, interoperable, write once run anywhere platform that's completely free to participate in. It has some critical deficiencies I'd like to see fixed rather than abandoned.
- forrestthewoods 12y ago
  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.
z3t4 12y ago
Once you go Canvas, you never go back!
- stardrive 12y ago
  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.
EdSharkey 12y ago
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-Lightning-Fast http://updates.html5rocks.com/2011/12/Transferable-Objects-L... 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 12y ago
  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 :(
johnrob 12y ago
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.
- jlongster 12y ago
  I think its because the bar for native apps wasn't that high back then. Also the interactions required for desktop apps are much simpler than mobile apps, where gestures are key part of interactions. Gesture-based animations is actually part of using the app, instead of on desktop where they just make things look pretty.
- frik 12y ago
  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.
- apetrovic 12y ago
  My guess: 1) Microsoft made Windows too damn fragile. Installing the app means that setup.exe will write all over the hard drive, and uninstall was never easy. Web didn't required install/uninstall. 2) Windows programs, with a few notable exceptions, were/are butt ugly. Web started as an ugly abomination, but designers catched up quickly. Web applications, even then, on slow connections, often provided more pleasant experience. Web app on mobile today doesn't have the same luxury - native app install/uninstall is painless; native applications are better integrated and most of the time handle unstable connections better; good native apps are beautiful and often have superior usability compared to web apps.
- Iftheshoefits 12y ago
janfoeh 12y ago
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.
deleted 12y ago
[deleted]
lorddoig 12y ago
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.
dts 12y ago
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 12y ago
  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.
mstade 12y ago
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.
robbyking 12y ago
>> 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?"
redindian75 12y ago
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 12y ago
  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 12y ago
    No, it just speaks how far behind (and the wrong origin) of the mobile web apps tech is compared to native SDKs.
    - imissmyjuno 12y ago
      You're right, that is the only possibility ¬_¬
_greim_ 12y ago
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.
cromwellian 12y ago
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.
lightblade 12y ago
> 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?
tomelders 12y ago
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.
throwaway41597 12y ago
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?
zkhalique 12y ago
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

273 points by bceagle 12y ago

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

shawndumas 12y ago
Anything that maximises engagement increases impact/growth/revenue. When apps are joy-inducing people engage with them more. Jank works against joy.
danabramov 12y ago
>The only place I could possibly imagine that mattering is for fast-twitch video games, or theoretically videos It's about scrolling and animations. In videos it 24fps is enough because you have motion blur. In fact higher frame rate makes videos seem unnatural.. >Do people really care if their website/mobile app is 60 fps? Who are these people? People who prefer native apps to webapps. Quite a lot of them actually.
mcmillion 12y ago
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 12y ago
  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 12y ago
    Typically in a mobile app I'm flick scrolling at speed through lists. So the maximum distance travelled per frame is pretty high.
    - teamhappy 12y ago
      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.
untog 12y ago
60fps is more of a label than a measurement. Not 60fps, but "60fps", which translates to "as fast as native app transitions".
mbrubeck 12y ago
When you're manipulating things with a mouse and keyboard, maybe not. When you're directly scrolling/dragging/pressing things with your fingers on a touch screen, jank and latency and frame rate make a huge difference in how you perceive the device's response to your actions.
jwmerrill 12y ago
If you could run at a perfectly consistent 24 fps, that would probably often be okay. But the typical failure mode is not running at a perfectly consistent lower frame rate; instead, it's variable length pauses with the tail of them being painfully long.
d0m 12y ago
Valid question, not sure why you are getting down-voted. It's mostly related to the animations. I.e. scrolling, dragging. This is what makes the experience amazing. But also, it's because every time you do a costly operation, ti freezes the screen and the user loses control. This is a solved problems in so many environment, frustrating that it's not there yet while developing cordova apps.

shawndumas 12y ago

"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?

kevincennis 12y ago
It depends entirely on what your app does – but yes, I'd paint this as a fundamental problem for any app that needs to render a large amount of content (and keep it updated).
danabramov 12y ago
>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 We already hit that wall a long time ago. DOM is the bottleneck in any non-trivial app (unless your app mines bitcoins or something).
- shawndumas 12y ago
  Agreed! Further, things like DOM diffing help but are an optimisation and can only take us so far. The answer is in the layout engine, no?
untog 12y ago
I don't know how fundamental the problem is in terms of fixing it, but it is fundamental in making mobile webapps. I remember making an auto-complete friend selector a while ago (the kind that filters as you type) - I had the JS filtering through names in less than 10ms, but the resulting DOM updates immediately brought every keypress to around 400ms, which is visibly slow, and worse, laggy. I started work on a canvas-powered alternative before giving up - but I'm glad to see the React Canvas has gone with it. When I have some free time I'll be playing around with it to see if it lives up to the hype.
protonfish 12y ago
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.

bceagle 12y ago

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 12y ago
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 12y ago
  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.

fidotron 12y ago

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.

MarcScott 12y ago
This actually made me giggle. What a ridiculously backward situation we find ourselves in.
ovulator 12y ago
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 12y ago
  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).
woah 12y ago
Maybe Google could write a performant DOM in Chrome before it is too late?
- nostrademons 12y ago
  See Project Ganesh, demoed at the Chrome summit late last year and apparently in Chrome 41: http://www.androidpolice.com/2014/11/19/project-ganesh-demoed-at-chrome-dev-summit-makes-chromes-page-rendering-a-lot-faster-by-working-directly-on-the-gpu/ http://www.androidpolice.com/2014/11/19/project-ganesh-demoe...

htilford 12y ago

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 12y ago
React also has its own implementation of the Flex layout system. Implemented in JavaScript and C++ (for react native).
woah 12y ago
I built an app when that first came out, and it was literally insane. Not in a good way. 100 lines of code to make a 'view' (their version of a div).

steveklabnik 12y ago

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 12y ago
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.
- steveklabnik 12y ago
  Yes, it's true, it's already had a positive impact in this regard. I can't remember the exact CSS tweak that happened, but it's already done that one time.
- pcwalton 12y ago
  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 12y ago
    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!

wedesoft 12y ago

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 12y ago
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.
acak 12y ago
I'm not sure why you were downvoted but it's possible that your question was too basic from the point of view of a web developer. To answer your question: one reason is that the developer needs to express how elements on a page place themselves not just on the screen but with respect to other elements as well. As you can guess, calculating this "layout" will occur pretty often, and if you have only one thread running all your code, then your logic and communication with the server can interfere with the rendering of the UI - thus making the response choppy. On native apps, though some of them have borrowed web-type expressions of placement or layout, the entire calculation runs on a dedicated thread. Not on the same thread that also needs to respond to touch / slide / drag events! HTH.

jkot 12y ago

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

nwienert 12y ago

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

taylorbuley 12y ago
You perhaps won't be surprised that using layers/absolute positions ends up being faster with Canvas rendering too. Frame by frame is not so much layout calc and mostly painting and composition. I'm now using React and the Flux pattern to use a single source of truth to drive all absolute position math. I very much like the model's performance.
davedx 12y ago
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 12y ago
  Interesting! Can you share more about it?

diminish 12y ago

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.

deleted 12y ago
[deleted]
woah 12y ago
I C what U did there!!! EDIT: LOLOLOL
- woah 12y ago
  Why the downvotes? This comment is of a similar intellectual caliber as its parent.
carapace 12y ago
Everything old is new again. http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...
- agumonkey 12y ago
  Exactly. Which aims at organizing better and teaching better. I loved the fact that early display engines were memory deprived to the point where most of the logic was lazy and streamed. Framebuffers allowed progress but also regress. History rotations.
- 12y ago

d0m 12y ago

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 12y ago
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 12y ago
  The WKWebView is buggy/breaking enough that the Cordova team has still not integrated it: https://shazronatadobe.wordpress.com/2014/09/18/cordova-ios-and-ios-8/ https://shazronatadobe.wordpress.com/2014/09/18/cordova-ios-...

deleted 12y ago

[deleted]

whytry 12y ago

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.

fny 12y ago

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 12y ago
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.
- Animats 12y ago
  Flexbox: "The specification describes a CSS box model optimized for user interface design. In the flex layout model, the children of a flex container can be laid out in any direction, and can “flex” their sizes, either growing to fill unused space or shrinking to avoid overflowing the parent. Both horizontal and vertical alignment of the children can be easily manipulated. Nesting of these boxes (horizontal inside vertical, or vertical inside horizontal) can be used to build layouts in two dimensions." They just re-invented HTML tables. The replacement of HTML tables for layout with "float" and "clear" was a disaster. It replaced a 2D model with a 1D model. There were years of Javascript hacks to deal with that. Now, the 2D model of tables is back, but with a new name, because the cool kids won't use tables.

bahmutov 12y ago

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-worker/ http://glebbahmutov.com/blog/run-angular-digest-cycle-in-web...

TheMagicHorsey 12y ago

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.

Kalium 12y ago
Please don't try to handwave away security like that. It's much, much harder than it sounds and there still aren't great solutions to safe sandboxing. That said, what you're describing is native applications.
aikah 12y ago
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.
12y ago

digdug2k 12y ago

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.

underbluewaters 12y ago

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_comscore_study_shows_that_most_people_download_zero_new_apps_per_month.html http://www.slate.com/blogs/future_tense/2014/08/25/a_comscor... 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.

Scarbutt 12y ago
If only all web apps where as simple as providing food recipes.
- underbluewaters 12y ago
  Very true. For some apps native is the only solution. I'd wager most apps are on that same order of complexity though. For example, I don't think Flipboard's use of Canvas to wrap content with fancy animations and magazine-style layout is really a damning indictment of the web platform. It's a failure to understand the medium on their part. We've got a mature, interoperable, write once run anywhere platform that's completely free to participate in. It has some critical deficiencies I'd like to see fixed rather than abandoned.
forrestthewoods 12y ago
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.

z3t4 12y ago

Once you go Canvas, you never go back!

stardrive 12y ago
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.

EdSharkey 12y ago

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-Lightning-Fast http://updates.html5rocks.com/2011/12/Transferable-Objects-L... 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 12y ago
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 :(

johnrob 12y ago

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.

jlongster 12y ago
I think its because the bar for native apps wasn't that high back then. Also the interactions required for desktop apps are much simpler than mobile apps, where gestures are key part of interactions. Gesture-based animations is actually part of using the app, instead of on desktop where they just make things look pretty.
frik 12y ago
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.
apetrovic 12y ago
My guess: 1) Microsoft made Windows too damn fragile. Installing the app means that setup.exe will write all over the hard drive, and uninstall was never easy. Web didn't required install/uninstall. 2) Windows programs, with a few notable exceptions, were/are butt ugly. Web started as an ugly abomination, but designers catched up quickly. Web applications, even then, on slow connections, often provided more pleasant experience. Web app on mobile today doesn't have the same luxury - native app install/uninstall is painless; native applications are better integrated and most of the time handle unstable connections better; good native apps are beautiful and often have superior usability compared to web apps.
Iftheshoefits 12y ago

janfoeh 12y ago

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.

deleted 12y ago

[deleted]

lorddoig 12y ago

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.

dts 12y ago

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 12y ago
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.

mstade 12y ago

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.

robbyking 12y ago

>> 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?"

redindian75 12y ago

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 12y ago
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 12y ago
  No, it just speaks how far behind (and the wrong origin) of the mobile web apps tech is compared to native SDKs.
  - imissmyjuno 12y ago
    You're right, that is the only possibility ¬_¬

_greim_ 12y ago

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.

cromwellian 12y ago

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.

lightblade 12y ago

> 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?

tomelders 12y ago

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.

throwaway41597 12y ago

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?

zkhalique 12y ago

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