Another case in point is slack app. On Linux, it is probably the worst app. :(
When no javascript is running the app consumes effectively no power.
Now that being said there's nothing to stop developers from running lots of expensive code or being non-performant with rendering. This is true in any environment. However; having access to the type of flame-charts and profiling tools that come with Chrome / Electron go a really long way to addressing some of these issues.
I work at Nylas and we've been heavily focused on reducing the amount of power the app consumes. We've still got a lot of work to do, but at the end of the day processing a ton of email quickly is a fairly expensive operation.
In the long run it's possible to offload very expensive work to natively compiled modules. A lot of Electron projects do this and can use Node's native bindings to connect to processes that really need to be fast in native code.
Citation needed. Battery life with Safari on Mac or IE/Edge on Windows is easily twice that of Chrome/Chromium with the same tabs open.
Note: I'm not disputing that the Chrome team has put in significant effort, but rather that the results are anything above mediocre at best.
So if Nylas is parsing imap messages then both parsing and rendering difference between a native and eletron app will be big. Fortunately browsers workaround some of this problem by consuming json and stuff - formats browsers can natively parse.
http://www.sabah.net.my/manuals/en/nscomm/images/messwin.gif
[1] - http://i.imgur.com/0eLhrAM.png
[2] - https://raw.githubusercontent.com/chergert/gnome-builder-web...
I guess I found a replacement for Thunderbird.
There was an amazing mail client for (of all things) FidoNet back in the 90s called GoldEd that was amazing. It had threaded message display, a great editor, pleasant colors, etc. It was tailored to that network, however. Would love to find something like this for console-based email that has the built-in editor and isn't Pine.
I obsessively measure wakeups/s in powertop for every application I use, and the above setup is very good.
If you want to try other things you can look into the mutt-kz fork (which replaces internal search commands with notmuch).
There is also a notmuch curses client, but I find mutt+notmuch superior.
Mu is a notmuch alternative worth considering. Their emacs client is excellent.
Finally, also if you use emacs, gnus is perhaps the most powerful email client ever. Steep learning curve, though. It's a bit different to everything else, as gnus has been built as a news reader. It treats mail as news, but this has some great advantages I think, as long as you can adapt your mindset. Also Org integration.
Gnus is the only thing that might make me switch away from mutt.
For my reduced email needs, I mostly use K-9 Mail (Android) and self-hosted RainLoop (web). For work mail I use Outlook.
One day someone will build a good Electron app.
Visual Studio Code is very good in my opinion. It can be done.
VS Code is not 'a very bad app'. If you know of a comparable app that uses fewer resources to a significant degree please let us all know and I'm sure we'll all switch.
Built in debugger is just one example that makes Vim not comparable to VS Code: https://code.visualstudio.com/Docs/editor/debugging
Every time I try to get someone to explain it to me I'm just met with a bunch of empty answers like "Yeah it just flows really well man". It seems like the JavaScript Everywhere fad came into being solely to fulfill the need of a lot of novices to feel smug and important against more reasonable people, who are just left with puzzled looks.
Keep in mind I don't agree with the above at all, but this is what a lot of people believe.
PHP would like a word.
Until recently, and I know the "front-end devs" are going to have my head for this, but until recently, there was hardly any serious JavaScript coding going on even on the client-side. That means it wasn't something that a new developer would really stumble across and just start using to build full-fledged programs.
JavaScript's main use was extending web widgets to do things slightly more conveniently. All the heavy lifting would be behind the scenes and JavaScript would watch you type so it could autotab for you. So I don't think the explanation that there was a vast knowledgebase eager to break into the backend is plausible.
JavaScript was so disliked from horrifyingly frustrating exposure throughout the IE6 days that no one would go near the thing unless they were wrapped in the jQuery condom. John Resig was a hero of legendary bravery for biting the bullet and making JavaScript semi-usable.
Someone had to write a book called "JavaScript: The Good Parts" that openly acknowledged JavaScript's inherent inferiority but tried to cheer us up by saying "Hey, I know we're stuck with this because browser vendors will never be able to agree on something else, but there are some hidden cool things about it! Don't cry!"
Somehow in the last 5 years or so, JavaScript has gone from something that required a prophylactic device before anyone would approach it to something that real companies are writing production _DESKTOP_ applications in. What the heck happened?
(I think The Good Parts is probably the real turning point here, where it became OK to treat JavaScript as a non-joke, and that V8 accelerated it. But people took Crockford's feel-good apologia and ran way past the finish line with it.)
They will then naturally choose the convenient-for-them known quantity and dismiss concerns regarding usability, performance, etc.
I don't see a real trend toward building apps using web technologies, but there is a lot of noise, making the topic seem larger than it is.
I wish exist a native renderer that could use a (saner, better) subset of html/css that fit the same use case, then let us use any better language for the logic.
Probably OpenGL toolkits are the idea, but it way to operate and looks are weird.
Qt perhaps is holding up the best, but I can see why people prefer Javascript's event model to Qt's.
Pointing out that old toolkits still exist doesn't necessarily help when people expect more from their toolkit now.
It can't be performance, because Electron is slow. It's not conservative power usage, because browsers are power hungry. It's not disk space or memory usage either.
Nor is it a native-looking UI. Nor security. Nor privacy. Nor accessibility.
The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new.
NPM, even if it has plenty of do-not-use-that-packages crap, is still far more furnished that Qt will ever be, for example.
> The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new.
One could say the same for the typical Qt developer that refuse to get serious in learning the web platform.
By comparison web front end devs tend to cling much more tightly to their favored language+toolchain, taking it with them to every platform they decide to develop for.
Ignoring arguments, aggressive advocacy, "you too"s, asserting that web technologies are great in the face of so much evidence to the contrary and most of all, insisting to use the same inadequate tools for everything from desktop to mobile to embedded.
I've been having the same discussion for six years with different characters now. One thing has never changed - web apps consistently show poorer quality than their native counterparts, especially in performance, resource usage and usability.
The software this community so focused on PR and advocacy is building is not good in spite of the bragging.
And regarding your arguments:
* Java, C++, .NET, Python, etc can claim having ecosystems. JS has a continuously churning collection of libraries. Nothing has been forgotten.
* a lot of Qt developers use it where it makes sense by bulding hybrid apps or together with QML.
Don't get me wrong, I'm actually a nice guys who has nothing against Qt/C++. I'm glad it exists because I can use it when what matters is power usage, native looking UI, security, privacy and all. It's just that I don't, personnaly, need those requirements.
> The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new
I'm sorry but this is simply wrong. And I think you don't need to show disregard to "typical web developers" when you're trying to make a point.
What do you choose when you need to quickly throw an MVP in front of a customer? Surely not C++/Qt (well, maybe yes if that's the only platform you master).
When you need a web-looking UI ? Not C++/Qt.
When you need to easily deploy on hundred's of windows workstations at a plant where IT is blocking you from installing anything on said workstations? A web app, not a C++/Qt client.
So, you see, maybe the web platform also has it advantages when you start looking outside of what you do everyday for a living.
Gtk has been ported to macOS in 2007. You don't need an X server anymore :)
Does it support hi-DPI yet?
This has not been true for years now. There is a native port of Gtk that does not require an X server. Gimp is available natively, as are other Gtk apps (Gnucash, Deluge, etc).
Not get me wrong, I don't like much JS/html apart as be hostage as everyone else to use it in the web, but is clear that as far to build the GUI is way more enjoyable than most GUI toolkit.
It can't be that web developers have been bitterly complaining about how poor HTML and CSS are at building UIs for years and years and suddenly it's become easy and enjoyable.
Actually it has become easy and enjoyable ;) Even for complex UIs.
Just think seriously about what a stack like es6/React/Redux brings on the table against plain old ES5, and you'll be struck by how well things have become.
Totally granted, the web platform suffer from a very bad reputation. And what does not help at all is that one need to carefully choose his tooling among a zillion of short-lived, hyped github repos.
But there is future-proof gems for those who invest the time in trying and learning. In a jumble: React, Redux, Reagent, Re-frame, Typescript, Clojurescript, Om, Immutable.js, Om.next, and so on.
Of course it's not.
> There is no reason to use JavaScript just so you can get a "cross platform GUI".
The main reason (imho) is that "JavaScript" (as you call it, but you should say "the web platform") is more future proof than "old toolkits".
Qt would be the best candidate for a "cross platform GUI", but you are relying on the [Qt company/nokia/whatever] for its continuation.
When you choose html/js you choose a standard used by virtually every single person with a computer nowadays. There is far less chance that html/js will be killed someday, like Microsoft killed WPF or like IBM made SWT an abandonware, because nobody is in that position and this whole World Wide Web thing rely on it.
How can JS be more future-proof than old UI toolkits when JS libraries and frameworks are constantly changing? Sure, nobody will kill HTML and JS, but that's not the point. Nobody knows how UIs will be built with web technologies in two years!
Edit: based on your reply below, it looks like I have to spell it out. GUIs are built with UI frameworks, not just with programming languages and markup languages. JS frameworks are so short-lived that one can't be sure if their code will still work in one year.
That is the opposite of future-proof.
Yes, it is the point. Nothing more, nothing less.
> Nobody knows how UIs will be built with web technologies in two years!
You can't say that things like es6/react/typescript/clojurescript will be plain gone in two years, there's too much real momentum behind these things.
The crop of JavaScript derivatives are probably not going to disappear, but riddle me this: while there are many variations on JavaScript's syntax, why do other languages that are arguably JavaScript competitors, like Ruby and Python, not have the same wide selection of alternate syntaxes and sugar packets? Could it have something to do with the usability of the default dialect?
I personally think it's a bad sign when so many people feel they need to write a transpiler to add some syntactic and behavioral enhancements. The language should provide a functional, livable set by default, at least good enough that writing a transpiler doesn't sound like the time-effective solution.
I don't understand ASM.js very well but it sounds like it's a new type of bytecode that allows programs written in many different languages to be executed in the browsers' JavaScript VM. If this truly bring us first-class support for non-JavaScripts (which won't be real until browser vendors either ship or make it transparent and automatic to install additional DOM bindings), I will be so happy. I will also be curious to see if it has any impact on the popular use of JavaScript itself -- the node buzz already kind of seems to be fizzling out and moving onto things like Go, so maybe we won't have to wait too long.
Popularity, and the fact that things were very bare-bones before ES6.
> If this truly bring us first-class support for non-JavaScripts (which won't be real until browser vendors either ship or make it transparent and automatic to install additional DOM bindings), I will be so happy
Interop with existing JS code/data(structures) will still be a problem. Shipping (or rather, not re-shipping every single time the user vists) your favorite language's runtime and standard library will become a problem (which can be solved). By that time JS will be good enough to make it even less worth it, especially for dynamic/GCed languages.
> the node buzz already kind of seems to be fizzling out and moving onto things like Go, so maybe we won't have to wait too long.
This is true. There hasn't been anything new happening in node land for quite a while now, and the basic core platform is showing its age. With tools such as typescript, async/await and generators available, however, a revival is possible. TS tooling combined with a well designed and documented "core standard library" in the style of Dart's stdlib could make node a very nice platform again.
You focus too much on ES5. It's not about the language, it's the platform.
Versioning your dependencies is good practice regardless of language and has been for decades. Javascript has enough cons, you don't have to resort to imaginary ones.
Ok, so let me spell this out too (frameworks/librairies mixed):
- jquery: 10 years
- backbone: 6 years
- angular v1: 6 years
- ember: 5 years
- react: 3 years
Quoting from wikipedia:
> Qt 5 was officially released on 19 December 2012. This new version marked a major change in the platform, with hardware-accelerated graphics, QML and JavaScript playing a major role. The traditional C++-only QWidgets continued to be supported, but did not benefit from the performance improvements available through the new architecture.
That's plainly wrong.
The list of praticals client-side language on the web is actually pretty vast: https://github.com/jashkenas/coffeescript/wiki/list-of-langu....
Of course you can't write a piece of, say, typescript, and just include it in your HTML and call it a day. You need to compile it first, and you need some tooling for that, but it's not different from using a C++ compiler for building a Qt application.
> Every time I try to get someone to explain it to me I'm just met with a bunch of empty answers like "Yeah it just flows really well man".
Well, actually it flows really well indeed :)
With JavaScript transpilers, this happens in reverse; there is an entirely separate secondary language loosely bolted on here, which compiles to JavaScript, which compiles to some IR, which compiles to machine code. From the developer point of view, the code they wrote in the top-level language executes as JavaScript, not native code, and must be debugged at that level.
I'm sure you're not actually naive enough to pretend this is the same as using a library like Qt. Language semantics are very different and can be difficult and bug-prone to cross-implement. Third-party libraries and modules have large, potentially interdependent module webs that have to be resolved and will often result in massive includes on such transpiled pages (talking 10M+). Bugs at runtime will have to be debugged as the transpiled language, not as the code you originally wrote.
If you use Qt, everything is written in the same language, built by the same compiler, and that language's typical pipeline, including dependency resolution, is unaltered. Bindings in non-reference languages link out to shared objects that do not use transpilation, but long-established and well-understood OS-level linking conventions. This is a greatly reduced complexity surface (== fewer bugs).
My experience with transpilers is that people avoid them whenever possible because they introduce very intricate and difficult-to-use bugs. Now that I think of it, the most well-known transpilers are specially-made to service a large project's needs, like the recently-announced Grumpy [0], which converts YouTube's Python codebase to Go.
Literally the description on GitHub, and a very similar line is the first line in the README. I admit that I have not tried Grumpy personally and do not have any real experience with it. My knowledge on it mostly comes from the HN discussion a few weeks back. It is absolutely possible, even likely, that I'm getting things wrong here. Would you kindly correct my misconceptions? Thanks.
The "runtime" comes in at this point. It sounds like `grumpc` compiles Python objects down to stubbed-out Go objects, which depend on the functionality implemented in grumpy for the implementation of those stubs. "The Go code generated by grumpc performs operations on data structures that represent Python objects in running Grumpy programs."
To me, this mostly sounds like a Python->Go transpiler with special hooks to more easily facilitate Pythonic access in Go. If anything, it seems to support my original point that transpilers are custom-built even more; from my high-level and probably wrong reading, it looks like instead of a full-scale Python-to-Go transpiler, Grumpy's developer realized it would just be easier to implement if he made the programs dependent on his "runtime", which he could freely do because he was running his own project on it and he can execute that project through `grumpy` just as easily as he could through anything else. Such options would probably not be available to someone who was tasked with writing a generic Python-to-Go transpiler that was expected to work anywhere that Go works.
I also could be misreading this, because again, I've never used it, and maybe by "runtime" the author really does just mean "library", and it all compiles down to a standard Go application. That'd be cool.
[0] https://github.com/google/grumpy/tree/aa58aa68717f6ac2ebf40f...
Wrong, source maps solves that problem well enough. Granted, it's not as coherent as a single compiler, but yet, it works.
Its faster than Ruby, Python and PHP by a mile.
It now has async/await.
The amount of work that goes into making it good for front-end apps is amazing.
It has a fairly large ecosystem.
Dynamic / unityped nature lets you prototype quickly.
Tooling such as TypeScript lets you switch to static types when being dynamic just wont cut it any longer. Oh, and TypeScript has generics! (can't believe thats still a differentiator in 2017)
TypeScript can typecheck JSX templates.
It has PureScript for when you want even stronger type-checking and abstraction powers.
It doesn't have: multicore green threads (probably not going to happen) and large ints (coming soon).
Here, have a look at https://facebook.github.io/reason/ and https://facebook.github.io/reason/modules.html and see how many equivalent features it provides using just lexical closures and free-form objects (the TypeScript overlay can also approximate some features of algebraic datatypes via tagged unions and control flow analysis)
Really, the JS sucks meme is getting old, fast. Sure there are more powerful languages and higher quality ecosystems, but its quite far from being "the worst".
In particular, I didn't realize how much faster V8 is than the reference implementations of similar languages. That can be a real and significant usage consideration and makes me less hostile to things like desktop apps. I've been operating from the "JS is slow" pre-V8 perspective, and while I knew V8 was a massive speed-up from the web perspective, I didn't consider that it was actually now among the fastest dynamic languages for non-web uses. That's a great point that should probably get promoted more often.
I still dislike a great deal about the methods and culture in the community and wish that such optimization would be directed at what, in my mind, is a more worthy target, but I know of a concrete rationale now. Thanks!
All the fixable weirdness has been fixed. Even `this` has been mostly fixed by arrow functions. It still has implicit conversions, but hey, typescript and flow make that irrelevant because they'd check statically for those.
What else is so bad about JavaScript? I really don't get it.
The DOM... thats another story.
The application involved a few components that were going to be quite complex and I wanted many of the basic components to have slight customizations. This turned out to be quite a bit more difficult than I thought.
The numerous issues that I encountered in 3-4 weeks (part time) of native development for MacOS included
* Xcode support for swift is garbage. Highlighting, code completion, and general responsiveness are far lower than even web based editors. Also no refactoring.
* Lack of documentation in swift + cocoa + appkit
* Lack of documentation for swift 3. Many examples were from either iOS (not everything is equivalent) or from older versions of swift (a lot has changed in 2 years apparently). Even basics of naming have changed a good bit.
* There was a lot of magic going on in xcode with storyboards / interface builder. When something broke it was very difficult to figure out what went wrong in the storyboard. The generated code from the storyboards is useless to look through. The difference between code working or not could be me forgetting to option + click a part of interface builder to a certain line in my code, with little or no indication of whether it had been done correctly, or what needed to go where, particularly with certain appkit components.
* Dependancies are a heck a of a lot harder to manage. I don’t know why but I ended up using Cocoapods and it was a total mess.
* Many core UI components requiring me to extend them or recreate them for basic functionality that would be a single line of code/xml/css on other platforms. Components that are common in other desktop applications don’t seem to be included in AppKit (some are including in UIKit though)
I ended up scrapping the idea of doing it natively and decided on Electron + React + Typescript. It was a lot easier to aquire and intergrate dependencies, the development enviroment is a lot faster, there’s no magic connecting my UI together, and it’s actually easier to recreate customizable, native looking components with css + js than it seems to be in AppKit. On top of that I won’t have to build a seperate windows app. Realistically my app currently looks and performs better than any competing app (many of which are legacy java+swing apps) and is a lot faster to iterate on.
Heck even my company-id has lots and lots of emails. Jenkins integrations notifications, travis, cron job failures and what not.
I naturally filter both my person and company accounts - so my Inbox is neat and tidy but I think we have reached a point where programmers/system devs/devops people will have to deal with tons of emails.
And yeah - I wish Nylas was better at dealing with this.
If I'm reading emails it means I'm not working or enjoying myself. And I'm not dev-ops, which means I'm not getting payed to keep the systems up and running at night.
I'm also practicing my own extreme version of "inbox zero". Whenever my Inbox reaches 100 emails, I select them all, mark as read, then archive. Information loses value as time passes and I figure that if there was anything important in there that hasn't caught my attention and that I did not answer, then one of my colleagues will surely buzz me about it. Worked fine thus far. And because I'm regularly removing noise, it means I have a higher chance of actually noticing important messages.
Writing this message reminded me that I've got 40+ unread emails in my Inbox. Marked as read, archived, now it's a solved problem.
Never really compared their resource usage since I'm only in one Slack team 99% of the time and even the official app isn't that horrendous in that use case.
Which is somehow funny, since the whole supply chain is controlled by them (App, Browser, OS).