4 ms·

For me, it is not just that web apps feel slow. It is that they feel clunky. I can often see the UI elements being drawn one by one, the animations are rarely s

For me, it is not just that web apps feel slow. It is that they feel clunky. I can often see the UI elements being drawn one by one, the animations are rarely smooth, and the gestures (if I'm on mobile) never register as well as they do in native apps. The seams are showing. Even when native apps are slow, they can have a feeling of cohesiveness and polish that web apps lack.

potatolicious 13y ago
This really feeds into npalli's point above. Comparing native vs. web by simply comparing JS execution performance is a red herring. The average native app doesn't really do that much app logic. I'd wager you can take almost any app in the App Store, rip its non-UI code out and replace it with JavaScript equivalents, and no one would be any the wiser. We're talking about software that needs to respond in human-time. Taking a couple dozen milliseconds is not the end of the world. What is the end of the world for these apps is laggy, unresponsive UI, and that's where hybrid web apps fall apart. Users are very timing-sensitive when it comes to visual elements. When I touch a button it should visually respond immediately, within at most a few milliseconds. Most web apps can't reach this level of performance. Which leads to something from the article itself: > "many of the common, tough-to-program operations are carefully coded by top programmers who are devoting their careers to fine-tuning that operation" The problem with the web, as it pertains to UI, is that this isn't true. Take the dreaded carousel - that things needs to animate and scroll smoothly, but the code to do this isn't natively built into the platform, so everyone ends up rolling their own (or using what someone else has rolled) non-natively. And now you have shitty, laggy scrolling performance. This goes double for webapps that pretend to be native. Now they're basically reimplementing all of the platform's native UI widgets in Javascript without the benefit of the legion of native platform developers who've smoothed out all the kinks.
- talmand 13y ago
  Isn't one of the reasons that a web app won't respond immediately to a button click is because of a built-in delay on the browser level on touch devices? The one in place to allow for some time to know whether the user intended to do a touch event versus a drag event? For instance, I've made a simple tic-tac-toe app that I have on my phone through Phonegap that uses nothing but canvas for rendering. It doesn't seem to have this built-in delay and the buttons are quite responsive. I don't think your example of the carousel works because the article, I believe, was referring to the programmers that are working on the browser itself. You can't necessarily hold them responsible for performance issues derived from what other programmers are doing on the platform that may or may not be a good idea. Besides, I would imagine you could build a rather snappy carousel these days on modern browsers using CSS3 features as the bulk of the animation as they are native to the browser. You are also comparing today's Javascript endeavors to those of native developers that have already had their issues worked out, as you say. It would only be fair to wait until current Javascript issues are worked out before doing a proper comparison. It would be like saying your car is the obvious choice for the race because it outperforms my car even though I've yet to put the tires on my car. Native is the proper choice today, but who knows what tomorrow may bring?
- dk8996 13y ago
  JavaScript is single threaded you will never get a good smooth UI. Maybe in the future there could be more support for a "UI-thread" and background tasks but for now that's how it is. Android UI framework is basically a copy of Java/Swing where you have single UI thread that does all the painting and event handling. As a developer you have two basic rules for making a smooth UI 1) don't block the UI thread -- create background task for IO, heave code, ect... 2) don't call UI framework from non-UI thread.
- qznc 13y ago
  "Taking a couple dozen milliseconds is not the end of the world." In games, where you draw the whole screen for each frame, the magic number nowadays is 16ms. This gives you 60fps. For a TV-attached console, this is a good as it gets. For a PC it is just fine. Taking longer than 16ms is not the end of the world, but noticeable lag for the gamer.

potatolicious 13y ago

This really feeds into npalli's point above. Comparing native vs. web by simply comparing JS execution performance is a red herring. The average native app doesn't really do that much app logic. I'd wager you can take almost any app in the App Store, rip its non-UI code out and replace it with JavaScript equivalents, and no one would be any the wiser. We're talking about software that needs to respond in human-time. Taking a couple dozen milliseconds is not the end of the world. What is the end of the world for these apps is laggy, unresponsive UI, and that's where hybrid web apps fall apart. Users are very timing-sensitive when it comes to visual elements. When I touch a button it should visually respond immediately, within at most a few milliseconds. Most web apps can't reach this level of performance. Which leads to something from the article itself: > "many of the common, tough-to-program operations are carefully coded by top programmers who are devoting their careers to fine-tuning that operation" The problem with the web, as it pertains to UI, is that this isn't true. Take the dreaded carousel - that things needs to animate and scroll smoothly, but the code to do this isn't natively built into the platform, so everyone ends up rolling their own (or using what someone else has rolled) non-natively. And now you have shitty, laggy scrolling performance. This goes double for webapps that pretend to be native. Now they're basically reimplementing all of the platform's native UI widgets in Javascript without the benefit of the legion of native platform developers who've smoothed out all the kinks.

talmand 13y ago
Isn't one of the reasons that a web app won't respond immediately to a button click is because of a built-in delay on the browser level on touch devices? The one in place to allow for some time to know whether the user intended to do a touch event versus a drag event? For instance, I've made a simple tic-tac-toe app that I have on my phone through Phonegap that uses nothing but canvas for rendering. It doesn't seem to have this built-in delay and the buttons are quite responsive. I don't think your example of the carousel works because the article, I believe, was referring to the programmers that are working on the browser itself. You can't necessarily hold them responsible for performance issues derived from what other programmers are doing on the platform that may or may not be a good idea. Besides, I would imagine you could build a rather snappy carousel these days on modern browsers using CSS3 features as the bulk of the animation as they are native to the browser. You are also comparing today's Javascript endeavors to those of native developers that have already had their issues worked out, as you say. It would only be fair to wait until current Javascript issues are worked out before doing a proper comparison. It would be like saying your car is the obvious choice for the race because it outperforms my car even though I've yet to put the tires on my car. Native is the proper choice today, but who knows what tomorrow may bring?
dk8996 13y ago
JavaScript is single threaded you will never get a good smooth UI. Maybe in the future there could be more support for a "UI-thread" and background tasks but for now that's how it is. Android UI framework is basically a copy of Java/Swing where you have single UI thread that does all the painting and event handling. As a developer you have two basic rules for making a smooth UI 1) don't block the UI thread -- create background task for IO, heave code, ect... 2) don't call UI framework from non-UI thread.
qznc 13y ago
"Taking a couple dozen milliseconds is not the end of the world." In games, where you draw the whole screen for each frame, the magic number nowadays is 16ms. This gives you 60fps. For a TV-attached console, this is a good as it gets. For a PC it is just fine. Taking longer than 16ms is not the end of the world, but noticeable lag for the gamer.