[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.

[mwcampbell]

An app based on React Native isn't a web app anymore. But it's not quite native either; it doesn't use the native button and list view controls on either iOS or Android.

[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.