We also almost managed to let blind and other impaired people use their computers via OS-level accessibility settings and features so now we need to throw all that away :)
With all respect to leichzeit0 comment, IMHO, JS is an ugly language, with way too many pitfalls [0]. Even big boys [1] use CoffeScript to transpile into JS.
JS for cross platform desktop development may be an easy thing to manage, though it can become unusable and clunky super fast. You can spot JS desktop apps, just by the size of executable, which is at least 5-10 times bigger than you could expect (Spotify - 130MB). They have poorer performance, can drain your battery faster, and some OS native features/guidelines must be implemented in a custom way, or could not be implemented/used at all. Sorry, for my critical and conservative view, but it's just my opinion (probably due to annoyance of overflow of laggy (web)apps, riddled with complex JS, where it could be avoided).
I'm going to elaborate on your comment a bit because this infuriates me and I don't think people truly understand the reasons behind why web-apps-for-desktop generally suck and there's nothing you can do to fix it in yours.
Background: I'm the lead dev/UX on LXQt, a linux desktop environment (http://lxqt.org/).
First one that comes to mind is accessibility and consistency of interactions. Apps that do not respect a host of user settings because the devs don't even know they exist -- but on desktop frameworks, you get these for free. You find this on the web, too. People hijacking scrolling behaviour on websites, without a damn clue that not everybody is on a fucking iphone. You don't respect smoothscroll options, you don't respect autoscroll, you don't respect lines-per-tick, it's infuriating.
Zooming? What's that? Let me disable it for whatever hacky performance reason. Who zooms anyway, people who can't see well? FUCK EM!
There's a lot of those examples. Maybe one day I'll write about all of them. They infuriate me as both a user (who is used to some specific behaviour) and a UX guy.
Second reason is the performance. Both in executable size and general runtime performance, as you yourself mentioned. We, as engineers, spent a lot of time and effort working around all the design flaws of js and the web because it was the most pragmatic thing to do. But if you bring these problems with you on the desktop, you are doomed to lowering the quality of the experience we have on our machines. And the user won't understand why their battery now drains at twice the rate - they'll blame it on Lenovo's shitty hardware, so you can get away with it. sighs
And the final one is the direct consequence of lowering the barrier of entry. You often deal with worse quality code. Because of the reasons I cited above, serious devs work with different languages when dealing with the desktop.
There are better ways, that's the worst thing. Qt and QML are extremely productive, work well on mobile and don't have all of these issues. They also work on more platforms than you'd be able to enumerate. Don't get me wrong, I am a proponent of lowering the barrier of entry, and I want to bring the advantages of the web to the desktop. But you can't just move the web there, lest you get its serious flaws and throw away decades of good engineering and UX.
This! I don't particularly care what technology people use to write apps, so long as it works well. As others in this thread have said, you can immediately spot a web-app-pretending-to-be-native because it doesn't work well.
QML appears to offer the best of both worlds - I don't understand why it isn't more popular?
Qt's C++ heritage, I'd assume. That, and I really didn't like Qt Creator, when I last tried to play with it a few years ago. In addition, "package management" for libraries as per `npm` and it's ilk is a non-starter, though I believe there was something on HN attempting to fix that for Qt recently.
Qt's C++ heritage isn't any more relevant than WebKit's C++ heritage. I agree that the ecosystem needs to improve, but it's a bit of a chicken and egg problem.
But you don't get native UI with QML, and even with Qt it's not exactly "free."
I'm not advocating html-based desktop apps, but using native UI frameworks is not as straightforward as you make it sound and they are certainly not cross-platform. I just wish there was an easier way for developers to incorporate system behaviors into their apps. Even if it wasn't a cross-platform solution, being able to "opt-in" to these behaviors without having to adapt your whole app to a wonky framework would benefit everyone. I'd rather add native behavior to a custom opengl text input than having to deal with the web platform.
But I probably couldn't. And you might complain about "noobs," but the barrier to entry is probably one of the main reasons we get so much crappy software nowadays. On point: I just installed the latest Qt and opened a few QML example projects. The result? QML's text input won't recognize cmd-delete.
Out of interest, can you point me to some Qt apps that look and feel completely native on OS X? (In particular, I'd like to see ones that feel modern, and take full advantage of Core Animation for UI transitions.)
I'm not too familiar with OSX but on the "native" side you have Transmission, and on the "completely custom" spectrum you have various game launchers (such as the Battle.net launcher).
JS has an ungainly syntax, but then so do many other languages. I have been really surprised at how nice it is to work with a transpiler for JS (I do a lot of CS these days). One of my first jobs was working with CFront, which was a gigantic hassle so I was a bit apprehensive about moving to CS. Nevertheless I think it hits quite a nice sweet spot of giving you nice syntax but not being so different from JS that you forget what you're doing.
As for pitfalls, most languages also have pitfalls. The "this" convention in JS is downright weird, but I've actually used it to my advantage (admittedly only once). The only other thing I can really think of that is actively hostile is automatic coersion of various types.
The core of JS is actually quite small and elegant, though (IMHO). I really like the prototypical inheritance. Once you understand how it works, it is very flexible and easy to work with. It lacks a lot of explicit facilities, but it is usually very easy to implement them if you want.
The main thing JS lacks is decent standard library. The recent Ecma script standards are moving in the right direction, but it is slow progress (understandably).
I've worked professionally with FORTH, C, C++, Perl, C#, Java, Ruby, Go and probably a few more which I'm forgetting. When I'm programming in Coffeescript, I never feel like I'm missing out. When I'm programming in JS, I'm frustrated by all the parens and "function"s that I have to type, but otherwise quite content. I like types, though, so will probably checkout typescript or something similar one day.
If you pick a technology by the aesthetics of the language, I'm pretty sure you'll make a bad decision no matter what. Not you like in you, but in principle. :)
The code is clean if you write it well. Ugly code comes in all parentheses positions.
"JS is an ugly language, with way too many pitfalls."
IMHO it's ugly from 'within', just look at the JS truth table [1] and video I linked with the quote [2]. I just feel that I have no control of what I am doing with JS.
<rant>
It's quite a paradox, that new people to programming, can get start quick with JS, though are not repelled how easily you can shoot yourself in the foot with it. But maybe they just do not catch the errors..
I think we are getting into deep rant, though I want to say, that even I know this rule of JS (always use 3 equals, unless you know why you need 2) why not make double equal work as triple one?
What would help is if the Node.js foundation could ship a Node Runtime, similar to the CLR for each platform and then applications could use that. You know, dynamic linking like we've done forever.
Go and Node seem to be heading back to static linking.
Meanwhile Australia is getting left further and further behind. Our internet speed isn't increasing, yet webpages, games, movies and applications are getting bigger and bigger. Help!
I actually find that Spotify is a good example of a well made JS desktop app:
_ I used it on Windows, OSX and several Linux distros and really like the fact that the experience is the same everywhere.
_ No notable performance issues even with modest configs. It's been always usable in my experience.
_ Install size is on par with its competitors
_ Never noticed battery draining but I'll probably keep an eye out for this one now that you made me think about it :)
I really doubt that a normal user would notice a difference.
Concerning code maintenance, it would be interesting to hear the opinion of someone who worked on such a complex desktop hybrid app.
Coffeescript is a compiler/transpiler and Babel does a much better job of doing it, Javascript has all the requirements you want in the "Next Big Language", dynamic languages will have pitfalls, implementing type coercion and lexer/parser optimization are the reason for some of the "wat" stuff in that video, if the speaker made a a popular language like javascript he would have a better understanding of why some of those pitfalls end up existing
True. Popcorn Time is written with NodeJS. Hence it takes a very long time to install or upgrade (has to handle thousands of files) and has rather high CPU use at runtime.
Actually it's more like this: That ugly language called Javascript that everyone derided and said was "too shit and slow to ever write a Demo in" back in the 90s when all the "real developers" were writing server side scripts in Perl and left the frontend people to their own devices caught up with them. They kept pushing the boundaries, discovering things like XMLHttpRequest, and using that crap little language. Eventually big players like Google started throwing a lot of money at the problem and Javascript became usable enough to write apps in. The front end people that all the cool Perl kids derided needed something on the backend. They wern't going to touch Perl since by this time it was an old languishing dinosaur and there was a bad taste left in their mouth. And thus NodeJS was born. The frontend dev could write his server side stuff in the one language he knew.
This is my completely biased and highly selective history of events ;)
Except the perl kids weren't cool (I was one of them) because they didn't write c++, and they weren't cool because they didn't write assembly, and on on!
How about NodeJS bindings to a native desktop library of choice and a React.js backend to said library slipped in? They're decoupling the React API from the DOM, right?
But that's the point of React - providing an abstraction layer over the poor decisions that were made in creating the web.
Apart from Javascript, of course. But that particular "bad decision" is getting modified with every version into something more acceptable ("now with classes!").
I guess the endpoint is that React + Javascript (+ Redux) becomes the defacto language for developing UIs in, and what implements that abstraction layer is immaterial. React-native all the things!
I know I'm a nutter, but I like the type system :)
I like that there's "==" and "===", because that's exactly how I think. It fits my use case of "is this the same value as that?" or "is this really equal to that?" exactly.
I like that types are fluid, flexible and never get in my way.
But there's a religious war here that I think got won by the static type side, so I'm not going there again ;)
I see it as an initial step towards actual native code generation. I would rather use that than the likes of Qt QML if it actually produced native code.
Have you used Qt and QML? For me it's much more productive and straightforward than html/js/css. Delarative legible ui with built in dataflow/reactive properties. Performs straight out of the box without having figure out how to work with the mechanisms buried in this hugely complex and opaque machine called a browser. In fact its a relief to work with it. Could you say where you think its so 'horrible'.
Agreed. Assuming they took this to its full potential, and created native, cross-platform, desktop widgets for React, what they'd end up with would look startingly similar to QML, except without the easy C++ interop.
I'm a fan of React, but I have no desire to use it outside of the web, and maybe mobile (still on the fence there). For desktop, we have QT, which is truly an awesome native widget toolkit, with many thousands of man-years work in it, excellent cross-platform desktop coverage, along with pretty good accessibility standards.
Do you know of any modern OS X apps written with Qt that have a native look and feel that, in particular, take advantage of Core Animation for UI transitions?
All the Qt apps I have touched (Google Earth comes to mind) have neither looked nor felt native on OS X, much like Swing and SWT apps don't at all feel native. Whereas all the best apps are written in native Cocoa.
Although I've never had to start from scratch, the Qt projects I've maintained have been prone to crashing.
Maybe the Qt apps have legitimate bugs but the fact is that native environments like Objective-C, and most likely this JavaScript environment, would both handle those issues very cleanly compared to Qt.
Comments
Please forgive the simple question, but...
Why does this exist? Is creating desktop programs out of HTML code really a good idea?
Because NodeJS is popular and desktop apps were getting small and efficient so we crammed a 30MB Chrome runtime in there.
We also almost managed to let blind and other impaired people use their computers via OS-level accessibility settings and features so now we need to throw all that away :)
Crap, does Chromium-via-electron not advertise the correct accessibility things for Windows?
+1
With all respect to leichzeit0 comment, IMHO, JS is an ugly language, with way too many pitfalls [0]. Even big boys [1] use CoffeScript to transpile into JS.
JS for cross platform desktop development may be an easy thing to manage, though it can become unusable and clunky super fast. You can spot JS desktop apps, just by the size of executable, which is at least 5-10 times bigger than you could expect (Spotify - 130MB). They have poorer performance, can drain your battery faster, and some OS native features/guidelines must be implemented in a custom way, or could not be implemented/used at all. Sorry, for my critical and conservative view, but it's just my opinion (probably due to annoyance of overflow of laggy (web)apps, riddled with complex JS, where it could be avoided).
Probably it's the price of 'cross-platformity'.
[0] https://www.youtube.com/watch?v=20BySC_6HyY (original site does not load for whatever reason)
[1] https://github.com/basecamp/trix
I'm going to elaborate on your comment a bit because this infuriates me and I don't think people truly understand the reasons behind why web-apps-for-desktop generally suck and there's nothing you can do to fix it in yours.
Background: I'm the lead dev/UX on LXQt, a linux desktop environment (http://lxqt.org/).
First one that comes to mind is accessibility and consistency of interactions. Apps that do not respect a host of user settings because the devs don't even know they exist -- but on desktop frameworks, you get these for free. You find this on the web, too. People hijacking scrolling behaviour on websites, without a damn clue that not everybody is on a fucking iphone. You don't respect smoothscroll options, you don't respect autoscroll, you don't respect lines-per-tick, it's infuriating. Zooming? What's that? Let me disable it for whatever hacky performance reason. Who zooms anyway, people who can't see well? FUCK EM!
There's a lot of those examples. Maybe one day I'll write about all of them. They infuriate me as both a user (who is used to some specific behaviour) and a UX guy.
Second reason is the performance. Both in executable size and general runtime performance, as you yourself mentioned. We, as engineers, spent a lot of time and effort working around all the design flaws of js and the web because it was the most pragmatic thing to do. But if you bring these problems with you on the desktop, you are doomed to lowering the quality of the experience we have on our machines. And the user won't understand why their battery now drains at twice the rate - they'll blame it on Lenovo's shitty hardware, so you can get away with it. sighs
And the final one is the direct consequence of lowering the barrier of entry. You often deal with worse quality code. Because of the reasons I cited above, serious devs work with different languages when dealing with the desktop.
There are better ways, that's the worst thing. Qt and QML are extremely productive, work well on mobile and don't have all of these issues. They also work on more platforms than you'd be able to enumerate. Don't get me wrong, I am a proponent of lowering the barrier of entry, and I want to bring the advantages of the web to the desktop. But you can't just move the web there, lest you get its serious flaws and throw away decades of good engineering and UX.
This! I don't particularly care what technology people use to write apps, so long as it works well. As others in this thread have said, you can immediately spot a web-app-pretending-to-be-native because it doesn't work well.
QML appears to offer the best of both worlds - I don't understand why it isn't more popular?
Qt's C++ heritage, I'd assume. That, and I really didn't like Qt Creator, when I last tried to play with it a few years ago. In addition, "package management" for libraries as per `npm` and it's ilk is a non-starter, though I believe there was something on HN attempting to fix that for Qt recently.
Qt's C++ heritage isn't any more relevant than WebKit's C++ heritage. I agree that the ecosystem needs to improve, but it's a bit of a chicken and egg problem.
But you don't get native UI with QML, and even with Qt it's not exactly "free."
I'm not advocating html-based desktop apps, but using native UI frameworks is not as straightforward as you make it sound and they are certainly not cross-platform. I just wish there was an easier way for developers to incorporate system behaviors into their apps. Even if it wasn't a cross-platform solution, being able to "opt-in" to these behaviors without having to adapt your whole app to a wonky framework would benefit everyone. I'd rather add native behavior to a custom opengl text input than having to deal with the web platform.
But I probably couldn't. And you might complain about "noobs," but the barrier to entry is probably one of the main reasons we get so much crappy software nowadays. On point: I just installed the latest Qt and opened a few QML example projects. The result? QML's text input won't recognize cmd-delete.
Guess that barrier is a little too high.
Out of interest, can you point me to some Qt apps that look and feel completely native on OS X? (In particular, I'd like to see ones that feel modern, and take full advantage of Core Animation for UI transitions.)
I'm not too familiar with OSX but on the "native" side you have Transmission, and on the "completely custom" spectrum you have various game launchers (such as the Battle.net launcher).
JS has an ungainly syntax, but then so do many other languages. I have been really surprised at how nice it is to work with a transpiler for JS (I do a lot of CS these days). One of my first jobs was working with CFront, which was a gigantic hassle so I was a bit apprehensive about moving to CS. Nevertheless I think it hits quite a nice sweet spot of giving you nice syntax but not being so different from JS that you forget what you're doing.
As for pitfalls, most languages also have pitfalls. The "this" convention in JS is downright weird, but I've actually used it to my advantage (admittedly only once). The only other thing I can really think of that is actively hostile is automatic coersion of various types.
The core of JS is actually quite small and elegant, though (IMHO). I really like the prototypical inheritance. Once you understand how it works, it is very flexible and easy to work with. It lacks a lot of explicit facilities, but it is usually very easy to implement them if you want.
The main thing JS lacks is decent standard library. The recent Ecma script standards are moving in the right direction, but it is slow progress (understandably).
I've worked professionally with FORTH, C, C++, Perl, C#, Java, Ruby, Go and probably a few more which I'm forgetting. When I'm programming in Coffeescript, I never feel like I'm missing out. When I'm programming in JS, I'm frustrated by all the parens and "function"s that I have to type, but otherwise quite content. I like types, though, so will probably checkout typescript or something similar one day.
If you pick a technology by the aesthetics of the language, I'm pretty sure you'll make a bad decision no matter what. Not you like in you, but in principle. :)
The code is clean if you write it well. Ugly code comes in all parentheses positions.
What I meant:
IMHO it's ugly from 'within', just look at the JS truth table [1] and video I linked with the quote [2]. I just feel that I have no control of what I am doing with JS.
<rant>
It's quite a paradox, that new people to programming, can get start quick with JS, though are not repelled how easily you can shoot yourself in the foot with it. But maybe they just do not catch the errors..
</rant>
[1] https://dorey.github.io/JavaScript-Equality-Table/ [2] https://www.youtube.com/watch?v=20BySC_6HyY
The link you provided to demonstrate the problem also gives you the solution:
Tools like ESLint make it easy to enforce this (and to only allow == in the few cases where those good reasons apply).
I think we are getting into deep rant, though I want to say, that even I know this rule of JS (always use 3 equals, unless you know why you need 2) why not make double equal work as triple one?
If we were to rewrite history, that'd probably happen. Now count the number of languages that wouldn't reconsider something if we were able to..
I understand your frustration with js, but let's not pretend it's objectively worse to learn to deal with its pitfalls instead of other languages'.
Because JS makes a point of being backwards compatible. Which is great, because some people out there are still using IE6.
That's why I do all my coding in brainfuck. People can't tell if it's ugly or not.
What would help is if the Node.js foundation could ship a Node Runtime, similar to the CLR for each platform and then applications could use that. You know, dynamic linking like we've done forever.
Go and Node seem to be heading back to static linking.
Meanwhile Australia is getting left further and further behind. Our internet speed isn't increasing, yet webpages, games, movies and applications are getting bigger and bigger. Help!
I actually find that Spotify is a good example of a well made JS desktop app:
_ I used it on Windows, OSX and several Linux distros and really like the fact that the experience is the same everywhere.
_ No notable performance issues even with modest configs. It's been always usable in my experience.
_ Install size is on par with its competitors
_ Never noticed battery draining but I'll probably keep an eye out for this one now that you made me think about it :) I really doubt that a normal user would notice a difference.
Concerning code maintenance, it would be interesting to hear the opinion of someone who worked on such a complex desktop hybrid app.
Coffeescript is a compiler/transpiler and Babel does a much better job of doing it, Javascript has all the requirements you want in the "Next Big Language", dynamic languages will have pitfalls, implementing type coercion and lexer/parser optimization are the reason for some of the "wat" stuff in that video, if the speaker made a a popular language like javascript he would have a better understanding of why some of those pitfalls end up existing
True. Popcorn Time is written with NodeJS. Hence it takes a very long time to install or upgrade (has to handle thousands of files) and has rather high CPU use at runtime.
I wonder if it read from a tar file instead of individual files on slow (NTFS) filesystems it'd be faster.
That's the logic behind most games. They implement a package format (sadly usually their own) for the game files for fast access.
Actually it's more like this: That ugly language called Javascript that everyone derided and said was "too shit and slow to ever write a Demo in" back in the 90s when all the "real developers" were writing server side scripts in Perl and left the frontend people to their own devices caught up with them. They kept pushing the boundaries, discovering things like XMLHttpRequest, and using that crap little language. Eventually big players like Google started throwing a lot of money at the problem and Javascript became usable enough to write apps in. The front end people that all the cool Perl kids derided needed something on the backend. They wern't going to touch Perl since by this time it was an old languishing dinosaur and there was a bad taste left in their mouth. And thus NodeJS was born. The frontend dev could write his server side stuff in the one language he knew.
This is my completely biased and highly selective history of events ;)
Except the perl kids weren't cool (I was one of them) because they didn't write c++, and they weren't cool because they didn't write assembly, and on on!
Server-side JavaScript was a thing in the 90s with Classic ASP.
They discovered a documented browser feature? Hooray for that.
Yep. If this is the only thing stopping native apps from disappearing completely then it's probably a good thing.
How about NodeJS bindings to a native desktop library of choice and a React.js backend to said library slipped in? They're decoupling the React API from the DOM, right?
Yeah, react-dom is a separate package now.
This is the question I was going to ask. It seems like porting many of the poor decisions that were made in creating the web to native desktop.
But that's the point of React - providing an abstraction layer over the poor decisions that were made in creating the web.
Apart from Javascript, of course. But that particular "bad decision" is getting modified with every version into something more acceptable ("now with classes!").
I guess the endpoint is that React + Javascript (+ Redux) becomes the defacto language for developing UIs in, and what implements that abstraction layer is immaterial. React-native all the things!
True, but it definitely seems like they're only fixing the low-hanging fruit. They're never going to fix the insane type system.
I know I'm a nutter, but I like the type system :)
I like that there's "==" and "===", because that's exactly how I think. It fits my use case of "is this the same value as that?" or "is this really equal to that?" exactly.
I like that types are fluid, flexible and never get in my way.
But there's a religious war here that I think got won by the static type side, so I'm not going there again ;)
You're probably not familiar with Atwood's Law[0]:
[0]: http://blog.codinghorror.com/the-principle-of-least-power/
I see it as an initial step towards actual native code generation. I would rather use that than the likes of Qt QML if it actually produced native code.
web-based apps; like Spotify?
Because working with things like GTK and QT is horrible compared to working with HTML/JS/CSS, for anything other than trivial things.
That said, it'd be cool to have native code generation from this though.
Have you used Qt and QML? For me it's much more productive and straightforward than html/js/css. Delarative legible ui with built in dataflow/reactive properties. Performs straight out of the box without having figure out how to work with the mechanisms buried in this hugely complex and opaque machine called a browser. In fact its a relief to work with it. Could you say where you think its so 'horrible'.
Agreed. Assuming they took this to its full potential, and created native, cross-platform, desktop widgets for React, what they'd end up with would look startingly similar to QML, except without the easy C++ interop.
I'm a fan of React, but I have no desire to use it outside of the web, and maybe mobile (still on the fence there). For desktop, we have QT, which is truly an awesome native widget toolkit, with many thousands of man-years work in it, excellent cross-platform desktop coverage, along with pretty good accessibility standards.
Do you know of any modern OS X apps written with Qt that have a native look and feel that, in particular, take advantage of Core Animation for UI transitions?
All the Qt apps I have touched (Google Earth comes to mind) have neither looked nor felt native on OS X, much like Swing and SWT apps don't at all feel native. Whereas all the best apps are written in native Cocoa.
Although I've never had to start from scratch, the Qt projects I've maintained have been prone to crashing.
Maybe the Qt apps have legitimate bugs but the fact is that native environments like Objective-C, and most likely this JavaScript environment, would both handle those issues very cleanly compared to Qt.
You clearly never programmed in Qt.
Did you mean the other way around?