Future Ideas after the Sunset

[mauricioszabo]

Considering we're currently working hard to avoid the end of Atom, I would like to prepare this discussion on ideas that we can focus when/if we are able to keep the editor up and running after the official end date of December, 15th.

It's a good thing to discuss what we want to prioritize too, and if the ideas are even valid or not :)

[mauricioszabo]

Disable support for CoffeeScript.

Currently, Atom packages can be written in CoffeeScript or Javascript. Should we simply avoid CoffeeScript at all? This may simplify the current code (Atom have some way of transpiling on-the-fly .coffee to .js)

[vprigent]

We'd then be removing support for most of the packages that made atom's initial glory?

[joshcangit]

We'd then be removing support for most of the packages that made atom's initial glory?

Oh, didn't realize that.
Actually some of my packages, which I like, actually use CoffeeScript.
But especially my ui themes, most of which use CoffeeScript.

[mauricioszabo]

I meant to transpile the packages on-the-fly when they get installed, if this is a viable options

[mauricioszabo]

VSCode API

I know this is something that the community have been studying a lot in the last years, so maybe it's a good idea to invest some time? Maybe start by supporting LSP (the biggest feature that almost all other editors have now, and that we're still lacking)

[jonian]

I think we already have LSP support https://github.com/atom-community/atom-languageclient

[jonian]

Also there is https://github.com/atom-community/atom-vscode for vscode extensions compatibility. Haven't tried it.

[mauricioszabo]

This second one implements few APIs, it needs to be extended to support at least the most common APIs...

I'm also thinking about some integration to Eclipse Open VSX registry too

[mauricioszabo]

Telemetry

Will we remove completely the telemetry support, or keep it but as opt-in? Or don't change at all? How can people know what's being collected about them, and if they want, opt-in for only specific events? How do we keep this transparent (like a public site with the numbers, or something, for transparency?

[meadowsys]

if we keep it, definitely keep it opt in, and be as transparent as we can possibly be. And only collect stuff that we as a community would actually use to help improve the editor.

[joshcangit]

Electron alternative

Could Atom maybe somehow migrate to another framework?
I hope it's not too much of a tall order.

There's NW.js, Neutralinojs and Tauri as Electron alternatives.
NW.js is closest but so I think it's not worth it since they're sort of the same.
I think Tauri maybe furthest since some Rust knowledge may be required.

I'd assume CoffeeScript can still be used since they're JS frameworks.

If so, gonna need to figure out how to also migrate Atom packages and themes as well.

There's also Vue based frameworks, Quasar and Vuido, but I'm not sure about those.

As for Qt based ones like NodeGui, Proton Native and React Native, I'm not in favor of those since I don't use KDE.

https://github.com/Elanis/web-to-desktop-framework-comparison
https://github.com/sudhakar3697/electron-alternatives#js

[aminya]

If it is a web-based framework like Tauri, probably few benefits as the Web platform is always the bottleneck (JavaScript is slow no matter which framework). But something like Qt can have a lot of performance improvements.

However, again as I said, this is a lot of work. This project lacks contributors that are willing to do the actual work, so such ambitious ideas will never happen. If you like to pursue such ideas, it is better to fork the project or start from scratch.

[ThatXliner]

I thought the idea of building on Electron was for customizability.

[aminya]

That's subjective. e.g. other frameworks like Qt can also be highly customizable.

[joshcangit]

That would be a new project and takes a lot of work.

I just realize that there is a new project, Pulsar, but should I have moved this discussion there now?

What would be the direct benefit of switching?

Not now. Tauri looks most promising but still not yet built at a level close to being a viable Electron alternative.

Tauri has its updater but Electron's add-on updater is still easier to use.
Some desktop app features may require Rust but don't know if future integration with Node.js or Deno will solve that to allow just JS/TS without needing to know Rust.
I think Tauri has yet to ensure their API achieves parity across the native webviews for cross-platform development.

[mauricioszabo]

I just realize that there is a new project, Pulsar, but should I have moved this discussion there now?

If you want, we'll try to answer the best we can. But as a preview, no, we won't move away. Atom (and Pulsar) depends on features that only exist on Electron (and maybe NW.js) for now, moving away from it will basically break almost all plug-ins and remove lots of the "hackable capabilities" of the editor.