Pulsar – A Community-Led Hyper-Hackable Text Editor | Hacker News Reader

Pulsar – A Community-Led Hyper-Hackable Text Editor

github.com

117 pointsphilonoist89 comments

Atom was unbelievably slow. How will the performance be improved? Visual Studio Code somehow managed to surpass the awful Electron performance just enough to make it usable, and it's pretty unbelievable this project will come close to that.

Why couldn't they take the optimizations from vs code and integrate them? VS code is open source, it's only their proprietary extensions like remote dev that aren't open.

I remember Atom in its later releases had significantly improved performance to the point I never noticed problems.

Looking at both projects vscode uses typescript heavily while this project mainly uses coffeescript. So that might be a hindrance. So I guess that might be part of it.

We are actually looking to "decaffeinate" back to vanilla JavaScript. Unfortunately there is rather a lot of it still even after the Atom team's attempt to remove some of it.

For those who want fast and lightweight without falling all the way back to emacs/vim, I’m really digging Lite-XL.

Lua for customization, thin accelerated rendering layer in SDL2+freetype, zero nonsense. Binary packages are like 2MB. The code itself is clean and readable.

The plugin collection is still young and won’t have everything you’d find in the Electron-family of editors, but that’s also a plus when it comes to it staying lightweight and streamlined like some might want in these tools.

No need to fall back to Vim, Sublime has stellar performance already.

Have used: dreamweaver, vi, nano, notepad, ++, atom and sublime.

Sublime so soo superior, it's not even fair. Haven't tried vscode but I understand it's a resource hog.

I reluctantly switched from Sublime Text to VSCode about four years ago, but now it's simply unimaginable to go back. It's heavier, but fast enough to have four or five different workspaces open, in very large projects. The language support, intellisense, and plug-in ecosystem are miles ahead.

I'm curious as to why that is. I would think it's LSP support would close the gap on languages (and intellisense) at least.

Sublime Text (plus Sublime Merge) all the way. I've been on Emacs, vim, nvim and always get back to ST.

Sublime performance can't be beat, but I'm seeing the end of the road for active plugin development. It's getting harder and harder to adopt new tools without farting around with configs all day.

At least, this was my experience trying to get Deno development to feel "right". It feels like vim and VSCode are the platforms that get plugin support nowadays, and the rest are a hack.

i'm keeping my eye on https://github.com/lapce/lapce

native frontend (Rust/druid), LSP support, tree sitter syntax highlighting, command pallette, vim key bindings, modal editing, plugins in any language with WASI target, remote development, community led, open source plugin registry, it checks a lot if boxes. https://lapce.dev

I would interested in understanding how VS Code overcame these limitations. Did the VS Code team ever do a write-up anywhere?

You might enjoy https://news.ycombinator.com/item?id=11940043

That was very enjoyable. I think the tldr is that they use custom scrolling via translate3d, limit any computation on the file to just the visible lines, and they split the text into lines with regex to leverage native loops instead of trying to split the next manually via JS. Mono-spaced font probably makes this problem a lot easier as measuring text is pretty trivial.

For starters, I’m pretty sure their focused on updating the project and dependencies.

Electron is rarely the cause of performance problems itself. It's more that JavaScript makes it really easy to write slow memory bloated code. But it's possible to write really fast and efficient apps in JS.

There are a few fundamental limitations with web/js. No shared memory concurrency, no reasonable storage layer, no integer types. Those can make some things hard to make performant but most apps I see are not limited by this.

Most apps are slow due to a few common mistakes.

- React/Anglular diff based rendering cycle.

- Garbage collection due to careless allocation of objects in tight loops.

- Poor client side data models, resulting in blocking on the network for simple things.

- Careless use of the bad storage abstractions (bleh indexeddb) which requires copying data for every operation leading to GC pressure and wasted CPU.

- V8 is a moving target in what it chooses to optimize well and what it fails to optimize.

tl;dr fast electron apps are possible but the platform makes it easy to write slow apps by default.

This is the community attempt to continue / revive atom right? Interesting that atom doesn't really get mentioned in the docs anymore- hopefully a sign that it's finding its feet and direction as a project in its own right.

I don't know, seems a bit weird not to mention Atom at all. At least "This project was forked from Atom" or whatever.

Besides it being nice, it's also a requirement of the Atom license, that the copyright and license notices are preserved. Seems the only mention of their heritage is "Original work copyright (c) 2011-2022 GitHub Inc." in the LICENSE file but again, no mention of Atom.

Just a guess: perhaps GitHub prefers the credit? It depends who controls the Atom name I'd think.

Shouldn't matter "who" prefers the credit, the project is a fork from Atom and should be mentioned as such. Right now, going to the website or the repository makes it seem like a brand new editor, which it is clearly not, but not so clear based on what information they willingly provide you with.

I mostly agree. Still, project / owner names (as written in licenses) can change. So the entity in control makes the call, I would think.

The license in the original Atom repository https://github.com/atom/atom/blob/master/LICENSE.md has the following copyright notice:

IANAL but the terms of the MIT license says:

> […]

> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

> […]

And they did preserve it all.

https://github.com/pulsar-edit/pulsar/blob/master/LICENSE.md

So IMO, they are pretty much fulfilling the requirements of the MIT license it looks like.

Depends on whether the copyright notice and license is also presented somewhere (such as under the About menu) in distributed copies of the modified program as well. But I have no interest in installing Pulsar just to see if they do that or not.

The LICENSE.md file in the root of the Pulsar repo is indeed available in the application under Help > View License.

From the about page of their web site (https://pulsar-edit.dev/about.html):

"The team behind Pulsar is a community that came about naturally after the announcement of Atom's Sunset and decided that they needed to do something about it to keep their favorite editor alive. This is a true community-led project to modernize, update and improve the original Atom project into a contemporary, hackable and fully open editor."

I don't think that's enough. It's not mentioned in github repository README. I actually thought this is a brand new editor until someone pointed out this is a fork of Atom. I have browsed at least hundreds of open source repositories and this stands out as very strange.

We have it in a bunch of places around the GH org (literally the first two lines on the org readme), docs and blog posts. In no way do we want to hide it but we also made a decision that we didn't want any trademark disputes from GitHub's lawyers from misusing their Atom trademark anywhere. We very much acknowledge the Atom legacy (including hosting the full original Atom flight manual before the website went down alongside the rebranded docs).

Edit - We have updated the main repo readme with the info to hopefully address some of these concerns

It's interesting to see this coming out of the atom community. I've been really impressed with Zed (https://zed.dev/) which is from the original atom folks and focused on speed and collaboration. Rapid improvements since initial launch.

Care to share a binary or some other project that is actually beyond a closed alpha? Otherwise not a lot of point in sharing it as an alternative, it's not available to the public.

Edit: signed up for the waiting list and received "Zed currently only targets macOS" so sounds like they only target ~10% of the actual market. Interesting strategy.

The strategy is that native macOS UIs are generally easier to develop than native Windows UIs, so they're trying to iterate on that platform first.

If they're building a native macOS UI, how is it ever possible it'll be worthwhile to port that into native Windows UI or "native" Linux UI? If you wanna go cross-platform, you usually consider that from the start, not once you're 50% done, as you're gonna have to redo a lot of work you could have gotten "for free".

The “engine” itself is likely cross-platform, with vendor-specific UIs.

It’s likely quicker to develop for a single OS and then build the additional UIs with a more feature-complete app.

Arc browser is also doing this, and they're planning on debuting the Windows UI in Fall.

Isn’t the whole selling point behind their thing that they don’t use the native macOS UIs but instead send everything to the GPU?

Rendering a platform native GUI and what you render it on are two different things. In the case of Zed, its a combination of - metal is quite easy to work with - apple has clear design guidelines and nice toolkits

The Xi editor team quickly found out how much of a mess "native" gui's were on windows. Zed will hopefully add support for vulkan and linux/windows later, but it makes sense to start off on macOS

Metal is not a platform native GUI, it is Apple's graphics API. The native UI on the platform is Cocoa (which calls Metal for some things, but isn't being used here).

I've got invites (and am not otherwise affiliated with the project) if you want to test it out. Username @ Gmail works.

If it's still Mac only, I don't have any real use for it, can only use editors that works across Windows, Linux and macOS, otherwise there is no real point in me trying them out :/ But I thank you for the offer, might reach out in the future if I hear it's available on more platforms.

Send one my way - ashishbhatiya18@gmail.com

If you have another invite to spare, I'd be very grateful to accept one! Email is: spidershred01@gmail.com

This looks fantastic! Read through the homepage, clicked the "Download" button in the footer, page 404s. Joined the waitlist! We'll see.

the big question: is it going to be open source, tho?

It's kind of maddening that both VSCode's remote dev extension AND Zed (which aims to be better than VSCode) AND JetBrains's remote dev AND repl.it AND <some other stuff> are all closed source.

What's the state of art open source editor/extension/protocol/whatever that enables two or more persons work on the same open files in real time? Something better than the ssh access which forces one person to work at time, then save, then the other person reloads.

ssh then attach to a tmux session

Okay this works, but how's the latency?

Can this made to work with a GUI editor? Like neovide or emacs but in X11/wayland not tty

Emacs with crdt.el, or neovim with instant.nvim are both open source and free implementations of collaborative editing with crdt's. Its going to be a bit of a struggle getting your coworkers to use emacs/neovim though

My dream is a 'universal' protocol for things like this, so that you can use whatever text editor you like to join a session.

Is there some inherent difficulty is this, or is it just "there is no standard" -> "nobody implements one"?

a combination of "there is no standard", "selling collaboration to businesses is way to make money", and that how editors handle files changes from editor to editor, so its a bit hard to sync

- zed.dev has crdt's/collaborative editing as one of its selling points, but they're planning to offer this collaboration as part a paid service to businesses. - vscode has its own sycronous collaboration plugin, but its proprietary and they declined to release the source code or offer to port it to other editors - you could probably build a plugin that bridges emacs and neovim, but it might be a bit slow as you'd have to "translate" the buffer from one editor to the other

There is an inherent difficulty in implementing it, getting asycronous collaborative editing right is hard. Combine that with how few people on emacs/neovim actually use collaborative editing (emacs still has a mailing list and does code via patches) and the chance for a "universal" version is practically nil.

Getting Teletype working properly again is one of our tangible goals for Pulsar - which is of course entirely open source. The question is of hosting so hopefully we can make it really easy to host your own instance or go peer to peer rather than just relying on a server.

Speaking with some of the devs, yes (asterisk). From what I understand, they are working out what they can open source while also retaining the ability to make money from the editor (mostly from the collaboration features)

I’ve been using Zed for a couple of months. It has replaced eMacs and VSCode for writing Rust. The integration is so well done, it’s like a constant conversation with the compiler. I’ve got ten invites by the way.

One thing I worry about a little is the business model. They want to target teams and charge for the cooperative features. But as a single user I’d love a way to just buy a lifetime license and feel that I can expect at least five years of use. I don’t like when software I love treats me like a casual fling.

Any chance I could get one of those invites? My username @ gmail.com

Thanks in advance! Looks cool

I haven’t read the docs lately but when I was hacking on Atom years ago, the plugin model was TOO freeform, and with plugins all running on the main thread, it was easy for a plugin to kill performance and slow down the editor. The vscode model strikes a better tradeoff between extensibility and performance. Extensions have less power but my editing experience is never ruined by a rogue extension.

One of the last things I remember about Atom was that by the time they’d figured out all the stuff they needed to fix, VSCode had come in and stolen all the eyeballs, so to speak. So they have a good roadmap, they just need to do the implementation.

This is a fork of Atom, right?

It's funny the README doesn't mention it.

It is mentioned in the About Us page.

The team behind Pulsar is a community that came about naturally after the announcement of Atom's Sunset and decided that they needed to do something about it to keep their favorite editor alive.

Your comment is almost irrelevant to the original post. It's not in README which is what most people look at. I never look at "about us" unless I am really interested in what's going on. And this is just very strange when the entire foundation of the code is based on another project but they don't mention it in a visible way.

Honestly we thought we had covered it enough without flying too close to any trademark misuse claims from GitHub but it appears not so we are going to look at seeing what we can do to make it more obvious.

Edit - Have another look, we edited the readme to make it more obvious. The readme is due a massive branding overhaul but hopefully this addresses the immediate concern.

Does Pulsar support terminals over SSH? The reason I (only) use emacs and vi, is that they're available *everywhere* and work in literally every environment.

I'm enjoying the explosion in editor software going on right now. Even if most of them don't survive or gain a large audience, I'm sure the cross-pollination of ideas will lead to some great improvements in those that do.

It would be nice to know what this offers that emacs doesn't already ... other than it being built on a more modern GUI framework (Electron).

I think it'll be a long time before something replaces emacs given that emacs is extremely niche and most text editors don't seem to be after the vim/emacs market

your comment makes me think:

emacs already does everything-- no tool is ever going to do more than emacs (before you say it, i know this isn't literally true.)

so when i already have a tool that does everything (actually multiple tools), what might i want in a different tool? to extend the metaphor of a tool: i'd want a tool that feels better in my hand, or a tool that does a specific job very well, or a tool that can fit better into tight and awkward spaces, or a tool that works by a different principle, or just a more beautiful specimen of the same tool that does everything. or maybe i'd want a different tool for one of the many reasons i'm sure i haven't thought of.

just some stray thoughts, nothing original, but it makes me realize that i'm always looking for tools that work on a different principle to the ones i've got, and that's never occurred to me before now.

A new tool can certainly do things better. Emacs has many quirks, that are partly because of its age, and partly because it needs to remain compatible with its extensive ecosystem. A new editor that, for example, prioritizes performance, while not sacrificing extensibility, and maybe does it in a more mainstream language, could always start small and eventually gain traction.

I recently stumbled across this interesting attempt:

https://emacs-ng.github.io/emacs-ng/js/getting-started/

The whole point of it was being as customizable as Emacs, but easy to do with JavaScript.

I personally prefer sticking with an s-expression based language, but apparently not everyone agrees:

https://emacs-ng.github.io/emacs-ng/js/getting-started/

Maybe this project will help emacs move into the browser someday.

Why is everybody building on top of electron (slow and bloated) instead of emacs or even vim?

We don't need a new editor. Just make a spacemacs layer or doom plug-in.

It’s a rebranded Atom, which was sunsetted recently.

Folks who know Pulsar and Zed internals: which one of them is more likely to gain support for Atom packages? I find Hydrogen[1] invaluable as a data science scratchpad since it supports python/r/julia/etc under a common interface via jupyter, and have been unable to construct a comparable workflow in vscode or any other editor [using scripts as opposed to notebooks, which i find far too bloated].

[1]: https://github.com/nteract/hydrogen

Pulsar already supports (nearly) all the Atom packages and has a brand new backend reverse engineered from the closed source Atom.io packages backend. I think it is unlikely you will get any Atom support in Zed any time soon.

Some packages had to be removed due to incompatible licenses

32% CoffeeScript is a very interesting choice in 2023

Working on bringing it down via the process of "decaffeination". Unfortunately this is Atom's legacy and not our doing.

I didn't realize this was a fork until reading our comments. Makes sense in that context. Your page says this is a new project which is what threw me.

> "Built on Electron"

No, thanks.

This one on the other hand, looks very promising

https://lapce.dev/

I am willing to bet $100 this thing never becomes mainstream based on my 2 decade software dev experience.

Like Atom after VS Code

Atom was introduced prior to VS Code. VS Code reuses electron as a framework, which was written for Atom (originally called electron shell).

Bah, that's too easy. You can say that about 100% of all projects that hit HN and you'll be right 90% (or more) of the time.

Save your comment for when you believe the opposite (that something for sure will become mainstream), that's when it gets interesting.

Lapce, which is written in rust, is using Druid, which is discontinued.

They're using their own fork: https://github.com/lapce/lapce/issues/2177

No wonder my Rust GUIs have long-standing display bugs, e.g. Neovide (neovim GUI frontend), Psst (Spotify GUI client)

I've tried it out of curiosity and it's extremely unstable so far. Barely runs on my Linux box and couldn't get it to run without crashing on Windows.

I'm done with these JS/Electron editors. They are Ok (for the most part), but using Neovim in 2023 is such a huge step above everything else if you have the inclination to learn it. I'm integrating my workflow into Nixos and it's pretty incredible what is possible if you constrain your development to the terminal.

pass, because it’s electron.

700MB+ installed. It's a big boi for a text editing app.

Hasnt got a "scrollbar map" (known as MapMode[1] in Visual Studio), making it harder to navigate large chunks of code.

[1] https://learn.microsoft.com/en-us/visualstudio/ide/how-to-tr...

There is the Minimap community package which is one of the most installed ones. https://web.pulsar-edit.dev/packages/minimap

Reply on news.ycombinator.com