Historically, I have found that dismissing an otherwise effective technology due to performance is a bad idea. Fifteen years ago I dismissed Java in favour of C++ because at the time the JVM was about 25 times slower than native. Now I regret not investing more time learning Java. I suspect the same will be true of HTML/JS apps in the next few years. Hardware and performance improvements will likely erase any differences.
I also dismissed Java for a long time until a few years ago when I developed a mobile project in Java and unfortunately did encounter over-architecting and lack of interest in performance as expected. On the other hand, I can't say I disliked using the language, even if I found it quite restrictive. Java is a pragmatic tool, it's not about fun or expressiveness but making a team of average or better engineers build something that works. And it does that very well.
Now that I've had that experience, I know it's not for me, but I can understand when a tool like Java makes sense.
JavaScript vs anything else is not the same as C++ vs Java, because JavaScript is not an effective technology to build software applications in. It never was and likely won't become one.
It has a weak type system and non-existant standard library. Must be run in a packaged browser. Anything UI-related must be done by using a document markup language and style sheets. The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top.
Dynamic typing is useful. The "native" Objective-C is dynamically typed, for example. Static typing is useful too. If history has shown anything, it's shown that both dynamic typing and static typing have their places, and trying to argue that one is superior to the other in all circumstances is one of the most boring arguments imaginable.
> non-existant standard library
This is more or less a deliberate design choice, because there are many implementations of JS and that multiplies the probability of incompatibility. Consider the headaches that have arisen between Microsoft's STL and GNU's STL...
> Must be run in a packaged browser
Node? This is obviously false.
> Anything UI-related must be done by using a document markup language
It's an effective retained mode tree of nodes, with a whole lot more optimizations than any native toolkit I know of. (Look at how the childNodes array is implemented sometime, for example; no native toolkit does the kind of caching that browsers do...)
> style sheets
Style sheets are a great idea. They're becoming increasingly popular for native development nowadays (Qt, GTK, etc.)
> The fact that any app developed in it is guaranteed to be inefficient and sluggish is just the cherry on top.
I'm as much of a critic of current browser design as anyone, but this is mostly the fault of old browser designs. The Web platform has a lot more potential for performance than things like the Win32 API, as I've elaborated on in many other posts.
It's useful, but when that's the only tool one has, it becomes a liability. I like using both JS and Python where it makes sense, but building a medium-sized or large app in such languages is asking for trouble.
Some teams make enough of an effort that they are able to deliver such an app. That should not be encouraged, but rather criticized as encouraging development practices. To be clear: they can do whatever they want in their projects. I have a problem when they recommend such methods to others, without being honest about the pitfalls and effort involved.
Re standard library: the STL is currently working great! JS would kill to have something as stable and high quality as the STL.
Re node: I am not aware of any desktop or mobile apps using node. Isn't that a server-side technology?
Re markup: does it matter how much optimized it is and how much caching it does when in the end it's still slow?
Re style sheets: they're great when used for styling, like in Qt (not sure what GTK is doing). But that doesn't scale when building widgets and doing positioning.
pcwalton, web apps have had the potential to do X, Y and Z better than native apps for the past decade. At one point web developers need to talk less and deliver.
> I like using both JS and Python where it makes sense, but building a medium-sized or large app in such languages is asking for trouble.
There have been tons of reliable large apps written in dynamically typed languages. This is, again, a tiresome argument.
> the STL is currently working great! JS would kill to have something as stable and high quality as the STL.
The STL took nearly a decade to get hash tables. And for years, users suffered from Microsoft and other vendors taking very different approaches to template expansion, causing no end of ifdef hell. JS never had such issues.
> But that doesn't scale when building widgets and doing positioning.
Huh? How does flexbox "not scale"? Positioning is just one aspect of style.
> At one point web developers need to talk less and deliver
I've been working on browsers for 7 years, and on most of those weekends, thanks.
The tide seems to be turning against dynamic languages because developers are getting tired of the poor performance, fragility and maintenance difficulty. We just needed to see some innovation in the static typing camp: the transition from Objective-C to Swift is a great example.
A typical app can be made pretty reliable with enough testing effort and a good process, so I'm not surprised that large apps have been written in dynamically typed languages,
although I am now curious which apps you had in mind. Can't think of anything the scale of e.g. Photoshop, Oracle or Linux.
Re STL: Really? :) I'll take missing hash-tables (dictionaries are fine) any day over no library.
I don't know which period you're referring to with the ifdef hell, but at least for the past decade I can't think of any STL compatibility issues. Perhaps you can be more specific here?
In any case, JS never had such issues because back then it was being used to make text blink. Now that it's facing more challenges we start seeing the issues.
Re working on browsers: you're not a web developer. I will say though that Mozilla pushing this web-everything agenda is disappointing. The FirefoxOS lesson has not been learned...
15 years ago, I believed that one day, generational garbage collection would be so good that I wouldn't have to think about it. I'm no longer holding my breath for that day.
Yes! Right now Electron is the easiest way to build cross OS desktop apps, bar none. Just like Java was the easiest way to write cross platform code back then.
Dismissing it for performance reasons is a fool's errand. The performance issues are fixable and we're already seeing them get fixed.
Bold prediction - JavaScript(or rather, a future incarnation of it resembling es7/es8) will be the lingua franca for all platforms(web, desktop, and mobile) within a decade.
