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.
Man it's great to see effort being put into a platform-sensitive React component set. We've been working on React components for N1, and it'd be cool to swap them out for an open source set one day. The thing is, I'm not sure 100% native appearance is the way to go. I think Spotify nailed a cross-platform desktop experience using a UI that is distinctly non-native.
For folks just learning about Electron / web-based desktop UI — we gave a talk about UI considerations at the Bay Area ElectronJS meetup last month: https://www.youtube.com/watch?v=JIRXVGVPzn8
Round 1: AWT. Uses the native widgets. Therefore the layout is slightly different on different platforms.
Round 2: Swing. Cross-platform identical, and therefore looks nothing like native apps. You could 'skin' it, at which point it would look native but behave subtly differently.
Round 3: SWT. Back to native widgets for Eclipse.
Round 4: Everyone throws up their hands in despair and stops writing desktop applications.
Indeed. If cross-platform UI toolkits have shown us anything, it's that cross-platform UI toolkits are a bad idea.
You end up targeting the lowest common denominator, and a UI convention that works on Windows won't work on OS X, and vice versa.
One big error made by these toolkits is to base themselves on generic pixel-oriented layouts, instead of more abstract declarative ones. For example, if you need a dialog box with a small form and "OK" and "Cancel" buttons, you'd lay each component out on a form, and the layout would be identical on each platform. But this is such a common thing to do that it would be better to just declare what fields should be visible and what actions should be available, and have different, platform-specific, opinionated adapters that can wire together a native UI from this metadata (together with some platfomr-specific, CSS-like hinting: "on OS X this field needs to be at least 500px wide", etc.).
There's a wide selection of common idioms (dialog boxes, file dialogs, "wizards", preference panes, alerts, etc.) that fit into this scheme. The reason nobody did this is probably because developers overestimate how important it is to micromanage the UI, and don't think a system like this could support all variations that apps need. In truth, most UIs are quite pedestrian, and could benefit from being driven by a high-level description.
This is where React (and React Native) actually would help, because the component interface is separate from the component implementation. You can have a fairly high-level mostly-declarative description of your app that pulls in platform-specific versions of certain UI widgets where it makes sense to have one, but otherwise relies on generic ones.
Java was captured by "Enterprise", lending it an air of radioactive uncoolness. So people are very reluctant to look at it and risk learning something from its successes and failures.
Came here to say this. For quite a few years in the bad old days around Y2K, people thought they would get a free cross-platform lunch by writing GUI applications in Java. This wasn't so bad in Xwindows, where every program did its own thing already, but it was terrible everywhere else. It took years for developers to get it, and there are probably still a few internal corporate applications using Java; I suspect the same will happen over the next 5-10 years with JS.
I think part of the reason that it might be different this time round is because using web technologies for desktop applications gives access to a much broader pool of UI/UX talent to help build something that works well and looks nice. Applications built with web technologies are already looking noticeably better than anything you get with a cross-platform UI toolkit without putting in a lot of effort.
The components look nice but they're not really native like I had initially thought. Are these necessarily better or different than existing styles that reproduce these components?
Anyway, I would love to see these come in native form like reactive-native.
I would guess that it does not interact with accessibility now.
These components are just bunch of styles to make it look like a 'native' widget, though it's not a real native widget of OS.
Though, it leaves me with a question, how can you set up OS X accessibility features, in your web app/UI, that it could be used by OS X? I would guess you can't, and it's all left to the browser.
WebKit supports ARIA attributes. If you aren't using them in your web code already, VoiceOver can probably navigate your page just fine, but it's subpar compared to a document that has been marked up with rich accessibility information.
It's cute and I can see the appeal but I think that even if you are making a "desktop app" that has its own executable, you are better off just using nice HTML. It will be cross-platform, it will probably look nicer (imo, the desktop-style looks somewhat dated). And most importantly, it won't confuse users when it doesn't behave as expected. Getting hotkey behavior etc right is hard, if not impossible -- some things change with international settings and some key combinations are unavailable to the browser anyway.
We've seen these countless times before. Trying to recreate native UI in web technologies is a lost cause in my book.
I think what you've got here for an OS X implementation is pretty good, but I can still tell that it isn't really native, and if an OS update changes anything in regard to the standard UI components forget about it.
Why not design and develop your own UI? That way you can control how it is supposed to work given the drawbacks and advantages of web technologies and not have to ask the user for forgiveness of minor quirks in your reimplementation.
As long as we're just talking about skins and not true native desktop behavior, I'd like to see someone port such nice styles to FLTK [0] boxes. FLTK moves you back to C++ bindings relative to an Electron-based solution, but you'd get the same "looks native but not really" and layout portability tradeoffs in a tiny, undeniably mature library.
I could see this being used in a desktop app using Chrome Embedded Framework or some embedded browser framework. Even if you are using HTML to generate views for your Desktop app, it could be very useful to use native-looking widgets to blend in.
