16 ms·

JavaScript Conquered the Web, Now It’s Taking Over the Desktop

172 points by nreece 10y ago

rplst8 10y ago
I'm not an expert, but the memory required to render the seemingly simplest of interfaces in html/js/css in a browser today seems excessive. Some web sites bring a reasonably powered desktop to its knees. I'm not sure I want this problem on my desktop too. Though I guess this is just one step closer to having METAL. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- dismantlethesun 10y ago
  It is pretty excessive, but maybe web assembly would find a real home in making applications that do well on both native and web.
  - n00b101 10y ago
    WebAssembly will hopefully end JavaScript's stranglehold on the web. The justification for using JavaScript for server/desktop/mobile applications seems to essentially be that a certain large group of programmers only know JavaScript.
    - gjolund 10y ago
      Agreed, Im so tired of being forced to write js.
    - contextfree 10y ago
      I'm not sure. All the browser APIs will still use the JS object model. If we look at the situation on the JVM or CLR, it seems like languages specifically designed for those object models (even if adapted from other languages) have been more successful than attempts to directly port existing languages. e.g., Scala, Clojure, F# or Powershell vs. Jython, JRuby, C++/CLI or IronPython. My bet would be that languages specifically designed for the JS ecosystem (whether JS itself or something like CoffeeScript or TypeScript) will continue to be the most popular for writing most of an app, with some apps dropping down to C or C++ or Rust compiled to wasm for a subset of performance-critical code.
      - vidarh 10y ago
        I'm sure there'll be a mix. But consider things like Opal (Ruby => javascript), and it seems like there's at least some people who very much want to be able to work in a single language, but for that language to not be javascript... I'm sure once webassembly is ready, that'll at least get more popular.
    - Udik 10y ago
      I guess you tend to reuse the technologies you're familiar with, especially when they are very well proven for solving a very complicated problem that requires a lot of expertise (I'm talking about fancy UIs, of course). Which is also why I think the emphasis on JS is wrong: the main selling point of these technologies is NOT javascript, is HTML5/ CSS. Javascript is just a (very handy indeed) scripting language like any other: frankly the logic and requirements of most applications around are not complex enough to justify the usage of anything more solid or complicated than that. Just today I was contacted by a former colleague, a Java developer, asking advice on using Electron to develop a quick desktop application. On the other hand, there is a long list of languages that transpile to javascript. So where are the masses of serious C#/ Java/ <pick-your-language> developers using transpilers to write the logic of their web applications?
      - n00b101 10y ago
        So where are the masses of serious C#/ Java/ <pick-your-language> developers using transpilers to write the logic of their web applications? I think it is catching on with C++ game developers, who want to be able to run the same codebase natively or in the web browser. The Unity 3D game engine has built-in support for this using WebGL, for example. I don't know if CLR or JVM languages have been successfully transpiled to the browser using asm.js / WebAssembly (it wouldn't be very efficient at all, so I doubt that will ever be popular).
- raquo 10y ago
  No one likes that, but 1) HTML/CSS/JS is sill the only truly cross-platform (mac/windows/linux/web/ios/android/etc.) UI platform/ecosystem in 2016, and it will probably stay that way in the foreseeable future because OS makers love their walled gardens. 2) An app's memory efficiency is not a top 10 priority of an average solo-or-small-team developer's concerns, because that's not what most users pay for. Electron/NW.js apps will only become more common, so I hope things will improve with asm.js/webassembly/etc.
  - fdgdasfadsf 10y ago
    On point (1) you've kind of loaded the comparison by including web in that list...
    - raquo 10y ago
      It's a common business scenario: start out as a web app, then as business picks up let's start providing native apps. Or the other way: start out with a native app on the platform we most care about + a web app for "access from anywhere".
  - gr3yh47 10y ago
    Python would like a word with you about point 1)
    - corv 10y ago
      Python on iOS?
      - nodja 10y ago
        It's not pretty but: https://kivy.org/docs/guide/packaging-ios.html https://kivy.org/docs/guide/packaging-ios.html
        corv 10y ago
        Interesting
- catnaroek 10y ago
  Too much wishful thinking during the second half of the talk, though. Also, while fancy runtime systems can improve the performance of dynamic[0] languages, it doesn't come for free: the price to be paid is the loss of elegance. For instance, a JIT compiler could inline a virtual method that seems not to be overridden anywhere, but if later on it turns out that the virtual method was overridden somewhere, the “optimization” has to be undone. How can anyone in their right mind trust a language that requires such dirty implementation tricks to achieve decent performance? [0] By which I mean “less amenable to static analysis”, regardless of whether the language has a static type system. For instance, Java and C# are dynamic languages in this sense.
  - smallnamespace 10y ago
    > How can anyone in their right mind trust a language that requires such dirty implementation tricks to achieve decent performance? Isn't this a rather broad brush with which to paint all JIT language implementations, including Java, C#, and, say, PyPy?
    - catnaroek 10y ago
      Could you name a JIT compiler that doesn't do this kind of thing, yet offers performance comparable to AOT-compiled languages? (FWIW, I'm not saying it's impossible. It's perfectly possible, but you'd need a source language that offers much better static guarantees than the typical language that a JIT compiler is written for.) --- Sorry, can't reply to you directly, because “I'm submitting too fast”. So my reply goes here: > for the simple reason that type systems cannot capture all relevant runtime context. Type checking isn't the only kind of static analysis out there. And there's no need to use statistics to optimize anything at runtime when your ahead-of-time compilation step already emits optimal target machine code. > Java is a good example here, since it's strongly statically typed. Java is as dynamically typed as it gets: `instanceof`, downcasts and reflection, all conspire to reduce the usefulness of static type information to zero. > By your reckoning, all greedy optimizations that CPUs do like branch prediction and prefetching are also similarly 'inelegant', because they can be wrong and require rolling back. Yes, indeed. It's more elegant to know beforehand what exactly you have to do, and then do just that and nothing else.
- wpietri 10y ago
  I feel your pain. My first computer had 4K of RAM; my second had 48K; my third, 640K. I learned to work small. It pains me to see the equivalent of Hello World taking up untold MB. But when I think about software as a business rather than an art, I have to concede that it's a very rare circumstance where RAM efficiency matters as much as I'd like. Note the way the cost of memory has declined: http://www.jcmit.com/mem2015.htm http://www.jcmit.com/mem2015.htm Watches now have 100,000 times the RAM that I started with. Costs are dropping by 1-2 orders of magnitude per decade. Something that is absurdly wasteful now could well be economically reasonable very soon.
  - vidarh 10y ago
    Memory isn't the issue to me. Latency is. Most of the applications I work with today do a lot, that's true, but their UI latency is often worse than it was on my 7.16Mz M68000 Amiga 500, and other things as well are just slow. I've mentioned here several times in the past that on my laptop I can "boot" Linux-hosted AROS (so the problem is not the Linux kernel, nor X) with a custom startup script to boot it straight into a full featured, scriptable text editor in less time than it takes to start Emacs. I'm sure it's possible to tune my Emacs setup (for example, I found out by a fluke, that the default Emacs setup on debian will wait for a DNS request to complete or time out before it starts - break your DNS setup and Emacs will hang for ages) or pick another editor (many of the other ones I've tried are either just as slow or feature-limited compared to the Amiga editor in question - FrexxEd, co-written by the same guy that started curl), but the point is that we've come to accept the kind of slow startup and UI latency that was unacceptable back then. E.g. people spent weeks tuning and trimming AmigaOS commands to make them the smallest possible so we could make as many of them as possible RAM resident to avoid the tiny fractions of a second it'd take the load-time linker to load them. I'm happy we don't need to think that much about the RAM any more. But we do need to think about the latency. There's the attitude that we should just throw servers at this instead of developer time. That's fine when you can compensate by e.g. throwing more RAM in and/or a program is run relatively rarely or where paying for a beefier server in some data centre can achieve the same performance. But it's not true when latency grows into user noticeable levels because you can't get high enough single-core performance, and that program is run a lot.
- onion2k 10y ago
  Poorly written websites can bring a desktop PC to its knees, but so can a poorly written native application. That isn't an argument against leveraging web technology so much as an argument in favour of well written applications. And at least with a chromeless-browser-pretending-to-be-application you have the protection of the browser process sandbox so an app that goes awry isn't going to take your computer down that badly.
  - aikah 10y ago
    > That isn't an argument against leveraging web technology so much as an argument in favour of well written applications The difference is there is very little room for optimisation in most javascript runtimes. They don't support multi-threading and the memory is impossible to manage. "Lower" level languages always allow better performance tweaking when necessary. Javascript allows next to none. You can't tell javascript :"Give me an array of 10 elements", or "give me a integer of that length". So no "headroom" for performances with Javascript.
    - BinaryIdiot 10y ago
      > the memory is impossible to manage. Nonsense. There are plenty of strategies for managing memory efficiently in JavaScript. Yes you can't do a C++ level of allocation, decallocation, etc but you most certainly can manage the amount of memory your code uses.
    - jaquers 10y ago
      I think the spirit of the argument is that if you have requirements for heavy computation such that you need multithreading + low level memory management, then you probably shouldn't use this. Use the right tool for the job. This is just one of them. Plus there are alternatives to threads. Look at the state of Atom or VSCode. Much progress has been made in terms of perf and these are not trivial applications.
      - dilann 10y ago
        > Use the right tool for the job That's a funny argument in a thread about js. Js has started as a small language to do scripting on the pages, now they are sticking it everywhere.
- jaquers 10y ago
  No disagreement about memory usage, except to say that [some web sites] are usually either poorly or unethically coded. I was on theverge.com yesterday, wondering why the network indicator was going crazy on a blog post. Pull up dev tools and it's ad code downloading megs worth of data, endlessly. Whether that's on theverge, or bad actor for ad code; I don't know or care - but when people talk about bad websites that's usually the primary example in my experience.
- segmondy 10y ago
  See the spotify client, popcorn time, visual studio code. these are javascript. They run great.
  - _prototype_ 10y ago
    Also the Slack web client
  - rbanffy 10y ago
    Have you checked how much memory they use? I know we have 8-core laptops with 16 gigs of RAM, but, still, it's excessive.
    - segmondy 10y ago
      Don't have an 8 core, or 16 gigs of ram. I'm talking about my desktop. I have a 4 core i5 from 2013. Spotify has 173M in res. Visual studio code with 10 files open has 99M in res. I have firefox open with about 125 tabs open, 6 terminal windows, 2 pdf files open, VLC open but not playing, IRC in about 15 channels. Load average is 0.60. Memory load across all CPU's about 10%. 8gigs used out of 12gigs of ram. With firefox using 5.1 gigs.
    - freyr 10y ago
      Any idea why the memory usage is so high? Is it related to the Electron/Chromium platform, or bad application design?
      - rbanffy 10y ago
        Would need to check, but my bet is caching of partially rendered HTML as bitmaps, as well as a full JavaScript JIT environment. It's just a high footprint enironment.
doublerebel 10y ago
Linux is more successful on the desktop than it's ever been, and Gnome is largely powered by JavaScript. The Gnome extensions repository is a huge JavaScript success. Never before has WM customization been so accessible. The Universal Windows Platform also has a JavaScript API that is a breeze compared to the old Win32 development process. Electron is good but just the tip of the iceberg. I think it says more that major OSes have bet their future on JavaScript.
- tonyedgecombe 10y ago
  More likely they see a lot of programmers who only know JavaScript and they want to offer them something.
  - lloyd-christmas 10y ago
    Is that a bad thing?
    - tonyedgecombe 10y ago
      No, well programmers just knowing JavaScript is but catering to a wider audience is a good thing.
  - glasz 10y ago
    was just about to say: it's not damn javascript, it's the damn developers. it's really becoming like java. pushed every, but the wrong choice on many occasions.
- aikah 10y ago
  > Linux is more successful on the desktop than it's ever been, and Gnome is largely powered by JavaScript. You mean gjs which is a poor javascript runtime. And Gnome is largely powered by C more than javascript. You may use javascript because Gobject-introspection which is also available for perl and python.
- gpderetta 10y ago
  Anecdote time: after I did a distupgrade of my kubuntu desktop to the next kubuntu release, kwin kept crashing for some reason, probably due to a botched package update. After attaching gdb to the dying process I found out that it was dying inside a javascript interpreter. Not wanting to know WTF a JS interpreter was doing inside the window manager, I wiped kubuntu, installed plain debian and now I'm happily running xfce on my desktop too. Of course now someone will tell me that xfce has also been similarly infected...
deleted 10y ago
[deleted]
ndepoel 10y ago
JavaScript didn't "conquer" anything. It was just one of the first languages around when the web was still in its infancy, and simply never went away.
- zeppelin101 10y ago
  Javascript became far more significant than what it used to be. We can largely thank Microsoft (AJAX) and Google (V8) for that.
  - jdhawk 10y ago
    And Sun, for being assholes about Java.
- r00fus 10y ago
  Lets be honest here, Javascript (alternately known as ECMAscript [1]) has done the following: a) progressively adopted new language features like prototypes, closures, generics and the like. Javascript just being there early wasn't enough. I has improved remarkably over the past 20 years, and the ECMA standards body has been critical to that improvement. That said, it's still a quirky language and that alone makes a lot of people feel they can't rely on it. https://en.wikipedia.org/wiki/ECMAScript https://en.wikipedia.org/wiki/ECMAScript
  - zeveb 10y ago
    > Lets be honest here, Javascript (alternately known as ECMAscript [1]) has done the following: a) progressively adopted new language features like prototypes, closures, generics and the like. JavaScript had prototypes and closures from the beginning, no? Does it really have generics — a quick Googling makes it appear that it's a matter of hand-rolling. But it's been awhile since I've written JavaScript in anger, so perhaps I've missed an announcement since then.
- halayli 10y ago
  You're in denial. Javascript is everywhere nowadays. It has become the English of languages. It's not my favorite language but it has improved extensively. No one wants to maintain a web app, mobile app, and desktop app separately.
jjtheblunt 10y ago
bologna.
jesuslop 10y ago
because bytecode isn't slow enough
seibelj 10y ago
I know many languages but JS is what a lot of new companies need, therefore I have devoted myself to it. On my own time, I like to code in C, because it is a pleasure to use something so fast and close to the metal, and requires such a different style of programming (disciplined paranoia) and allows me maximum control over application resources.
- rjbwork 10y ago
  IMO C and JS both stink. Give me statically typed, memory managed, expressivity or give me death.
  - hood_syntax 10y ago
    C is a necessary evil (debatably necessary, but at the very least quite useful). Apart from that, I agree with you. Static typing is a core tool for helping me manage complexity, and I wish I got to use it in my work.
niftich 10y ago
The salient points of the article: - People are stuffing websites into Electron and packaging it as a native application - HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience Although the article doesn't say it, this seems to imply that: - Full-native development unique on each platform is considered too much effort, when you can get a cross-platform app with Electron - Other platforms are not very 'hackable'; why is this? Is this purely because JS has a higher mindshare and marketshare than [preferred platform language] on [preferred platform toolkit] on [preferred platform], or do HTML/CSS/JS applications actually tend to hit a sweet spot in terms of separation of presentation, view logic, business logic? Or is it about the view-understand-edit-deploy lifecycle being easier with HTML/JS apps?
- haddr 10y ago
  I think it's the mixture of both. Editing something, pressing f5 and watching new changes getting into your webpage is really great, and a form of instant gratification. This workflow will always be better than for example restarting jetty web server to reload some servlet... Also when you have everything packaged inside you don't worry about runtime libraries. That's another headache in native app deployments. And the third is great ecosystem of libraries, editors, tutorials, snippets, etc. Low entry barrier makes it easy to quickly adopt.
- kartan 10y ago
  > HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience I think that's related to the high fault-tolerance in Javascript. A good developer is good in any language, so she can work with Javascript. A beginner or even a bad developer can make things happen in Javascript, when that is not always possible in other languages. So the entry point level is so low that a lot of people is using it. > Other platforms are not very 'hackable'; why is this? I prefer strong typed languages. I use TypeScript when I have to do some JS work as it is easier to maintain in the long term. But that means that you need to know what you are doing before starting to do anything. Compile, fix errors, repeat. I can see that for starters JS is more fun and "hackable", as it was BASIC for me when I started.
dan_ahmadi 10y ago
There are companies using this in production -- saving time and resources! Example: https://mixmax.com/blog/turnkey-electron-apps-with-meteor https://mixmax.com/blog/turnkey-electron-apps-with-meteor
simula67 10y ago
> It turns out it’s useful to have a lingua franca for the web. No, I don't think so. Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser. There is a BIG difference. > Creating desktop apps in JavaScript lets developers choose from a vast range of freely available code libraries and frameworks, which takes much of the grunt work out of coding Lots of languages have a wide array of freely available code tooling and frameworks. Slightly tangentially though, I wonder if we really really put our mind to it, will we be able to just kill JavaScript ? I mean, I am sure that there are people out there making a living on JavaScript, but please, take one for the team. Learn something else. I hear it is a hot market for developers. JavaScript is obviously a flawed language[1] that inspires absolutely bad programming that the rest of us has to deal with. The ecosystem is terrible[2] and the community is full of self-righteous assholes[3] who has the collective attention span of a 2 year old [4]. Let's just call this experiment a failure, cut our losses and just.move.on. [1] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat [2] http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ [3] http://atom-morgan.github.io/in-defense-of-douglas-crockford http://atom-morgan.github.io/in-defense-of-douglas-crockford [4] https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4#.gc226gtmp https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...
- scrollaway 10y ago
  > Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser. You're not contradicting what you are replying to. People are using Javascript because it's the only option, but it is useful to have a lingua franca. I just wish that lingua franca wasn't Javascript.
  - inputcoffee 10y ago
    I agree with the first part. The issues of: "utility of lingua franca" and "ubiquity of Javascript" are orthogonal issues. It seems everyone agrees that Javascript would not have been the first choice of language. There is no short argument there, you have to go out and try at least one other language and compare them. However, on the second question, I don't see why it is useful to have a lingua franca. Multiple languages arise out of multiple needs. You want a superfast language for your OS, you want a quick high level language for quickly examining data, you want a language that describes visuals and so forth. What are the benefits of a lingua franca for the internet, or any other domain? They still get to exchange data in an agreed upon format.
sebringj 10y ago
More systems like React Native are how JavaScript should be done on the desktop rather than cordova-like things running in a node host. It has approachability but also performance and ubiquity of skill set, very little friction and is better suited for integrating native controls IMO.
- doublerebel 10y ago
  React Native is part of a solid continuing trend. I've had a really good experience with the Appcelerator Titanium JS API for Android/iOS, and for the last couple versions iOS has a quality native JS API itself. Now ExponentJS has entered the ring powered by React Native and looks very very promising. When a business needs to deploy to several platforms at once, it's a quick and success-proven model that still has good performance.
  - sebringj 10y ago
    I'm going to investigate ExponentJS as that sounds like a gap needed filling.
- mamcx 10y ago
  I almost jump to react-native, then I discover that I need to do the npm install bloatware dance. Is possible to have a more lean setup?
dboreham 10y ago
Everything evolves, and this is where evolution has led us. Unfortunately.
- xkcd-sucks 10y ago
  JS is the cockroach of programming languages
knodi 10y ago
Ya, if JS went away tomorrow and replace by something else I would be happy about it.
abc_lisper 10y ago
Ahem. Let me be the first to say, YUCK!!! I don't understand why people like this language. I am sure it has it's uses etc., but come on, if you want to build a reliable, easy-to-reason program, using JS is just running up a escalator that is going down. https://abdulapopoola.com/2015/09/30/why-javascript-seems-to-get-addition-wrong/ https://abdulapopoola.com/2015/09/30/why-javascript-seems-to... http://rhodesmill.org/brandon/2012/js/ http://rhodesmill.org/brandon/2012/js/ http://dorey.github.io/JavaScript-Equality-Table/ http://dorey.github.io/JavaScript-Equality-Table/ https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat http://blog.chewxy.com/2014/01/27/javascript-wat-again/ http://blog.chewxy.com/2014/01/27/javascript-wat-again/ I can see using js as a target language with a 'transpiler', but JS is just a shitty language to write code.
b123400 10y ago
When I choose softwares, I tend to choose native one over electron or JavaFX ones. It feels more native and more "sincere", like the developer really want to make it a good software. I know this logic doesn't make sense, but I don't mind paying more if it is native. It's like a handwritten letter, not a printed one.
- bluetidepro 10y ago
  > "...I don't mind paying more if it is native..." I'm curious on how you know this before you even purchase? For example, the Mac app store can have both native and electron apps? You wouldn't know it's native or not until after you purchase it?
  - b123400 10y ago
    1. File size is a big hint. 2. Most of the electron apps doesn't replicate native elements completely, so you can guess it from tiny details like shape and shadow of text field. 3. It is also very common for their windows counterpart to look exactly the same.
  - deleted 10y ago
    [deleted]
mxuribe 10y ago
Sure these early days might show this being overkill, or less performant than traditional methods, but my hope is that this newer approach leads to other types of benefical apps. I'm keenly interested in how these types of approaches help for "unhosted" types of apps (see http://unhosted.org/ http://unhosted.org/), as well as offline first apps.
coldcode 10y ago
No. Javascript frameworks/tools change every few months, by the time you finish a project, everything you used has been superseded by something new. Last year's expert is today's luddite. Change at that pace is unsustainable for long term support of applications.
thegeomaster 10y ago
My biggest issue with these apps is the inability to share memory. If I have Viber, Slack, Atom and regular Chromium open at the same time, they all consume copious amounts of memory which I assume is due to the constant overhead layout/JS engines need to keep resident per app. If I'd somehow opened all these as tabs on Chromium, they would plug into Chromium's already-allocated shared data structures and the memory consumed would be quite lower. I can have Facebook Messenger, Deezer and Gmail open alongside 10+ other tabs at all times, but once I start Slack and Viber alongside Chromium (or Skype for Linux Alpha, or Visual Studio Code, or Black Screen, or any of these trendy hybrid-web-desktop apps), Linux starts screaming and swapping things around; as a result, everything becomes sluggish. Also, the apps themselves feel a bit laggy even when they have all the memory they need. I know the comparison is not fair, but using, say, Code::Blocks or QtCreator (which are full-blown IDEs) with Atom, I can feel input response differences for some reason. I have a low amount of RAM on my home PC and I plan on upgrading it, so you can say that my hardware is the problem, but clogging up memory like that is always a waste. As a test, I just opened Popcorn Time. Right after startup, it uses 200MB of resident memory. The whole GNOME shell + the Xorg process consume around 280MB combined on my PC. That's insane. Yes, it looks beautiful, but it's nothing you can't do with Qt these days. It also supports JavaScript. QML is not hard to learn. It's available for Windows, Linux, OS X, and even mobile. Ditto for GTK+ 3: Vala is beautiful, practically C#, and good enough for at least the UI layer of your app, if not for the whole thing. Qt and GTK+ are both open source and LGPL, which means you can freely link to them even if you develop proprietary software. I just don't see such a need to make today's apps so bloated (and I don't consider "people have enough memory nowadays" a valid argument). If it's an one-off app made by a small team, or for fun, the trade-offs may be worth it. But for Slack, or Skype for Linux, or VS Code, wouldn't it make sense to put more developer time on it and have a much more performance-conscious application?
zwetan 10y ago
"Adobe’s AIR system enabled developers" it still does, AIR v1.0 was in 2006, we are now at v23.0 Electron is nice but a whole browser engine is a big bloat, you can easily reach 150MB. Not to go into a debate JS vs AS3, but the AIR runtime have a lot of advantages : AS3 the language is one, the default native API cover a lot of ground, being able to extend those native functionalities with ANE (ActionScript Native Extension) is nice too. I don't buy the kool-aid that you could use the exact same HTML5/CSS/JS code for both the browser and a desktop app, unless the app is trivial you gonna have to build your UI/UX specifically for the desktop with all the different subtleties between different OS. So sure you can use something like Electron to easily wrap an already existing web app for the desktop but imho either you are limiting the desktop features you could add or you will soon end up having 2 code base: 1 for the web and 1 for the desktop and that require more resources than just "wrapping it up for the desktop".

172 points by nreece 10y ago

I'm not an expert, but the memory required to render the seemingly simplest of interfaces in html/js/css in a browser today seems excessive. Some web sites bring a reasonably powered desktop to its knees. I'm not sure I want this problem on my desktop too. Though I guess this is just one step closer to having METAL. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

dismantlethesun 10y ago
It is pretty excessive, but maybe web assembly would find a real home in making applications that do well on both native and web.
- n00b101 10y ago
  WebAssembly will hopefully end JavaScript's stranglehold on the web. The justification for using JavaScript for server/desktop/mobile applications seems to essentially be that a certain large group of programmers only know JavaScript.
  - gjolund 10y ago
    Agreed, Im so tired of being forced to write js.
  - contextfree 10y ago
    I'm not sure. All the browser APIs will still use the JS object model. If we look at the situation on the JVM or CLR, it seems like languages specifically designed for those object models (even if adapted from other languages) have been more successful than attempts to directly port existing languages. e.g., Scala, Clojure, F# or Powershell vs. Jython, JRuby, C++/CLI or IronPython. My bet would be that languages specifically designed for the JS ecosystem (whether JS itself or something like CoffeeScript or TypeScript) will continue to be the most popular for writing most of an app, with some apps dropping down to C or C++ or Rust compiled to wasm for a subset of performance-critical code.
    - vidarh 10y ago
      I'm sure there'll be a mix. But consider things like Opal (Ruby => javascript), and it seems like there's at least some people who very much want to be able to work in a single language, but for that language to not be javascript... I'm sure once webassembly is ready, that'll at least get more popular.
  - Udik 10y ago
    I guess you tend to reuse the technologies you're familiar with, especially when they are very well proven for solving a very complicated problem that requires a lot of expertise (I'm talking about fancy UIs, of course). Which is also why I think the emphasis on JS is wrong: the main selling point of these technologies is NOT javascript, is HTML5/ CSS. Javascript is just a (very handy indeed) scripting language like any other: frankly the logic and requirements of most applications around are not complex enough to justify the usage of anything more solid or complicated than that. Just today I was contacted by a former colleague, a Java developer, asking advice on using Electron to develop a quick desktop application. On the other hand, there is a long list of languages that transpile to javascript. So where are the masses of serious C#/ Java/ <pick-your-language> developers using transpilers to write the logic of their web applications?
    - n00b101 10y ago
      So where are the masses of serious C#/ Java/ <pick-your-language> developers using transpilers to write the logic of their web applications? I think it is catching on with C++ game developers, who want to be able to run the same codebase natively or in the web browser. The Unity 3D game engine has built-in support for this using WebGL, for example. I don't know if CLR or JVM languages have been successfully transpiled to the browser using asm.js / WebAssembly (it wouldn't be very efficient at all, so I doubt that will ever be popular).
raquo 10y ago
No one likes that, but 1) HTML/CSS/JS is sill the only truly cross-platform (mac/windows/linux/web/ios/android/etc.) UI platform/ecosystem in 2016, and it will probably stay that way in the foreseeable future because OS makers love their walled gardens. 2) An app's memory efficiency is not a top 10 priority of an average solo-or-small-team developer's concerns, because that's not what most users pay for. Electron/NW.js apps will only become more common, so I hope things will improve with asm.js/webassembly/etc.
- fdgdasfadsf 10y ago
  On point (1) you've kind of loaded the comparison by including web in that list...
  - raquo 10y ago
    It's a common business scenario: start out as a web app, then as business picks up let's start providing native apps. Or the other way: start out with a native app on the platform we most care about + a web app for "access from anywhere".
- gr3yh47 10y ago
  Python would like a word with you about point 1)
  - corv 10y ago
    Python on iOS?
    - nodja 10y ago
      It's not pretty but: https://kivy.org/docs/guide/packaging-ios.html https://kivy.org/docs/guide/packaging-ios.html
      - corv 10y ago
        Interesting
catnaroek 10y ago
Too much wishful thinking during the second half of the talk, though. Also, while fancy runtime systems can improve the performance of dynamic[0] languages, it doesn't come for free: the price to be paid is the loss of elegance. For instance, a JIT compiler could inline a virtual method that seems not to be overridden anywhere, but if later on it turns out that the virtual method was overridden somewhere, the “optimization” has to be undone. How can anyone in their right mind trust a language that requires such dirty implementation tricks to achieve decent performance? [0] By which I mean “less amenable to static analysis”, regardless of whether the language has a static type system. For instance, Java and C# are dynamic languages in this sense.
- smallnamespace 10y ago
  > How can anyone in their right mind trust a language that requires such dirty implementation tricks to achieve decent performance? Isn't this a rather broad brush with which to paint all JIT language implementations, including Java, C#, and, say, PyPy?
  - catnaroek 10y ago
    Could you name a JIT compiler that doesn't do this kind of thing, yet offers performance comparable to AOT-compiled languages? (FWIW, I'm not saying it's impossible. It's perfectly possible, but you'd need a source language that offers much better static guarantees than the typical language that a JIT compiler is written for.) --- Sorry, can't reply to you directly, because “I'm submitting too fast”. So my reply goes here: > for the simple reason that type systems cannot capture all relevant runtime context. Type checking isn't the only kind of static analysis out there. And there's no need to use statistics to optimize anything at runtime when your ahead-of-time compilation step already emits optimal target machine code. > Java is a good example here, since it's strongly statically typed. Java is as dynamically typed as it gets: `instanceof`, downcasts and reflection, all conspire to reduce the usefulness of static type information to zero. > By your reckoning, all greedy optimizations that CPUs do like branch prediction and prefetching are also similarly 'inelegant', because they can be wrong and require rolling back. Yes, indeed. It's more elegant to know beforehand what exactly you have to do, and then do just that and nothing else.
wpietri 10y ago
I feel your pain. My first computer had 4K of RAM; my second had 48K; my third, 640K. I learned to work small. It pains me to see the equivalent of Hello World taking up untold MB. But when I think about software as a business rather than an art, I have to concede that it's a very rare circumstance where RAM efficiency matters as much as I'd like. Note the way the cost of memory has declined: http://www.jcmit.com/mem2015.htm http://www.jcmit.com/mem2015.htm Watches now have 100,000 times the RAM that I started with. Costs are dropping by 1-2 orders of magnitude per decade. Something that is absurdly wasteful now could well be economically reasonable very soon.
- vidarh 10y ago
  Memory isn't the issue to me. Latency is. Most of the applications I work with today do a lot, that's true, but their UI latency is often worse than it was on my 7.16Mz M68000 Amiga 500, and other things as well are just slow. I've mentioned here several times in the past that on my laptop I can "boot" Linux-hosted AROS (so the problem is not the Linux kernel, nor X) with a custom startup script to boot it straight into a full featured, scriptable text editor in less time than it takes to start Emacs. I'm sure it's possible to tune my Emacs setup (for example, I found out by a fluke, that the default Emacs setup on debian will wait for a DNS request to complete or time out before it starts - break your DNS setup and Emacs will hang for ages) or pick another editor (many of the other ones I've tried are either just as slow or feature-limited compared to the Amiga editor in question - FrexxEd, co-written by the same guy that started curl), but the point is that we've come to accept the kind of slow startup and UI latency that was unacceptable back then. E.g. people spent weeks tuning and trimming AmigaOS commands to make them the smallest possible so we could make as many of them as possible RAM resident to avoid the tiny fractions of a second it'd take the load-time linker to load them. I'm happy we don't need to think that much about the RAM any more. But we do need to think about the latency. There's the attitude that we should just throw servers at this instead of developer time. That's fine when you can compensate by e.g. throwing more RAM in and/or a program is run relatively rarely or where paying for a beefier server in some data centre can achieve the same performance. But it's not true when latency grows into user noticeable levels because you can't get high enough single-core performance, and that program is run a lot.
onion2k 10y ago
Poorly written websites can bring a desktop PC to its knees, but so can a poorly written native application. That isn't an argument against leveraging web technology so much as an argument in favour of well written applications. And at least with a chromeless-browser-pretending-to-be-application you have the protection of the browser process sandbox so an app that goes awry isn't going to take your computer down that badly.
- aikah 10y ago
  > That isn't an argument against leveraging web technology so much as an argument in favour of well written applications The difference is there is very little room for optimisation in most javascript runtimes. They don't support multi-threading and the memory is impossible to manage. "Lower" level languages always allow better performance tweaking when necessary. Javascript allows next to none. You can't tell javascript :"Give me an array of 10 elements", or "give me a integer of that length". So no "headroom" for performances with Javascript.
  - BinaryIdiot 10y ago
    > the memory is impossible to manage. Nonsense. There are plenty of strategies for managing memory efficiently in JavaScript. Yes you can't do a C++ level of allocation, decallocation, etc but you most certainly can manage the amount of memory your code uses.
  - jaquers 10y ago
    I think the spirit of the argument is that if you have requirements for heavy computation such that you need multithreading + low level memory management, then you probably shouldn't use this. Use the right tool for the job. This is just one of them. Plus there are alternatives to threads. Look at the state of Atom or VSCode. Much progress has been made in terms of perf and these are not trivial applications.
    - dilann 10y ago
      > Use the right tool for the job That's a funny argument in a thread about js. Js has started as a small language to do scripting on the pages, now they are sticking it everywhere.
jaquers 10y ago
No disagreement about memory usage, except to say that [some web sites] are usually either poorly or unethically coded. I was on theverge.com yesterday, wondering why the network indicator was going crazy on a blog post. Pull up dev tools and it's ad code downloading megs worth of data, endlessly. Whether that's on theverge, or bad actor for ad code; I don't know or care - but when people talk about bad websites that's usually the primary example in my experience.
segmondy 10y ago
See the spotify client, popcorn time, visual studio code. these are javascript. They run great.
- _prototype_ 10y ago
  Also the Slack web client
- rbanffy 10y ago
  Have you checked how much memory they use? I know we have 8-core laptops with 16 gigs of RAM, but, still, it's excessive.
  - segmondy 10y ago
    Don't have an 8 core, or 16 gigs of ram. I'm talking about my desktop. I have a 4 core i5 from 2013. Spotify has 173M in res. Visual studio code with 10 files open has 99M in res. I have firefox open with about 125 tabs open, 6 terminal windows, 2 pdf files open, VLC open but not playing, IRC in about 15 channels. Load average is 0.60. Memory load across all CPU's about 10%. 8gigs used out of 12gigs of ram. With firefox using 5.1 gigs.
  - freyr 10y ago
    Any idea why the memory usage is so high? Is it related to the Electron/Chromium platform, or bad application design?
    - rbanffy 10y ago
      Would need to check, but my bet is caching of partially rendered HTML as bitmaps, as well as a full JavaScript JIT environment. It's just a high footprint enironment.

doublerebel 10y ago

Linux is more successful on the desktop than it's ever been, and Gnome is largely powered by JavaScript. The Gnome extensions repository is a huge JavaScript success. Never before has WM customization been so accessible. The Universal Windows Platform also has a JavaScript API that is a breeze compared to the old Win32 development process. Electron is good but just the tip of the iceberg. I think it says more that major OSes have bet their future on JavaScript.

tonyedgecombe 10y ago
More likely they see a lot of programmers who only know JavaScript and they want to offer them something.
- lloyd-christmas 10y ago
  Is that a bad thing?
  - tonyedgecombe 10y ago
    No, well programmers just knowing JavaScript is but catering to a wider audience is a good thing.
- glasz 10y ago
  was just about to say: it's not damn javascript, it's the damn developers. it's really becoming like java. pushed every, but the wrong choice on many occasions.
aikah 10y ago
> Linux is more successful on the desktop than it's ever been, and Gnome is largely powered by JavaScript. You mean gjs which is a poor javascript runtime. And Gnome is largely powered by C more than javascript. You may use javascript because Gobject-introspection which is also available for perl and python.
gpderetta 10y ago
Anecdote time: after I did a distupgrade of my kubuntu desktop to the next kubuntu release, kwin kept crashing for some reason, probably due to a botched package update. After attaching gdb to the dying process I found out that it was dying inside a javascript interpreter. Not wanting to know WTF a JS interpreter was doing inside the window manager, I wiped kubuntu, installed plain debian and now I'm happily running xfce on my desktop too. Of course now someone will tell me that xfce has also been similarly infected...

deleted 10y ago

[deleted]

ndepoel 10y ago

JavaScript didn't "conquer" anything. It was just one of the first languages around when the web was still in its infancy, and simply never went away.

zeppelin101 10y ago
Javascript became far more significant than what it used to be. We can largely thank Microsoft (AJAX) and Google (V8) for that.
- jdhawk 10y ago
  And Sun, for being assholes about Java.
r00fus 10y ago
Lets be honest here, Javascript (alternately known as ECMAscript [1]) has done the following: a) progressively adopted new language features like prototypes, closures, generics and the like. Javascript just being there early wasn't enough. I has improved remarkably over the past 20 years, and the ECMA standards body has been critical to that improvement. That said, it's still a quirky language and that alone makes a lot of people feel they can't rely on it. https://en.wikipedia.org/wiki/ECMAScript https://en.wikipedia.org/wiki/ECMAScript
- zeveb 10y ago
  > Lets be honest here, Javascript (alternately known as ECMAscript [1]) has done the following: a) progressively adopted new language features like prototypes, closures, generics and the like. JavaScript had prototypes and closures from the beginning, no? Does it really have generics — a quick Googling makes it appear that it's a matter of hand-rolling. But it's been awhile since I've written JavaScript in anger, so perhaps I've missed an announcement since then.
halayli 10y ago
You're in denial. Javascript is everywhere nowadays. It has become the English of languages. It's not my favorite language but it has improved extensively. No one wants to maintain a web app, mobile app, and desktop app separately.

jjtheblunt 10y ago

bologna.

jesuslop 10y ago

because bytecode isn't slow enough

seibelj 10y ago

I know many languages but JS is what a lot of new companies need, therefore I have devoted myself to it. On my own time, I like to code in C, because it is a pleasure to use something so fast and close to the metal, and requires such a different style of programming (disciplined paranoia) and allows me maximum control over application resources.

rjbwork 10y ago
IMO C and JS both stink. Give me statically typed, memory managed, expressivity or give me death.
- hood_syntax 10y ago
  C is a necessary evil (debatably necessary, but at the very least quite useful). Apart from that, I agree with you. Static typing is a core tool for helping me manage complexity, and I wish I got to use it in my work.

niftich 10y ago

The salient points of the article: - People are stuffing websites into Electron and packaging it as a native application - HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience Although the article doesn't say it, this seems to imply that: - Full-native development unique on each platform is considered too much effort, when you can get a cross-platform app with Electron - Other platforms are not very 'hackable'; why is this? Is this purely because JS has a higher mindshare and marketshare than [preferred platform language] on [preferred platform toolkit] on [preferred platform], or do HTML/CSS/JS applications actually tend to hit a sweet spot in terms of separation of presentation, view logic, business logic? Or is it about the view-understand-edit-deploy lifecycle being easier with HTML/JS apps?

haddr 10y ago
I think it's the mixture of both. Editing something, pressing f5 and watching new changes getting into your webpage is really great, and a form of instant gratification. This workflow will always be better than for example restarting jetty web server to reload some servlet... Also when you have everything packaged inside you don't worry about runtime libraries. That's another headache in native app deployments. And the third is great ecosystem of libraries, editors, tutorials, snippets, etc. Low entry barrier makes it easy to quickly adopt.
kartan 10y ago
> HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience I think that's related to the high fault-tolerance in Javascript. A good developer is good in any language, so she can work with Javascript. A beginner or even a bad developer can make things happen in Javascript, when that is not always possible in other languages. So the entry point level is so low that a lot of people is using it. > Other platforms are not very 'hackable'; why is this? I prefer strong typed languages. I use TypeScript when I have to do some JS work as it is easier to maintain in the long term. But that means that you need to know what you are doing before starting to do anything. Compile, fix errors, repeat. I can see that for starters JS is more fun and "hackable", as it was BASIC for me when I started.

dan_ahmadi 10y ago

There are companies using this in production -- saving time and resources! Example: https://mixmax.com/blog/turnkey-electron-apps-with-meteor https://mixmax.com/blog/turnkey-electron-apps-with-meteor

simula67 10y ago

> It turns out it’s useful to have a lingua franca for the web. No, I don't think so. Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser. There is a BIG difference. > Creating desktop apps in JavaScript lets developers choose from a vast range of freely available code libraries and frameworks, which takes much of the grunt work out of coding Lots of languages have a wide array of freely available code tooling and frameworks. Slightly tangentially though, I wonder if we really really put our mind to it, will we be able to just kill JavaScript ? I mean, I am sure that there are people out there making a living on JavaScript, but please, take one for the team. Learn something else. I hear it is a hot market for developers. JavaScript is obviously a flawed language[1] that inspires absolutely bad programming that the rest of us has to deal with. The ecosystem is terrible[2] and the community is full of self-righteous assholes[3] who has the collective attention span of a 2 year old [4]. Let's just call this experiment a failure, cut our losses and just.move.on. [1] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat [2] http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ [3] http://atom-morgan.github.io/in-defense-of-douglas-crockford http://atom-morgan.github.io/in-defense-of-douglas-crockford [4] https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4#.gc226gtmp https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...

scrollaway 10y ago
> Most people do not use JavaScript since it is useful. They use it since it is the only option available on the browser. You're not contradicting what you are replying to. People are using Javascript because it's the only option, but it is useful to have a lingua franca. I just wish that lingua franca wasn't Javascript.
- inputcoffee 10y ago
  I agree with the first part. The issues of: "utility of lingua franca" and "ubiquity of Javascript" are orthogonal issues. It seems everyone agrees that Javascript would not have been the first choice of language. There is no short argument there, you have to go out and try at least one other language and compare them. However, on the second question, I don't see why it is useful to have a lingua franca. Multiple languages arise out of multiple needs. You want a superfast language for your OS, you want a quick high level language for quickly examining data, you want a language that describes visuals and so forth. What are the benefits of a lingua franca for the internet, or any other domain? They still get to exchange data in an agreed upon format.

sebringj 10y ago

More systems like React Native are how JavaScript should be done on the desktop rather than cordova-like things running in a node host. It has approachability but also performance and ubiquity of skill set, very little friction and is better suited for integrating native controls IMO.

doublerebel 10y ago
React Native is part of a solid continuing trend. I've had a really good experience with the Appcelerator Titanium JS API for Android/iOS, and for the last couple versions iOS has a quality native JS API itself. Now ExponentJS has entered the ring powered by React Native and looks very very promising. When a business needs to deploy to several platforms at once, it's a quick and success-proven model that still has good performance.
- sebringj 10y ago
  I'm going to investigate ExponentJS as that sounds like a gap needed filling.
mamcx 10y ago
I almost jump to react-native, then I discover that I need to do the npm install bloatware dance. Is possible to have a more lean setup?

dboreham 10y ago

Everything evolves, and this is where evolution has led us. Unfortunately.

xkcd-sucks 10y ago
JS is the cockroach of programming languages

knodi 10y ago

Ya, if JS went away tomorrow and replace by something else I would be happy about it.

abc_lisper 10y ago

Ahem. Let me be the first to say, YUCK!!! I don't understand why people like this language. I am sure it has it's uses etc., but come on, if you want to build a reliable, easy-to-reason program, using JS is just running up a escalator that is going down. https://abdulapopoola.com/2015/09/30/why-javascript-seems-to-get-addition-wrong/ https://abdulapopoola.com/2015/09/30/why-javascript-seems-to... http://rhodesmill.org/brandon/2012/js/ http://rhodesmill.org/brandon/2012/js/ http://dorey.github.io/JavaScript-Equality-Table/ http://dorey.github.io/JavaScript-Equality-Table/ https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat http://blog.chewxy.com/2014/01/27/javascript-wat-again/ http://blog.chewxy.com/2014/01/27/javascript-wat-again/ I can see using js as a target language with a 'transpiler', but JS is just a shitty language to write code.

b123400 10y ago

When I choose softwares, I tend to choose native one over electron or JavaFX ones. It feels more native and more "sincere", like the developer really want to make it a good software. I know this logic doesn't make sense, but I don't mind paying more if it is native. It's like a handwritten letter, not a printed one.

bluetidepro 10y ago
> "...I don't mind paying more if it is native..." I'm curious on how you know this before you even purchase? For example, the Mac app store can have both native and electron apps? You wouldn't know it's native or not until after you purchase it?
- b123400 10y ago
  1. File size is a big hint. 2. Most of the electron apps doesn't replicate native elements completely, so you can guess it from tiny details like shape and shadow of text field. 3. It is also very common for their windows counterpart to look exactly the same.
- deleted 10y ago
  [deleted]

mxuribe 10y ago

Sure these early days might show this being overkill, or less performant than traditional methods, but my hope is that this newer approach leads to other types of benefical apps. I'm keenly interested in how these types of approaches help for "unhosted" types of apps (see http://unhosted.org/ http://unhosted.org/), as well as offline first apps.

coldcode 10y ago

No. Javascript frameworks/tools change every few months, by the time you finish a project, everything you used has been superseded by something new. Last year's expert is today's luddite. Change at that pace is unsustainable for long term support of applications.

thegeomaster 10y ago

My biggest issue with these apps is the inability to share memory. If I have Viber, Slack, Atom and regular Chromium open at the same time, they all consume copious amounts of memory which I assume is due to the constant overhead layout/JS engines need to keep resident per app. If I'd somehow opened all these as tabs on Chromium, they would plug into Chromium's already-allocated shared data structures and the memory consumed would be quite lower. I can have Facebook Messenger, Deezer and Gmail open alongside 10+ other tabs at all times, but once I start Slack and Viber alongside Chromium (or Skype for Linux Alpha, or Visual Studio Code, or Black Screen, or any of these trendy hybrid-web-desktop apps), Linux starts screaming and swapping things around; as a result, everything becomes sluggish. Also, the apps themselves feel a bit laggy even when they have all the memory they need. I know the comparison is not fair, but using, say, Code::Blocks or QtCreator (which are full-blown IDEs) with Atom, I can feel input response differences for some reason. I have a low amount of RAM on my home PC and I plan on upgrading it, so you can say that my hardware is the problem, but clogging up memory like that is always a waste. As a test, I just opened Popcorn Time. Right after startup, it uses 200MB of resident memory. The whole GNOME shell + the Xorg process consume around 280MB combined on my PC. That's insane. Yes, it looks beautiful, but it's nothing you can't do with Qt these days. It also supports JavaScript. QML is not hard to learn. It's available for Windows, Linux, OS X, and even mobile. Ditto for GTK+ 3: Vala is beautiful, practically C#, and good enough for at least the UI layer of your app, if not for the whole thing. Qt and GTK+ are both open source and LGPL, which means you can freely link to them even if you develop proprietary software. I just don't see such a need to make today's apps so bloated (and I don't consider "people have enough memory nowadays" a valid argument). If it's an one-off app made by a small team, or for fun, the trade-offs may be worth it. But for Slack, or Skype for Linux, or VS Code, wouldn't it make sense to put more developer time on it and have a much more performance-conscious application?

zwetan 10y ago

"Adobe’s AIR system enabled developers" it still does, AIR v1.0 was in 2006, we are now at v23.0 Electron is nice but a whole browser engine is a big bloat, you can easily reach 150MB. Not to go into a debate JS vs AS3, but the AIR runtime have a lot of advantages : AS3 the language is one, the default native API cover a lot of ground, being able to extend those native functionalities with ANE (ActionScript Native Extension) is nice too. I don't buy the kool-aid that you could use the exact same HTML5/CSS/JS code for both the browser and a desktop app, unless the app is trivial you gonna have to build your UI/UX specifically for the desktop with all the different subtleties between different OS. So sure you can use something like Electron to easily wrap an already existing web app for the desktop but imho either you are limiting the desktop features you could add or you will soon end up having 2 code base: 1 for the web and 1 for the desktop and that require more resources than just "wrapping it up for the desktop".