> They said that users really wanted native desktop like seamless change pages.
This perhaps roots in the behaviour of browsers ten and more years past. Back in the day, you'd often get a "flash of white" during page loads. Today, not any more. A full-reload and a "seven million lines of JS client-side renderer" application are virtually indistinguishable. Chances are that the "full-reload" app is faster.
> On the desktop the network is the bottleneck, not the rendering.
That's pretty oversimplified. For lots of workloads—e.g. interacting with widgets on the page, composing emails/etc, scrolling, opening pop-out menus, interacting with Google Maps—the rendering (broadly speaking) is the bottleneck.
In fact, I'm of the opinion that improving layout and graphics performance is the single biggest thing we can do to make Web apps not feel slow compared to their native counterparts. People still (often quite rightly) feel that the Web is slower than native (however "native" is defined). The difference is unlikely to be network-related, and it's unlikely to be JavaScript either for most apps—JS performance may not be at C++-level yet (though asm.js will get there in time), but it's certainly on par with Objective-C and Java/Dalvik. The problem is mostly styling, layout, and graphics in my view: how to get from the DOM to rendered pixels as quickly as possible. Those are, not coincidentally, what Servo has focused on.
>> We often engage in debates about whether Javascript/the web stack is fast enough to use for various types of software. Performance improvements are treated as an inevitability; "if it isn't fast enough today it will be tomorrow". Similar attitudes hold for missing APIs and functionality. Most people don't seem to really question what it really means for browsers to become more and more performant and more and more complex. The answer seems to be millions of lines of very complicated and low level C++.
Ironically, not needing to run high performance native code was a part of the original appeal of web apps. Google maps worked well however old your graphics card was. Gmail was secure even when viewed on an old version of IE.
If client side rendering is too slow, then don't render on the client. Cache the rasterized pdf as tiles up in the cloud and only read the actual document if the user selects text or zoom in. That is the only way to make massive pdf's load instantly on a slow machine.
> I'm curious where the majority of the win came from?
Great question! The boost can be explained by JS vs. raw HTML+CSS performance.
In the past, we sent a dummy loading screen but we then had to download tons of JS + run that to even show a "real" loading screen (i.e. page-specific loading screen).
Now, the HTML response (which you can inspect yourself, `curl https://my.causal.app`) already has a skeleton of the page, which doesn't need any JS to download and run before showing the "real" loading screen.
The UX is better because users spend noticeably less time staring at a blank screen and there's much less layout shift too!
They don't feel slow, they are slow, even more so on mobile, but developers have stopped caring about mobile web performance a long time ago. So much for "flash is killing my battery", now it's Javascript.
That's because people think it's a great idea to include 10MB of different javascript frameworks that cause the page to rerender itself 15 times as each component loads.
That said, the modern browser isn't slower itself. If you load a page from 10 years ago in edge/chrome it will render almost instantly in most cases.
> Really? Look at Linode, Amazon, or even Google (including GMail, and probably others). All of which are big names that can and do work ENTIRELY without JavaScript.
I think we can all agree, maintaining two discrete code-bases is a sub-optimal experience. Especially for companies without the resource of the "big names" you point out.
> Another (AJAX) HTTP request + rendering the returned data on a tiny mobile phone is faster than one HTTP request for the entire webpage and having dedicated machinery pre-render the content for you? I don't think so. He does talk about this point later on, but which is it? Client-rendered JS apps are, or aren't fast?
Several reason why this experience results in a faster mobile experience.
- cached data serves extremely quickly ;)
- pre-emptively loading data to prime the cache.
- data is smaller then data + html.
- the app remains usable during loading phases.
Additionally, separating the concerns of rendering and data loading, does afford more creative optimizations as the need arises.
> they're fundamentally referring to the underlying engine that makes those apps slow. If that engine was fast and light on resources, the complaint wouldn't exist.
Firstly: in that case you'd have to compare it to the weight of the entire desktop environment. I would bet money that Gnome + your GTK app is not meaningfully lighter-weight than Chrome + an Electron app. It's just that the former has a privileged place in the OS, and is a dynamically-linked dependency instead of a statically-linked one (using those terms loosely).
Secondly: The web itself is not fundamentally slow. People who aren't web developers love to repeat this mantra, but it's simply not true. That's what I'm trying to get to the heart of here:
1) JavaScript is slower than C++, but it's very rare that enough actual work is being done in JavaScript for it to become a bottleneck (on the UI side), even in complex web-apps. Most of the grunt-work, including recalculating layout, is implemented in C++ as part of the browser.
2) Layout calculation can be slow-ish in extreme cases, but that's a direct tradeoff for the benefit of using the world's most advanced UI layout system, which provides real value.
3) Under normal circumstances an entire web page runs in a single thread, which can be a problem when the occasional expensive operation blocks other ones, but Electron gives you several options for moving expensive operations to separate threads. By default the web view runs in a separate thread from the "main" process, and you can spin up workers or even split your UI into separate web views so each panel gets its own thread.
I think the origins of this myth are:
1) Websites have become much slower than they need to be with the increase in JavaScript dependencies. 90% of this is due to ads and analytics, which couldn't care less about their impact on page performance. The rest has mostly to do with the initial load-time of that 1-2MB script, rather than the runtime of the actual JS code.
2) As with any technology that lowers the barriers to making things, there's been a dilution of less-skilled developers putting things out into the world, decreasing the overall perceived quality of the space. But this isn't an indictment of the technology; if anything, it's a complement. It has to be distinguished from the actual merits of the tech.
> but by using Chromium everywhere, developers don't have to deal with cross-browser issues
I think it has more to do with being able to build and ship copies for all systems through a single channel. Building a "first-class" Mac app (a dock icon, hooks into system APIs, etc.) that uses Safari's web view right now would probably mean opening XCode and writing quite a bit of actual Swift as a wrapper around the web UI. People don't want to do that; it defeats a lot of the purpose. My proposal in my last comment would solve this problem.
Saying JS improves the experience in terms of speed is too general. Doing async requests can result in faster interactions than whole page reloads, but big JS blobs that offload work to the client can make initial page load take forever on small pipes and can make weak CPUs struggle under the weight. More CPU utilization also drains battery, which does harm UX. Ignoring low bandwidth and underpowered hardware is fine for some products, but a common mistake with many others. People with slow internet and cheap devices are people too, ya know?
Yes, so it's pointless for the author to say that a problem with Web Apps is that they're slower than native apps. It's redundant now days and a well designed web app using modern techniques should not feel any slower to an end user than a desktop app, in fact with the advanced rendering engines within modern web browsers they can feel more responsive and more usable than native.
> Sites with minimal or no javascript are faster than sites with lots of javascript.
Though experiment: Simple todo app. Would this be faster if, upon every interaction with the UI, the whole form was sent to the server to recalculate a new DOM to send back to the browser to download + re-render? It certainly seems like e.g. adding a row to a DataTable would be what most users would call "faster".
Also, consider how this app scales. Requiring that the server re-build a page for every user interaction is a lot more work for the server vs. sending a big blob of HTML + assets once (CDNJS and similar services also affect how this performs). Given how powerful even a low-end few-year-old smartphone in the US is these days, I doubt that it would be a better experience to make an app like todo rely on server-side processing.
I do agree that javascript isn't /always/ the right tool, but building a few smaller API back-end + JS app front-end things lately been pretty convincing for me that JS + AJAX + REST API is a better UX for lots of things vs submit-and-rebuild. Clicking a radio button or selecting something in a drop-down and having the page refresh as a result feels pretty lame in 2014.
EDIT: note that I was a pretty dedicated NoScript user for a few years, a few years ago. These days, Privoxy running a few AB+ lists filters out almost all of the junk that annoys me (I found the performance of AB+ to be unacceptable with dozens of tabs open at once).
> The browser executes programs in a totally platform-independent way
JS has different scripting engines and different dialects, so it isn't really platform independent in the sense that the same code will execute the same way on every computer. In fact, it's possible for JS to execute in different ways on the same computer when you run the code on browsers with different engines. There are plenty of instances were a page will not render the same way in different browsers (although this is usually because HTML use isn't consistent).
> That "half speed" number was the status as of a few months ago, and is still improving.
It's still an effort to reinvent the wheel. When a 1:1 ratio is reached, you (not you in particular) will still have ended up spending time implementing a feature that already exists on your OS, instead of improving the original program. For example, browsers have pdf readers baked in. Now you have a dedicated pdf reader on the desktop, and a slower, buggier pdf reader on the browser.
The problem is that programs on the desktop don't communicate well with each other to get the same kind of integration you get on a browser, or the underlying OS doesn't include programs to implement features that you want to include on your web page. I understand that it may be simpler to turn a web browser into a mini OS rather than get OS authors to change their OS (the Chromebook is a misguided attempt to take this to its logical end), but it is still an ugly and redundant solution.
That's not true at all, browser used to be much faster when HTML was simpler.
> ...but web sites are bloatier than ever before, eating up all the hardware and software capabilities.
Actually, even a rather simple website can very slow to render, if it does a significant amount of dynamic updates. DOM performance is an absolute disaster, hence all these "virtual dom" implementations like React. CSS Layouting is incredibly expensive. That has nothing to do with website bloat in and of itself, it's the platform coming bloated out of the box.
They'd declare that the JS engine was just as fast (or faster) - but that didn't cover the whole of the UI, and laggy bits of the UI could slow things down no matter how fast the JS engine was.
Thankfully they now seem to have improved the whole UI.
"If someone doesn't have JavaScript, he's either extremely paranoid (and belongs to a really minor minority) or using hopelessly outdated browser (a minority that most likely wouldn't be a good customer anyway)."
With the trend towards mobile devices (as in not chained to a desk) this introduces far more complexity to whether client-side rendering is viable than whether "javascript is turned on in the browser". (Here's some notes I made about that a few months ago: http://isolani.co.uk/blog/javascript/DisablingJavaScriptAski... )
The mobile trend also blows a big hole in the article itself: The CPU power of mobile devices is quite well behind that of a laptop or desktop. Probably about 2 or three generations behind. So the perceived performance will still lags behind.
Again? Single page apps refresh and respond faster than their HTML counterparts. Sounds like a mad backend dev posting hate for the evolving front-end world because they don't want to learn new stuff.
This perhaps roots in the behaviour of browsers ten and more years past. Back in the day, you'd often get a "flash of white" during page loads. Today, not any more. A full-reload and a "seven million lines of JS client-side renderer" application are virtually indistinguishable. Chances are that the "full-reload" app is faster.
reply