Would there be any interest in converting Less to Rust (or other language?)

[matthew-dean]

There has been a lot of great examples of tools in the JavaScript ecosystem being converted to (or built in) Rust / WASM for tremendous speed improvements, such as SWC. I personally feel that Rust is probably going to become more and more of the "web" workflow, and probably more of the Node.js workflow as well, although it has a steep learning curve.

A Rust-based Less compiler would, in theory, be extremely fast with low overhead. And it would actually make Less more viable in browser-based compiling scenarios. (Again, in theory.) I started tinkering with a Rust / WASM setup here, using Pest as the basis of the Less grammar, although I ran into some issues with Pest. (I'm not sure that Pest is the right solution, since no one has commented on that issue, which is a shame because it would make the grammar very self-documenting. There are a few parsers / parsing tools in the Rust ecosystem, and I think someone would need to dive into pros and cons.)

The hitch to all of this is: I don't really have time to work on this personally, BUT I could certainly help steer planning, features, testing, alignment with Less.js, etc. It's a big undertaking, and would probably need more than one interested developer.

I think the first step is assessing interest. Also, if someone would have objections to a future version of Less being written in Rust, this would also be a good place to mention that and why.

[cedx]

If browser usage is not abandoned... why not? But then, it would probably be hard to maintain 2 code bases (i.e. JS + Rust).

[matthew-dean]

If browser usage is not abandoned... why not?

It's not abandoned. The documentation alludes to it being not entirely supported. However, there still is an ongoing browser distribution. As to why, there are special use cases where people want to style based on "live" variables, such as a site that allows someone to modify colors / themes on the fly. I wouldn't focus a lot on the browser part; I'm just pointing out that it makes it a more viable option and possibly easier to support if everything is compiled to .wasm.

it would probably be hard to maintain 2 code bases

I'm not proposing maintaining 2 code bases. I'm proposing migrating to a different code base.

[cedx]

OK. So my only objection is that it will be a little more difficult to contribute to this project. But since I'm not a contributor... go for Rust 😄

The documentation alludes to it being not entirely supported.

Hmm... I don't see anything like that in the documentation. It just seems to discourage its use.

[shawn-yee]

There are currently fewer project maintainers, and if switch to another language with fewer users, there will be fewer maintainers and more problems will be difficult to fix,more new features are also difficult to keep up with.
The css field is very different from the JavaScript field.There are plenty of companies and sponsors out there.

[ancientstraits]

Although I'm more of a C/C++ programmer than a Rust one, I still do know some Rust and think I can help contribute. I wonder if we could write the whole compiler ourselves without any external libraries, even though that seems extremely inefficient. It would be a long road to completely replacing the JS Less, but since other JS project have already started to use Rust (such as Next.js), the transition should be feasible.

I will start trying to contribute to the Rust repo you have linked in your original post.

[matthew-dean]

I wonder if we could write the whole compiler ourselves without any external libraries

I really wouldn't advise that. Probably the next best approach to generating a parser via a defined grammar is using a parser combinators library. The most popular one seems to be nom -- https://crates.io/crates/nom

[matthew-dean]

This is another one that seems quite popular and seems to be well-maintained -- https://crates.io/crates/lalrpop

[matthew-dean]

Oh, one thing you have to be aware of is that CSS, and Less by extension, is a context-sensitive grammar. So any parser that is context-insensitive and has a tokenizer phase (like it appears LALRPOP does) likely will not work.

As an example, a:b is an a element with a :b pseudo-selector if it's within selectors, and it's an a property with a b value if it's within a qualified rule's curly block. And, if we're within a custom property's value, it's a whole different set of rules.

The example below is valid CSS.

a:b {
  a:b;
  --a:a:b;
  /* this would be invalid -- a:a:b; */
}

[ancientstraits]

@matthew-dean Thank you for all of this information. I have been experimenting with parsing in the past week, but I have also had some other work to do. I will try to work on this, though.

[iChenLei]

I perfer maintain a pure JavaScript(TypeScript) project

[vikaskaliramna0]

Maybe start supporting first class Deno support instead of Node.

Benefits of using Deno instead of Node -

1. TypeScript support directly, with browser APIs
2. Supports npm modules, so you can import dependencies from npm even if your project is written in Deno.
3. Built in tools for lint, formatting and building an executable file(for CLI)
4. Get rid of legacy code and write modern code.

Why re-write in Deno? Deno developers do not have any good css preprocess that has first class Deno support.
Dart still does not work with Deno, it would be great to maintain a Deno version. It would work in Deno, Browser and a CLI for major platforms - Windows, Linux, Mac.

Deno core team has also provided a DNT package, to convert Deno projects to npm packages.

Lots of benefits.