KolombikenTrying to read up on the JSSugar/JS0 thing.
Am I supposed to take these slides seriously? š
https://docs.google.com/presentation/d/1ylROTu3N6MyHzNzWJXQAc7Bo1O0FHO3lNKfQMfPOA4o
Pelle Wessman@kolombiken Deleted my previous reply, now actually read the slides, and I like the proposal in some ways, at its core it feels like https://extensiblewebmanifesto.org/ being pitched to the TC39 and I think the extensible web manifesto at large is a good approach for the web
What I donāt like about it:
- The focus on transpiling. High level āJSSugarā features should as far as possible be polyfillable and not require a transpilation step
1/x
- The naming was poorly suggested. JS0 will not be something new, itās JS as it is today, and JSSugar would essentially just be the TC39 opening the door to TS-level standardization, and it shouldnāt really just be syntax sugar so the JSSugar isnāt a good name either
- Iām unsure whether the āJSSugarā is best handled through TC39, through a single spec or if itās something that should be standardized separately by TypeScript, Babel etc.
2/x
I still think back to when jQuery informed the creation of querySelectorAll() within the DOM specification as one of the best examples of the extensible web idea in practice.
In the context of this proposal Iām unsure if a similar approach for a JS extension would have been expected to be speced in āJSSugarā first and only then have parts of it āgraduateā to āJS0ā? If so, then I think that would make it harder to iterate on by tools makers
3/x
Maybe āJSSugarā is imagined as only for syntax sugar like type annotations and decorators (https://github.com/tc39/proposal-type-annotations and https://github.com/tc39/proposal-decorators) and if so then I think that is very fine
A feature like āArray.fromAsyncā (https://github.com/tc39/proposal-array-from-async) is something that either would need to go into JS itself or else be better of as an npm module. If itās anyhow going to be bundled into the transpiled code then the reason to standardize it is slim and it wouldnt make much sense to add it to JSSugar
4/x
All in all: Cautiously optimistic about #JS0 / #JSSugar but feeling that:
1. This is nothing new, itās just a call/reminder to the TC39 to embrace the #extensibleWeb approach to new additions
2. Calling it JS0 rather than JS was really bad and made eg me defensive about it all
3. The focus on transpilation is bad if JSSugar is meant to embrace more than syntax only features
5/5
@voxpelli I might have gotten certain things wrong. But there are a couple of things that I donāt like.
I agree about the focus on transpilation. Itās bad. Itās like they think almost all js on the web already goes through a transpiler. Not true!
Another thing is that I donāt think itās healthy to trust transpilers with getting the implementation right.
Also is this how they want the whole web to work? Or just some part of it?
Iām confused!
@kolombiken Someone had a good point over here: https://mastodon.social/@voxpelli/113339279662731155
That if all this gets standardized, then why would I need to run the tooling before I publish to the web? Why canāt the browser do like eg Deno does and ship with the pre-processor built in?
If thereās a standard way of doing it, why not ship it in the browsers?
@voxpelli Iām guessing same reason as to why you have to compile any language? They canāt imagine doing it directly in the browser will ever be performant enough?
And I really hope none of this is standardized. It has a very much ābreaking the webā-vibe to it. Itās a strength that you can just write something in a document, upload it and it will run. No extra tooling is a good thing!