[Kunix]

I am 29, started coding at 14, I've built UIs based on mIRC Scripting, VB/Winforms, C++/Qt, C#/WPF, Java/Android layouts. Using IDEs such as Visual Studio, Eclipse, Qt Creator and Android Studio.

I must say: Atom Editor is great. Using HTML/CSS/JS to build desktop/mobile apps really makes sense to me, especially given that:

- You only have to support one rendering engine. - You have access to the latest Web Components/ES6/CSS3 features. - You can rely on native Node.js modules when needed.

It's good for portability, HTML/CSS became better at UI, JS becomes a better language, current IDEs are great, live debugging tools are great.

[scrollaway]

You also forget:

- There are far fewer native components, leaving accessibility down to the developer of the app and making it nonexistant.

- Platform integration is impossible, which means there is no way for the framework, for example, to create widgets differently on OS X, Windows or Linux (these platforms have many different conventions)

- Theming globally becomes impossible. If you want to write a dark theme for your desktop, you go from writing a theme once for GTK and once for Qt to once for each and every app you run. Uuuurgh.

But only supporting one rendering engine, yay! Much better than the 6 different engines we have to support in Qt (huh?).

And having access to all the latest JS additions! ... that were copied from other languages you could develop desktop apps in, because JS is a terrible hack.

And relying on native Node.js modules, yay! As opposed to native modules for literally every other better language out there.

I'm not sure what you're actually comparing this workflow to. Maybe one day writing HTML apps will be great, but today is not that day. Today, writing HTML apps is only beginning to be an idea that doesn't completely suck. But for the user, it does massively suck. Massive apps that ship their own copy of webkit/blink/whathaveyou, with security flaws that won't get patched, disgusting performance on low-end hardware, atrocious battery usage and decades of UX knowledge thrown out of the window just because the app developer doesn't have the knowledge to see it.

I don't look forward to this. And I'm younger than you.

[ZenoArrow]

> "Platform integration is impossible, which means there is no way for the framework, for example, to create widgets differently on OS X, Windows or Linux (these platforms have many different conventions)"

So web apps can't have reusable components now?

> "And having access to all the latest JS additions! ... that were copied from other languages you could develop desktop apps in, because JS is a terrible hack."

WebAssembly will take over for web apps eventually.

> "decades of UX knowledge thrown out of the window"

UX knowledge isn't toolkit dependent, UX knowledge is just as applicable on the web. You can make a dog of an app with any toolkit, native toolkits offer no guarantees for good UX, you can only hope that designers choose to follow best practices.

[scrollaway]

> So web apps can't have reusable components now?

I'm not saying they can't, I'm saying they don't. You go ahead and try to fix that, create widget#772981 that still won't support typed-selection, or will break with large text or what not... I've seen too many of those, most of them bad, and none of them standard. So far, React is the only thing that even comes close to a sane model for a contender to UI development on the desktop, and it still mostly fails the accessibility checkbox.

> WebAssembly will take over for web apps eventually.

More eventualism. Do you have evidence for that? Do you even have evidence that it'll be better than what we have now in other languages if it does take over?

> UX knowledge isn't toolkit dependent

A lot of it is. You'd be surprised just how much UX is crammed into Qt Widgets for example. Years of experience making them more accessible, more usable, more consistent with the platform they're running on, etc.

[ZenoArrow]

> "I'm not saying they can't, I'm saying they don't."

They already do. Electron, Web Components, etc...

> "Do you even have evidence that it'll be better than what we have now in other languages if it does take over?"

Compare the performance of vanilla JS vs. asm.js. It is clear from what developers have stated that WebAssembly performance will exceed the performance of asm.js, the threading improvements alone should offer noticeable benefits.

> "Years of experience making them more accessible, more usable, more consistent with the platform they're running on, etc."

So what are we looking at to replicate that? A theme per platform? Some accessibility work? What else?

It should be noted that the web isn't starting from zero with UX either, we've already had 20+ years of refinements to the web user experience.

[scrollaway]

> They already do. Electron, Web Components, etc...

And nobody can agree on which to use. It's not standard if it's just "some set of components some people reuse". A far cry from standardization.

> Compare the performance of vanilla JS vs. asm.js.

That's not what I'm comparing. I'm comparing the performance of native toolkits vs web toolkits on asm.js. It pales in comparison, and the battery usage is through the roof. ymmv?

> So what are we looking at to replicate that?

1. Standardization of components (developer does not have to build their own scrolling system, context menu, etc) 2. Themability of components at the application level (developer can style components not to clash with the style of the application) 3. Themability of components at the platform level (user can style the application not to clash with the style of their own desktop) 4. Performance needs to shoot way, way up. Apps can't rely on a performant GPU, it's unreasonable to ask that of every device at this point in time. Some day maybe every device will come with their own high performance GPU, but eventualism cannot excuse bad coding practices and unnecessary layering.

The rest should follow. But I still don't see us getting any of those things, any time soon. These are not easy problems to solve.

[ZenoArrow]

> "And nobody can agree on which to use. It's not standard if it's just "some set of components some people reuse". A far cry from standardization."

Atom uses Electron, VS Code uses Electron, Light Table uses Electron (starting with v0.8).

As for the web side, web apps are a young field, what else would you expect?

There are certainly popular UI elements, Bootstrap for example.

If you want to make an web app that looks native, using React Native could be a good solution.

[stonemetal]

>I'm not sure what you're actually comparing this workflow to.

He is comparing it to what they have now, XUL + CSS + JavaScript. Replacing it with html isn't as big a change as it sounds, their UI is already written in XML and rendered by Gecko, all they are doing is moving from a custom XML like XAML(MS) or FXML(Java) to standard HTML rendered by Gecko.

[toyg]

Unlike you know something I don't about Kunix specifically, I don't think he's talking about Mozilla development in particular, but rather development in general.

[walterbell]

In that case, could the XUL dependency be removed from Thunderbird?

[scrollaway]

Unlike the original parent post I don't think this announcement anything to do with XUL. Thunderbird just doesn't have the userbase Mozilla expects it to at this point because, surprise, the people who want an email client are a small subset of the people who want a web browser.

<rant>

This is lost in a sea of replies now but I'm sure pissed off Mozilla is completely losing their root mantra of fighting for the free web. Persona, Thunderbird, two critical components of a "free web": free global authentication, free email client. I'm sure next mozfest the same suits as every year will talk about how they're so proud of "keeping the web open". What a crock of crap. Firefox isn't even that good of a browser anymore.

</rant>

[walterbell]

It is easy to forget that freedom and creativity are not a numbers game. There are benefits to a majority when a minority is free to create. An argument could be made that the majority consumption patterns are made possible by the minority creator patterns, hence it makes economic sense to fund the minority out of majority profits.

This is one of the reasons why iPads have stalled - pro developers can't make money, for well documented reasons. The web equivalent will be the starving of open communication, thought and creativity, leading to homogeneous noise as a poor substitute for ground-breaking content.

[stonemetal]

I don't see why it couldn't, they are doing it for FireFox. On the other hand Mozilla has been on the path to retire Thunderbird for some time, this is just the next step.

Mostly I think it is an effort vs reward thing. Thunderbird doesn't have the user base and doesn't have a revenue stream the way fire fox sells the search box. I wonder if anyone over there has thought about cleaning it up and selling it as a white label email client.

[creshal]

> - You only have to support one rendering engine. - You have access to the latest Web Components/ES6/CSS3 features. - You can rely on native Node.js modules when needed.

So, developer convenience trumps user experience? Who cares about your battery run time, how hot your PC runs, the bandwidth overhead, the massive attack surface from all the useless components shipped, how badly the webapp integrates into your OS, as long as we can ship faster and faster?

[Kunix]

As a user, my experience with HTML/CSS/JS apps is great. Look at the excellent feedback the Atom Editor is getting.

As a developer, I feel that it's easier for me to create good user experience (nice UI, easy non-blocking I/Os by default, etc).

I don't say it's flawless, I say it's now becoming a very good alternative.

[creshal]

Oh, I'm writing web apps myself, but Gods, am I hating myself for it. OS integration is somewhere between a nightmare and impossible – and yes, it is desirable, unless you're on like Gnome 3 –, the resource requirements are abysmal (400 MB for an app that consists of a single input form, a table, and a search field, really Chrome?), performance is actually pretty lacklustre (non-blocking is one thing, actual multithreading another!), the UI isn't actually all that nice if you want to use it, not just look at it (say goodbye to accessibility; hell, even just proper keyboard navigation is black magic for most frameworks); and if you ship the engine yourself, you're now responsible for orchestrating and shipping bi-weekly browser updates to your customers to make sure your browser engine stays patched.

Is all that bullshit really worth… whatever we're saving? (Our company is mainly saving in developer salaries, because we can force kids fresh out of school to work for minimum wage, instead of hiring experienced developers… we'll see how long this keeps working.)

[mwcampbell]

> As a user, my experience with HTML/CSS/JS apps is great. Look at the excellent feedback the Atom Editor is getting.

For some less positive feedback on Atom, which reinforces some of creshal's points, see the Atom section of this text editor rundown:

http://eev.ee/blog/2015/05/31/text-editor-rundown/

I've also frequently seen complaints to the effect that Atom is much too slow, even on machines only a few years old. Even my 486 laptop back in 1997 could run a text editor with syntax highlighting (specifically, JPad for programming in Java). What are editors doing these days that needs so much CPU power?

[Kunix]

> For some less positive feedback on Atom, which reinforces some of creshal's points, see the Atom section of this text editor rundown:

> http://eev.ee/blog/2015/05/31/text-editor-rundown/

This review (6 months ago) is based on an early version of Atom Editor (0.204.0), the latest stable (1.2.4) is way more mature and provides very nice packages [1].

[1] https://atom.io/packages

[hmokay]

JavaScript programmers are truly delusional sometimes.

[kuschku]

It’s not really JavaScript, I’d argue it’s a different reason.

node-webkit apps are cheaper to develop. Far cheaper.

Everyone can write a webapp, a native application requires professional developers. The payroll looks completely different.

And then the devs who have only worked with node-webkit don’t know how much better they could have it. I know devs who refuse to use map, reduce and filter, because "it’s black magic and we always used for".

[vdaniuk]

The fact that you are being(edit: was) downvoted for constructive opinion shows unwarranted prejudice of HN hivemind towards web technologies. HN discussions on this topic are effectively useless, any constructive truth finding is drowned.

edit: I'll take my downvotes with pleasure. The fact that I am able to use Atom or Nylas N1 or Nuclide on linux with 0 problems alone is enough to welcome proliferation of web tech on desktop.

[paulddraper]

Your decry of prejudice would be more believable if it weren't only unsorted generalizations (i.e. prejudices)

[grinich]

Thanks for your support of N1. :) Feel free to ping me if you have feedback. I'm [e-mail]