
JavaScript Conquered the Web, Now It’s Taking Over the Desktop - nreece
https://www.wired.com/2016/05/javascript-conquered-web-now-taking-desktop/
======
simula67
> 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-48d4011b...](https://medium.com/@ericclemmons/javascript-
fatigue-48d4011b6fc4#.gc226gtmp)

~~~
alexwebb2
I can't believe this is the top comment. Let's go point by point:

1) JavaScript has its warts and its gotchas like anything else (okay, maybe a
few more). So what? Spend 50 hours building _anything_ substantial with
JavaScript and you'll get a good handle on them, and you'll be good to go for
the next 10,000 hours. Same goes for just about any other language. Focusing
on the weird edge cases might make for a nice blog post, but it's not relevant
to people actually building things day to day.

2) Growing pains in a very active community? Unheard of! Okay, so this was
embarrassing and disappointing, but at least it's been dealt with. You can
keep pointing to it if it helps your argument, but that doesn't make it valid.

3) I don't really understand what point you're trying to make here.

4) Again, very active community. Lots of churn. Plenty of reinventing /
rediscovering the wheel. If that _really_ bothers you and you're struggling to
separate the signal from the noise, I at least understand and respect that
criticism. I don't think that's a reason for anyone to stoop to the level you
have, though.

~~~
zeveb
> Spend 50 hours building anything substantial with JavaScript and you'll get
> a good handle on them, and you'll be good to go for the next 10,000 hours.

Spending 10,000 hours building things with JavaScript sounds like a pretty
good definition of Hell.

JavaScript is an actively, abusively bad language. It's not that it has a few
warts: it's nothing but warts. Its fundamental design flaws are obscured only
by its superficial design flaws.

It's a _really_ bad, tasteless language.

> I don't think that's a reason for anyone to stoop to the level you have,
> though.

I really don't think he 'stooped' to anything.

~~~
seagreen
In case Eich reads your comment: given that it had to be done in ten days and
"look like Java", JavaScript is a fine langauge.

(But yeah, compared to languages that were designed over years obviously it's
incredibly bad.)

To quote Eich (from here[1]):

" Ten days to implement the lexer, parser, bytecode emitter (which I folded
into the parser; required some code buffering to reorder things like the
for(;;) loop head parts and body), interpreter, built-in classes, and
decompiler. I had help only for jsdate.c, from Ken Smith of Netscape (who, per
our over-optimistic agreement, cloned java.util.Date -- Y2K bugs and all!
Gosling...).

Sorry, not enough time for me to analyze tail position (using an attribute
grammar approach:
[http://wiki.ecmascript.org/doku.php?id=strawman:proper_tail_...](http://wiki.ecmascript.org/doku.php?id=strawman:proper_tail_calls)).
Ten days without much sleep to build JS from scratch, "make it look like Java"
(I made it look like C), and smuggle in its saving graces: first class
functions (closures came later but were part of the plan), Self-ish prototypes
(one per instance, not many as in Self).

I'll do better in the next life. "

[1] Edit: jwz.org intercepts HN links. See mjgoeke's comment.

~~~
mjgoeke
I'd recommend copy+pasting the link to www.jwz.org if you want to open it...

    
    
      https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/#comment-1048

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

~~~
dccoolgai
What makes JS more "hackable"? Someone find that cartoon about the gaunt-
looking guy and the laid-back kid when the girl asks them to hold her coffee
and link it [edit:
[http://i.imgur.com/76Wtthy.jpg](http://i.imgur.com/76Wtthy.jpg) ].

...Because it gets the hell out of they way and holds your coffee for you and
doesn't slap it out of your hand and throw a tantrum because it _was actually
a medium coffee_...and it gives you the simplest no-BS object/array literals
you can get...IMO opinion everyone wailing and beating their chest bemoaning
the fact that JS got where it is fails to understand that it got there because
it the "UX" of coding JS is just a lot more pleasant - and you can treat it as
a compile target and do your work in a more type-obsessed thing like
Typescript if that's your cup of tea without imposing on the underlying
"hackability" of the language.

~~~
zeveb
> it gives you the simplest no-BS object/array literals you can get

I really don't think that:

    
    
        {
          "foo": "bar",
          "baz": ["quux", 1, true]
        }
    

is simpler than:

    
    
        ((foo bar)
         (baz (quux 1 true)))
    

Quite the opposite, really.

~~~
akubera
Question: Can s-expression list-of-lists really be used to represent an
unordered map when it comes to operations like equality? Or rather, does one
simply use expectations/context to compare this object to, say

    
    
      [["foo", "bar"], ["baz", ["quuz", 1, true]]]
    

making it a non-issue?

~~~
zeveb
> Question: Can s-expression list-of-lists really be used to represent an
> unordered map when it comes to operations like equality?

With the right predicates, anything is possible _grin_

I think that context unavoidable: one can't just read a JSON value into a
generic data structure, or even into a typed structure: one has to apply the
types of one's business logic (e.g. 'user-id' must not only be a string, but a
string beginning with either 'E' or 'C'). In that context (pun intended), then
it makes sense for equality comparisons to be at the business-object layer,
not at the freshly-deserialised JSON object layer.

------
rplst8
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...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
raquo
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.

~~~
gr3yh47
Python would like a word with you about point 1)

~~~
raquo
Honest question – how do you build cross-platform application UI in python?

~~~
eyko
I'm not familiar with the Python ecosystem but I imagine there are bidings for
GTK, QT, or other UI toolkits. The same applies to most (popular) languages.
The claim that HTML/CSS/JS is the "only" truly cross platform stack is simply
not true.

The main hurdle that other languages faced was not having a _native_ UI. For
example, GTK on OSX or Windows did not feel native. Key bindings were often
not native. Similar story with Java (was it Swing?).

The HTML/JS/CSS combo has _exactly_ the same issue (it's not comparable to a
native GUI - Cocoa or whatever it is.

~~~
falcolas
> The main hurdle that other languages faced was not having a native UI.

Electron faces this same hurdle, but with a twist. It just doesn't care; it
picks a rendering target (the web) and simply uses it everywhere. Perhaps
that's the approach QT and others need to take as well: stop trying to match
Apple's UI on Apple, and Windows' UI on Windows.

~~~
mgkimsal
> stop trying to match Apple's UI on Apple, and Windows' UI on Windows.

Great idea, but make sure it at least looks/feels _good_.

I remember Swing stuff from the late 90s and... IMO the primary issue wasn't
so much that "it doesn't look like Windows" but that ... it was a very poor
experience.

Copy/paste/keys - yeah, that's an annoyance, but if the UI is clean, friendly,
easy to understand and be productive on, people can look past the differences
of the native host OS. Swing (and GTK and others) really don't provide a
'better' UX (imo).

------
doublerebel
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
More likely they see a lot of programmers who only know JavaScript and they
want to offer them something.

~~~
lloyd-christmas
Is that a bad thing?

~~~
tonyedgecombe
No, well programmers just knowing JavaScript is but catering to a wider
audience is a good thing.

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

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

------
abc_lisper
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...](https://abdulapopoola.com/2015/09/30/why-javascript-seems-to-get-
addition-wrong/)

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

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

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

------
jesuslop
because bytecode isn't slow enough

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

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

------
seibelj
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
IMO C and JS both stink. Give me statically typed, memory managed,
expressivity or give me death.

~~~
hood_syntax
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.

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

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

~~~
xkcd-sucks
JS is the cockroach of programming languages

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

~~~
halayli
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.

~~~
dragonwriter
> It has become the English of languages.

I'm pretty sure English is still the English of languages.

JavaScript might be the English of _programming_ languages, though.

~~~
Practicality
You win the pedantic award for today. :)

------
jjtheblunt
bologna.

