ES6 & rollup

[lukeapage]

I'd like to (if I ever get time)

• move libs to es6/
• transpile es6/ to an es5/ folder
• use rollup to build a browser single file

It would be a new major release and I'd also remove the browser bundled promises as I've mentioned in other issues.

Any objections before I just do it? I'm not going to start converting everything to es6 other than the requires (for rollup) but other people are free to use less.js "upgrading" as a way of learning es6 if they like.

---

Update by @matthew-dean -- I ended up keeping lib/ in the same folder to keep (some?) of git history, instead of transpiling (up-transpiling?) and moving at the same time. The modules don't compile to es5/ either or the equivalent. Instead, there's a CommonJS single-file build for Node 6+, as well as a browser build.

[matthew-dean]

Nope. I've been thinking along the same lines for a while. What about using TypeScript? It might make development / contributions easier to have code hinting / real object linking. Although I don't know if this would put a knowledge burden / barrier then.

I was also thinking along the same lines that we should consider using es6 collections for parsing / AST and then using a polyfill for es5 builds like https://github.com/Benvie/harmony-collections. In es6 environments (which Node.js now is, as are latest browsers) that should theoretically speed up parsing / evaluation because of the reduced memory overhead and faster AST construction.

[lukeapage]

What about using TypeScript? It might make development / contributions easier to have code hinting / real object linking. Although I don't know if this would put a knowledge burden / barrier then.

We can consider that after ES6 - es6 doesn't preclude typescript since typescript is an es6 transpiler too.. it would be an additional step after this.

I personally wouldn't recommend typescript unless there was going to be significant extra work or refactoring in less. IMO typescript

• + makes development for new people who know typescript easier
• + increases maintainability
• • requires people know or learn a minimal amount of typescript
• • takes longer to write code so that it is typed

I was also thinking along the same lines that we should consider using es6 collections for parsing / AST and then using a polyfill for es5 builds like https://github.com/Benvie/harmony-collections. In es6 environments (which Node.js now is, as are latest browsers) that should theoretically speed up parsing / evaluation because of the reduced memory overhead and faster AST construction.

I wouldn't use that polyfill, the project looks dead (perhaps also because the name harmony is dead).

Also I unfortunately wouldn't be sure that the ES6 native equivalents are faster - https://jsperf.com/property-access-object-array-map-weakmap/6. Its sad how for instance the Promise polyfill is faster than the native implementation :(

[listepo]

👍

[matthew-dean]

All good points. Standardizing on ES6 / Babel often makes things not only easier to write, but read, especially when doing prototypical inheritance.

As far as that jsperf test, it's not really a fair example. I'd expect Weakmap to perform slower for that specific test. In theory, it might be better for Less in creating a bunch of different object shapes and types and then evaluating them. Not sure though. I found a few good libraries that I want to eventually test (and hopefully add) where we can hook into individual functions to do granular benchmarking, without having to put any "benchmarking hooks" into the lib. I'm hoping to set something up (when I have time, who knows when that will be) so that you can do a kind of jsperf test on functions within Less.js, but with local development / branch changes to Less vs. the current release, and using a few kinds of test .less files. As I've mentioned before, we shouldn't need to guess which is faster for our particular use case. We could theoretically sub in a WeakMap at some function level vs. raw objects, run benchmarks on that location, and decide based on outcome.

[rjgotten]

@lukeapage wrote:
IMO typescript

• + makes development for new people who know typescript easier
• + increases maintainability
• • requires people know or learn a minimal amount of typescript
• • takes longer to write code so that it is typed

And one unmentioned, very significant benefit you are skipping over:
TypeScript's typed mode forces you to use stable variable types, which enforces stable type shapes, which improves the compiler's ability to both statically and dynamically analyze your code, which produces much better optimized code and stops (or at the very least dramatically reduces) backouts from optimized code back to slow interpreted code.

Moving to TypeScript would probably contribute more than moving to ES6, imho.

[lukeapage]

By typed mode you mean the forbid Any? I tried that on a small project and I had annotations everywhere.. it ends up with alot of code because the transpiler isn't super clever. as to how many variables have mutated variable types, im not sure. so.. not convinced the performance benefit would be noticeable.

[matthew-dean]

@rjgotten I haven't used TypeScript but those are good points. If you are using an intellisense/autocomplete environment for TypeScript, it might actually help new contributors since it would complete types / object shapes as you make changes. Properly designed, it could serve as a kind of self-documenting / familiarizing / error-preventing tool to someone contributing code changes. But the key there is probably in the TypeScript design.

Overall, would there be a performance benefit? That's harder to determine. That's more the artist than the canvas.

Even though I'm aiming to use TypeScript for my own projects, I'm probably a little more inclined to agree with @lukeapage, primarily because, unless any of us here are TypeScript experts, I'm not sure we could make effective use of it initially.

Also, moving to ES6 doesn't prevent using TypeScript in the future. Microsoft / Google's goal is to make TypeScript 2.0 an ES6 superset, so we could always start with ES6 / Babel, and later add proper types and switch to the TypeScript transpiler. My suspicion is that TypeScript is going to "win" the transpiled languages, just because the compile-time / autocomplete benefits are so much greater over non-typed JavaScript. So... I guess that means that I think using TypeScript is probably inevitable, but that doesn't mean we have to use it right away.

[matthew-dean]

I would like to discuss a different architectural approach to Less at some point, but that's more of a tangent discussion to this.

[rjgotten]

By typed mode you mean the forbid Any?

No. Just using typed variables in general. You can forbid use of Any in general, but it's (atleast practically) a bad idea because it tends to lead to lots of code bloat to just satisfy the typing system.

However, the use of typed parameters on a function does mean that callers (atleast callers written in TypeScript) must respect the type given. That means typed functions can be used to protect type stability on the inner workings of the Less compiler where appropriate and guarantee that particularly important functions will be well optimized. (Don't forget; JS engines generally optimize at the function level...)

[lukeapage]

work started - https://github.com/less/less.js/tree/rollup

[matthew-dean]

Pretty cool work. Germaine to the discussion, I was looking at the code and quickly came across:

if (typeof index === 'number') {   

AFAIK that type of sanity check would never be necessary in TypeScript. If the index type is being converted at run-time to string every time to do a string comparison in order to check the type of value, things like that can add up. In TypeScript, if there was a call to a function that passed an index, but that type was sometimes not a number, and index only accepted a number, then the function would fail at compile time because of mis-matched types, rather than needing to be tested at run-time, when such checks are more expensive.

On the other hand, it could be that this is an isolated and rare example; it's just something I came across that seemed relevant.

[SomMeri]

I think that the biggest advantage of explicit types is that it allows more powerful tooling. Finding all (and only) places that call a function or override it is just a keyboard shortcut away. Finding out which functions the objects you have available is zero work and refactoring is safer because compiler generates more errors. It makes it also easier to learn new codebase - getting big picture, finding out which part of code depends or follow code flow without running it is harder in javascript then in java (for example), because typed editors are more powerful.

I did not used TypeScript yet, so I do not know whether tools are mature enough to make it worth it. Advantage of javascript is that everyone knows it, TypeScript is less known.

Overall, I think that move to TypeScript would make sense if we planned some kind of bigger refactoring or huge new features, but it might be too much work while we are just fixing small bugs.

[matthew-dean]

I think that move to TypeScript would make sense if we planned some kind of bigger refactoring or huge new features, but it might be too much work while we are just fixing small bugs.

This may be the case, and really, to be pragmatic, @lukeapage has already taken on the work so I'm inclined to say he should make the final call at this time. :-)