> 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.
- 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?
All of the above. If your application can be designed as a web application, you can use responsive designs and progressive enhancement techniques to create an experience that works across any platform with a web browser - with one code base. This is a pretty amazing thing, and for various business-related reasons this may seem like the right move.
> 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.
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.
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 ].
...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.
Yeah I find the "hackability" question really interesting. It is incredibly neat that I can hit a few keys in a browser and get an editable live source of what I'm looking at which is, to some extent, declarative and easily mappable from source to output. Yes, this is less true as more sites rely heavily on minified javascript for all of their implementation, or incomprehensible (to me) css that hides or moves things around in non-obvious ways, but it still mostly works. I definitely can't think of any commonly used native apps that are so easy to inspect and edit! Interestingly, though, I think you lose all that with something like Electron. At least, I don't know how to do that in eg. the native Slack client.
> "Full-native development unique on each platform is considered too much effort, when you can get a cross-platform app with Electron"
Yes, it's this. Full native development is awful since every platform is completely different, and other cross-platform solutions like Qt are a bit behind the web in terms of modern look and feel and developer base.
But Electron is also awful, since a hello world app uses 100mb of RAM.
Desktop GUI app development is horrible... meaning it's slightly worse than mobile GUI app development. GUI development in general is a horrid ghetto where your choice is between bad and completely proprietary.
I guess I believe it is common that if a platform becomes popular enough for developers - solutions will appear to allow them to reuse their knowledge in developing applications outside of their original target platform.
Furthermore in the attempt to woo developers from one popular platform to another a myriad of solutions will appear to allow the developer to move their existing tools, methods, and general knowledge from their comfortable and familiar platform onto the new one.
I'd suppose anyone that has more than 5+ years experience and has moved between at least two types of platforms can point to examples in their mind.
Personally I dislike this habit of using tooling to solve platform movement and escape the time constraints inherent in learning to develop for a new platform; I can however see the attraction, because, it really does ease time and effort in learning something new even if to provide this easing it acts a buffer to any deep understanding of the target platform.
Part of it is also, custom looking UI, not confined to the platform widgets, is not easy to do on many of the desktop platform libraries. It is incredibly easy to do with HTML/CSS.
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...
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.
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:
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.
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.
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.
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.
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.
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...
> 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.
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?
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.
> "...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?
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.
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".
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.
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.
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/), as well as offline first apps.
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.
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.
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.
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.
[+] [-] simula67|9 years ago|reply
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
[2] http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
[3] http://atom-morgan.github.io/in-defense-of-douglas-crockford
[4] https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...
[+] [-] niftich|9 years ago|reply
- 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?
[+] [-] t1amat|9 years ago|reply
[+] [-] kartan|9 years ago|reply
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.
[+] [-] haddr|9 years ago|reply
[+] [-] dccoolgai|9 years ago|reply
...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.
[+] [-] sanderjd|9 years ago|reply
[+] [-] api|9 years ago|reply
Yes, it's this. Full native development is awful since every platform is completely different, and other cross-platform solutions like Qt are a bit behind the web in terms of modern look and feel and developer base.
But Electron is also awful, since a hello world app uses 100mb of RAM.
Desktop GUI app development is horrible... meaning it's slightly worse than mobile GUI app development. GUI development in general is a horrid ghetto where your choice is between bad and completely proprietary.
[+] [-] bryanrasmussen|9 years ago|reply
Furthermore in the attempt to woo developers from one popular platform to another a myriad of solutions will appear to allow the developer to move their existing tools, methods, and general knowledge from their comfortable and familiar platform onto the new one.
I'd suppose anyone that has more than 5+ years experience and has moved between at least two types of platforms can point to examples in their mind.
Personally I dislike this habit of using tooling to solve platform movement and escape the time constraints inherent in learning to develop for a new platform; I can however see the attraction, because, it really does ease time and effort in learning something new even if to provide this easing it acts a buffer to any deep understanding of the target platform.
[+] [-] st3v3r|9 years ago|reply
[+] [-] rzzzt|9 years ago|reply
[+] [-] jsprogrammer|9 years ago|reply
I don't get why people don't understand its popularity.
HTML lets you put boxes on the screen and CSS lets you paint-by-number(id/name/selector).
If you aren't doing any of those things, I am very curious to know what exactly you are doing.
[+] [-] rplst8|9 years ago|reply
[+] [-] raquo|9 years ago|reply
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.
[+] [-] wpietri|9 years ago|reply
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
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.
[+] [-] onion2k|9 years ago|reply
[+] [-] jaquers|9 years ago|reply
[+] [-] segmondy|9 years ago|reply
[+] [-] dismantlethesun|9 years ago|reply
[+] [-] catnaroek|9 years ago|reply
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.
[+] [-] doublerebel|9 years ago|reply
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.
[+] [-] gpderetta|9 years ago|reply
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...
[+] [-] aikah|9 years ago|reply
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.
[+] [-] tonyedgecombe|9 years ago|reply
[+] [-] hota_mazi|9 years ago|reply
That's not saying much since Linux is pretty much nonexistent on the desktop.
[+] [-] sidlls|9 years ago|reply
[+] [-] thegeomaster|9 years ago|reply
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|9 years ago|reply
[+] [-] bluetidepro|9 years ago|reply
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?
[+] [-] abc_lisper|9 years ago|reply
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...
http://rhodesmill.org/brandon/2012/js/
http://dorey.github.io/JavaScript-Equality-Table/
https://www.destroyallsoftware.com/talks/wat
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|9 years ago|reply
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|9 years ago|reply
[+] [-] doublerebel|9 years ago|reply
When a business needs to deploy to several platforms at once, it's a quick and success-proven model that still has good performance.
[+] [-] mamcx|9 years ago|reply
Is possible to have a more lean setup?
[+] [-] jesuslop|9 years ago|reply
[+] [-] mxuribe|9 years ago|reply
[+] [-] coldcode|9 years ago|reply
[+] [-] dan_ahmadi|9 years ago|reply
[+] [-] seibelj|9 years ago|reply
[+] [-] rjbwork|9 years ago|reply
[+] [-] knodi|9 years ago|reply
[+] [-] dboreham|9 years ago|reply
[+] [-] xkcd-sucks|9 years ago|reply
[+] [-] ndepoel|9 years ago|reply
[+] [-] r00fus|9 years ago|reply
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
[+] [-] halayli|9 years ago|reply
No one wants to maintain a web app, mobile app, and desktop app separately.
[+] [-] zeppelin101|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] jjtheblunt|9 years ago|reply