If javascript is not supposed to replace lisp then why open the window to biforkating the plugin echosystem

[pushqrdx]

As the title says, i read in FAQ that javascript is not supposed to be an alternative or replacement for lisp, if so, why risk the possibility of a future where emacs-ng plugins are not compatible with gnu emacs or vice versa? It's not like javascript is any easier than lisp to learn, in fact anybody can pick lisp and i'd argue even easier than javascript (which is pretty easy already)

[shaunsingh]

Not a maintainer but imo

1. javascript is a more popular language. You can use elsewhere and in actual work, whereas noone really uses lisp anymore apart from very specific applications. People new to emacs are also more likely to know javascript

2. Faster, much much fater

3. Think of neovim vs vim, neovim incorporating lua plugins, more people are keen to write plugins since lua is an easier and more popular language. Lua is faster, opening the gate to plugins which weren't practical before. And those who dislike neovim and lua can still use vim, or neovim and just not use lua

Even if you use emacs-ng, you aren't forced to use the javascript aspect of it.

[pushqrdx]

Javascript is a more popular language. You can use elsewhere and in actual work, whereas noone really uses lisp anymore

I'd argue that customizing emacs in lisp is far easier to pickup (i am talking few days) than javascript, this becomes even more true when you consider all the elisp code/packages out there that you can just learn from and copy/paste to adapt, a non programmer is more likely to become familiar with lisp than it is to learn Javascript

Faster, much much faster

This point is not accurate simply because both lisp and javascript operate in a VM so JS being faster is just that it's VM is being more efficient than elisp's, in other words improving elisp vm using another language is probably the best way to go

Think of neovim vs vim, neovim incorporating lua plugins, more people are keen to write plugins since lua is an easier and more popular language. Lua is faster, opening the gate to plugins which weren't practical before. And those who dislike neovim and lua can still use vim, or neovim and just not use lua

Unlike vimscript, lisp isn't a waste of time/effort to learn, even if you don't use lisp in your day to day life as much, the things you learn with lisp will benefit you in other languages, vimscript on the other hand isn't even a real language you're just learning a weird DSL with a ton of quirks just to customize vim and nothing else.

[kiennq]

This point is not accurate simply because both lisp and javascript operate in a VM so JS being faster is just that it's VM is being more efficient than elisp's, in other words improving elisp vm using another language is probably the best way to go

Solely on the popularity side, javascript is much more used widely than elisp, so the effort to optimizing javascript engine is always much more than elisp.
While I love elisp, for the sake of practicality and speed, I will just stick to whatever offers the higher speed and consider changing later when elisp has caught up.

[pushqrdx]

I will just stick to whatever offers the higher speed and consider changing later when elisp has caught up.

leaving behind a bunch of javascript packages that only work on emacs-ng and now that elisp is on par they will be on life support or dead

[shaunsingh]

This point is not accurate simply because both lisp and javascript operate in a VM so JS being faster is just that it's VM is being more efficient than elisp's, in other words improving elisp vm using another language is probably the best way to go

This point is accurate, you're arguing about why its slower and trying to justify it, that doesn't make elisp any slower. And as he said, I don't see javascript/deno, a much much more popular language, getting slower than elisp, which doesn't have much use outside of emacs.

Unlike vimscript, lisp isn't a waste of time/effort to learn, even if you don't use lisp in your day to day life as much, the things you learn with lisp will benefit you in other languages, vimscript on the other hand isn't even a real language you're just learning a weird DSL with a ton of quirks just to customize vim and nothing else.

Its not a total waste of time, but javascript is still a better language to learn if you had to choose between the two. Not because its easier to pick up, but because its more widely used. I love lisp, but on paper javascript is the better investment.

Besides, you don't have to use deno/javascript if you want to use emacs-ng. You can even disable it alltogether when buildling emacs-ng from source.

[pushqrdx]

This point is accurate, you're arguing about why its slower and trying to justify it ... getting slower than elisp

I am not justifying elisp being slower all i am saying is that saying javascript is much faster hence we should use it instead of improving elisp's vm isn't probably the best way to go

Besides, you don't have to use deno/javascript if you want to use emacs-ng. You can even disable it alltogether when buildling emacs-ng from source.

Yeah i know but this isn't the point though, i am expressing a concern that having both javascript and elisp will create 2 separate echo systems that aren't compatible with one another, and in the long run will lead to wasted effort, just imagine cool plugin Z written in javascript, now neither emacs-ng users who want to use only elisp nor GNU emacs users will get to benefit from this, and either A) it will be ported to elisp or B) More than half of the population won't get to use it

[brotzeit]

Personally, I wouldn't write a whole package using javascript. I think it can help to improve the performance of some tasks but I think that usually won't exceed 10% of the code base ?

@pushqrdx I can understand your concerns, but I think package maintainers would decide to write this 10% of the code in javascript AND elisp so the package is also usable without emacs-ng(that's what I would do). But I also think that you have to take the risk of splitting the community when you want to try new things. After all, that seems very natural, right ?

[pushqrdx]

@brotzeit I understand that risks are inevitable for moving forward but it's the risk vs reward in case of embedding Javascript seems a bit too high and the gains aren't that big to justify it. Eitherway that's just my concern i thought i'd share it.

[black7375]

Similarly, even in a VM-based language, the performance is different.
As far as I know, stop-the-world is less and much more efficient.

• Generational GC
• Concurrent marking
• Hidden Class
• ..etc, ..etc2

To be honest, I don't think it's easy to improve the performance of the Elisp VM without professional knowledge and a lot of time.

---

I also agree with very limited use of JS because of ecosystem issues.

[shaunsingh]

Not to mention that no matter what you do, more time and money is going to be put into deno and v8, because its much more popular. Even if every emacs user were to contribute to improving the elisp vm, it doesn't compare with even a small subset of web browser users.

[pushqrdx]

@shaunsingh which again doesn't matter how popular or how much performance improvements are made there all we need is fast enough for emacs usecase VM, so for instance i'm very interested in a gpu accelerated Emacs, javascript integration however is just big risk with absolutely minute reward

[shaunsingh]

Well you say its a minute reward and a big risk, but thats subjective isn't it? Imo the reward in performance is well worth the hypothetical risk. "Good enough" is also a boundary thats drawn by the user, personally even with native comp emacs feels incredibly slow, compared to neovim or even vscode. If you can settle for emacs28's performance, then thats fine.

[pushqrdx]

@shaunsingh i am very picky about performance and speed but i have to say if emacs 20 + native comp is slower than vscode for you then you probably have tons plugins or using one of the "distros", for me vanilla emacs 28 + eglot + treesitter is way faster than vscode, it's nowhere near vim's speed but definitely not as slow as vscode, but yeah i agree that speed perception is subjective but that doesn't make taking a shortcut like embedding Javascript any less of a risk and i still think and hope that improving elisp would be the ultimate choice

[brotzeit]

i still think and hope that improving elisp would be the ultimate choice

Sure, that would be great. But isn't it better to have some alternatives until that has happened ? To be honest I think you have better chances to find people who want to work on a more modern elisp when they see that other users are working on features like JS and webrender. And we should also be a little realistic, we don't have many people in the community who are able to modernize elisp. I'm thankful for every emacs maintainer we have, but I think you also know how the situation looks like.

[shaunsingh]

emacs 20 + native comp is slower than vscode for you then you probably have tons plugins or using one of the "distros", for me vanilla emacs 28 + eglot + treesitter is way faster than vscode

Turn on pixel-scroll-mode and try scrolling. Definitely not as buttery smooth as vscode. Try opening a 3gb+ file, vscode is quite slow too but nothing as bad as emacs. When you build a text editor on a popular technology like chromium, and use a webrender, it produces great results, albeit being a ram hog.

[pushqrdx]

@shaunsingh

When you build a text editor on a popular technology like chromium, and use a webrender, it produces great results

Honestly i have no comment on this, like vscode has it's strengths but performance is definitely not one of them, also vscode doesn't use webrender, in fact monaco editor (vscode's editor component) just uses the dom

@brotzeit i just demonstrated a concern for possible rift in emacs echo system as a result of embedding javascript just for emacs-ng maintainers to take into account, i am excited about the gpu accelerated rendering part of emacs-ng though and i hope the project overall manages to add something useful to the Emacs ecosystem and community

[shaunsingh]

While it doesn't use webrender (which is iirc mozila's), I believe it uses blink/the chromium renderer. Scrolling is far, far better than emacs. Resource usage (ram) is definitely high, but performance is great

[YellowOnion]

99% of the time performance issues are because of bad code, not some 2x performance improvement from a slightly better optimized language VM. Using javascript won't magically make pixel-scroll-mode faster, nor gccemacs. What will fix it is profiling it and finding the actual issue.
Things like WebWorkers just make me worried that I'll have to deal Emacs hogging my CPU, because why write good code when you can just throw more cores at the problem.

I've had both vscode and emacs run really bad due to bad code.

TypeScript is the only suggestion that I think makes sense as it helps reduce bad code. But I would rather see a typed lisp included instead, because then existing plugins can use it and we don't end up splitting the plugin echosystem and moving towards the javascript monoculture.