Consider using Svelte instead of React

[btakita]

Svelte has some advantages over react:

• It's compiled, self-contained, & has no runtime library [smaller transpiled payloads]. This also makes it's components compatible with any other component library & will not cause conflicts.
• It follows standards (html, css, javascript, & web components)
• It's significantly faster & uses less memory. It's also produces isomorphic javascript out of the box.
• It's a better development experience. Superior & more cohesive Idioms followed by the community.
• It's api is stable yet there's plenty of development. See the sapper project (https://sapper.svelte.technology/) & compare it to next.js

Here's the repl: https://svelte.technology/repl?version=1.57.2&example=hello-world

If this seems interesting, I encourage you to have a conversation with Rich Harris on gittr (https://gitter.im/sveltejs/svelte). He introduced Tree-Shaking with his RollupJS package. He also wrote bublejs (https://buble.surge.sh/), which will yield faster & memory-efficient JS compared to babel.

[magic-akari]

AFAIK, there is another option ionic-team/stencil. It use tsx(TypeScriptReact) to build UI which is similar to React. It is a compiler to build W3C standard web components without runtime library.

Maybe it is possible for others to build xray with different front-end which mentioned in docs and this comment

[sandangel]

I vote for Angular, popular framework with incredible tooling support compiling to web component in v6 ^^

[sebe]

Interesting Xi in Fuchsia is using Flutter, also there is an experiment Flutter desktop, MacOs only to start. https://github.com/fuchsia-mirror/third_party-xi-editor https://groups.google.com/forum/?pli=1#!forum/flutter-desktop-embedding-dev

[nathansobo]

Hey @btakita, good to hear from you. I took a pretty long look at Svelte last week and it does look pretty awesome. That said, on a gut level what I saw wasn't enough to move the needle to spend time experimenting with it. At least for now I want to stick with the more mainstream solution that we already understand pretty well, even if it comes with some overhead. Atom's GitHub integration is all React and I'd like to reuse it, and we're hoping to continue working closely with Facebook devs who are all really familiar with that stack.

I'd like to say that we can always revisit this later, but I guess the challenge with software is that once you start down a path, there is always inertia that tends to keep you on that path, and the canyon only grows deeper as the water flows through it. That said, we're going to be careful to cleanly separate the view logic as its own concern and keep its interface with the core of the system clean. That should hopefully give us options down the road if we start running into bottlenecks with React. I just need to see the issues for myself before I sink time and risk into something more edgy.

Thanks for the feedback. Happy to continue the discussion but I'm going to close this out.

[Alhadis]

@nathansobo One thing I'm concerned about, going by the wording in the readme file: are you guys planning on one day forcing Atom package authors to use React? :confused:

[nathansobo]

@Alhadis A lot of these decisions are fairly subject to change, but here's where I'm at for now:

Early on in Atom's development, we chose to use jQuery, which ended up being a huge liability. Burned by that experience, I vowed to stick to web standards from then on in Atom, and that's what we've done. However, I can't help but wonder if I learned the wrong lesson from the jQuery experience. jQuery was just a particularly counterproductive library to drag into the core experience... it brought a lot of overhead and complexity for basically no value in return in a modern browser environment. But web standards alone are pretty low level, and I think it's an obstacle for our overall ecosystem that we don't have some coherent standard for building and sharing composable units of functionality.

React seems like its become a de-facto standard, and with a massively well-funded company promoting it with tens of thousands of its own components deployed in production, it seems like the story for continued support is fairly solid. Building on it feels like it could be a massive boost to our productivity by increasing abstraction. The trade-off is obviously that it is non-standard.

I think we could support React as the "blessed" approach to adding components to the UI, but still offer an escape hatch for people that want to manipulate the DOM directly (or via another framework) via some kind of adaptor component.

But again, my overall philosophy has shifted a bit from where I was at with Atom. I think we need to be a bit more opinionated and potentially reduce some degrees of freedom in the name of being more productive. All that freedom ends up adding up to large maintenance costs. That said, I still want as much freedom as we can get without drowning in complexity, and I don't think some kind of raw DOM option is out of the question.

[chriskrycho]

I think it's worth note, along those lines, that one of the ways VS Code has managed really excellent performance even with a lot of addons up and running is that it has severely restricted the addon API, including the styling API. This frustrates me at times, because it's more limited than what Atom offers. However, it also means that I can rely on VS Code performing better nearly all the time than Atom does with similar functionality via addons set up. So a big 👍 from me over here (as just an interested observer) for the approach you're taking.

[Alhadis]

@nathansobo I see. Thank you for your answer.

React seems like its become a de-facto standard

Popularity doesn't make a framework a de-facto standard, period. You know as well as I do that frameworks are ephemeral, and each one rises in the fall of another. We've gone from Backbone to Angular to React, and in the space of only 5 years. Who's to say where React will be in another five?

This is why I refuse to use web frameworks, because in the long-term, they're just fads. Only the real underlying technologies - HTML, CSS, JS, and standardised web APIs (DOM/CSSOM, etc) can be trusted.

However, I can't help but wonder if I learned the wrong lesson from the jQuery experience

Wrong comparison. jQuery doesn't tell you how to structure your code, whereas frameworks do.

and I don't think some kind of raw DOM option is out of the question.

I hope not. I recently quit the web industry just to escape all the trends and bullshit that have now become commercially mandatory. I don't want to ditch Atom for the same reason.

[HoraceKeung]

Rich Harris, the creator of Svelte, gave a talk recently about reactivity: https://www.youtube.com/watch?v=AdNJ3fydeao I know this issue is closed but I still want to share it here. This issue doesn't directly affect me. I am a Vue.js dev, I don't use React. I use VS Code. I prefer building and using PWAs over Electron apps. But one day, if I need to learn a new framework, it will be Svelte or frameworks that share similar ideology.

[DrSensor]

somehow I got a notification and realize I subscribed this issue 😂. Since it can be an interesting discussion, here is my opinion

For a project that is quite diverse, try to not be opinionated. If it has to be opinionated, make sure it has huge technical advantages and not being dictated by the popularity and gorgeous talks. There is a ton of framework/renderer out there that can outperform another framework on a specific scenario.

Before choosing a framework for performance, we should know well the underlying architecture on each framework, do some sort of benchmark, then make a specific table of comparison along with the approach on how each framework renders that specific UI. Also worth to mention that micro-frontends could also be an option.