sweet.js VS proposals

I was ready to be excited from the title, but was utterly disappointed :(

IMO these aren’t macros in the Lisp-sense of the word (or Rust, or even C); yeah they run code at compile time, but that’s where the common ends.

Macros should be able to apply syntactic transformation on the code. Lisp is famous for allowing that by representing code as lists. Rust has a compiler-level API to give tokens and run arbitrary code, then spit new tokens out. C macros operate on the tokens level, so with enough magic you can transform code to the shape you want.

This… isn’t any of that.

A pretty good example (and something I’m still sad that it didn’t take off) of macros in JS is Sweet.js[0]. Babel macros[1] are a bit higher level, where macros require the input to already be a valid AST, but that’s also cool.

This… I’d say it’s more of a build-time code execution feature, not a macro feature.

[0]: https://www.sweetjs.org/

Macros I'd expect to be able to be able to expand at compile time to more code to reduce boilerplate, something like SweetJS.

But yes, I'll tone down my appreciation for writables in this sub, I'll confine my tangents to svelte. A kind of a shame I'd love to talk about using https://www.sweetjs.org/ to make the $ autosubscription work outside of svelte, and the like. But holy off-topic Batman!

Mozilla created SweetJS over a decade ago[0]. It added hygenic macros to JS and I'm sure everyone on the TC39 committee is familiar with it.

There's a lot to like about it, but macros in such a complicated language as JS are hard to get right. They'd also potentially lead to huge fracturing in the JS ecosystem with different factions writing their own, incompatible macro-based languages.

Look at JSX for an example. It's actually a subset of a real standard (E4X -- actually implemented in Firefox for a long time), but just one relatively small syntax addition has added complexity elsewhere.

For example, `const foo = (x:T) => x` is valid Typescript for a generic arrow function, but is an error if your file is using JSX.

I like the idea of macros, but I suspect they made the right call here.

[0] https://www.sweetjs.org/

Sweetjs is unfortunately dead [0] for like 5 years now.

It also doesn't have any typescript awareness which is required to build this kind of functionality - you want to have static type introspection available in macros so you can generate code based on provided types.

[0] https://github.com/sweet-js/sweet-core/graphs/contributors

None of these are supported natively by JavaScript. Macros and ifdefs you could get with your own build step using things like sweetjs or ifdef-loader for webpack. Enums are in a similar boat with TypeScript supporting enums out of the box. But there's also a (very early) proposal to add enums natively to JavaScript as well.

TS doesn’t have monadic do notation, which is something that I want very badly. This would be easy to add to JavaScript with Sweet.js macros, but there’s no equivalent tool for TypeScript. I expect that extending this to TypeScript would be very difficult.

> If forEach is not to be used

That source is simply incorrect. forEach is perfectly fine to use as long as you realize what is happening. It iterates an array where each thing is a function that returns a promise. Of course the results aren't what they expect.

ES5 array additions suffer from being a little too early (though later stuff wouldn't exist otherwise, so...). They are designed to deal with holey arrays (arrays with indexes missing). This is extremely uncommon today, but was decently common once upon a time. They were also created before the iterator protocol.

The real fix is to design iterator versions that can handle things like async generator functions.

> it should be deprecated and removed from the language in a timely manner.

NOTHING can be removed from the language once added. Doing that would break all the older websites that depend on it (technically, a few minor breaks happened after they tested millions of sites and couldn't find anything that was adversely affected). At best, they can block older features from newer features. For example, using class syntax or a bunch of other ES6 language structures automatically makes your code shift into "use strict" mode.

I hope they introduce a "use strict 2" variant that strips away more of the undesirable features than the current "use strict" does.

> Since Javascript is based on C syntax, it should have the preprocessor that the birthplace of C saw it fit for that language not to be without.

That pre-processor was a source of untold nightmares. Direct injection leads to bugs. If someone is going that route, full-blown macros are the only answer. There is a full-blown macro system Mozilla created a few years ago, but it's not very popular.

https://www.sweetjs.org/

There also exist some C-style pre-processors for babel too, but they should be avoided because lisp's gensym is a critical feature that they and C both lack.

The proposal of "syntactic tail calls" to provide an explicit syntax for tail calls, co-championed by committee members from Mozilla (responsible for SpiderMonkey, the engine of Firefox) and Microsoft, was a response to these concerns. However, this proposal is now listed among the TC39's inactive proposals, possibly due to diminished interest, which may stem from the infrequent use of tail recursive functions in JavaScript.

Then there are proposals for new features. Some proposals move through quickly, though some of these will never make it into the spec. They can be available months or years in advance through Babel plugins and other tools. Be aware that these allow you to write code that may never become valid JavaScript, but they can be useful for simplicity and readability, so long as you understand the requirements.

TC39 Proposals

As for what’s new, well here https://github.com/tc39/proposals/blob/main/finished-proposals.md you can research anything from that list that doesn’t look familiar to you.

The latest version of the ECMAScript standard is referred to as ES2022. However, there are almost always something new cooking, which you can use (ESNext) if yo have a javascript engine that implements it, or if you use a polyfill which implements some particular feature for earlier javascript engines.

Here's the full tab list: - https://tjpalmer.github.io/languish/ - https://blog.python.org/2022/10/python-3110-is-now-available.html - https://devblogs.microsoft.com/python/python-311-faster-cpython-team/ - https://github.com/tc39/proposals/blob/main/finished-proposals.md - https://devblogs.microsoft.com/typescript/ten-years-of-typescript/ - https://devblogs.microsoft.com/typescript/announcing-typescript-4-6/#cfa-destructured-discriminated-unions - https://devblogs.microsoft.com/typescript/announcing-typescript-4-9/#the-satisfies-operator - https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/#go-to-source-definition - https://devblogs.microsoft.com/typescript/announcing-typescript-4-8/#build-watch-incremental-improvements - https://openjdk.org/projects/jdk/18/ - https://openjdk.org/projects/jdk/19/ - https://blog.jetbrains.com/clion/2022/07/july-2022-iso-cpp/ - https://en.wikipedia.org/wiki/C%2B%2B23 - https://en.cppreference.com/w/cpp/23 - https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2128r6.pdf - https://devblogs.microsoft.com/dotnet/announcing-dotnet-7/ - https://devblogs.microsoft.com/dotnet/welcome-to-csharp-11/ - https://devblogs.microsoft.com/dotnet/announcing-fsharp-7/ - https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ - https://go.dev/blog/go1.19 - https://go.dev/blog/go1.18 - https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu - https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu#n3017---embed - https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu#n3006--n3007---type-inference-for-object-definitions - https://www.php.net/archive/2022.php#2022-12-08-1 - https://wiki.php.net/rfc/dnf_types - https://blog.rust-lang.org/ - https://blog.rust-lang.org/2022/01/13/Rust-1.58.0.html#captured-identifiers-in-format-strings - https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html#inline-assembly - https://blog.rust-lang.org/2022/05/19/Rust-1.61.0.html#more-capabilities-for-const-fn - https://blog.rust-lang.org/2022/08/11/Rust-1.63.0.html#scoped-threads - https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html#generic-associated-types-gats - https://blog.jetbrains.com/kotlin/2022/06/kotlin-1-7-0-released/ - https://stat.ethz.ch/pipermail/r-announce/2022/000683.html - https://dart.dev/guides/whats-new - https://medium.com/dartlang/dart-2-18-f4b3101f146c - https://medium.com/dartlang/the-road-to-dart-3-afdd580fbefa - https://www.swift.org/blog/swift-5.6-released/ - https://www.swift.org/blog/swift-5.7-released/ - https://www.swift.org/blog/swift-language-updates-from-wwdc22/ - https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/ - https://www.lua.org/news.html - https://www.scala-lang.org/blog/2022/09/05/scala-3.2.0-released.html - https://tjpalmer.github.io/languish/#y=mean&weights=issues%3D1%26pulls%3D0%26stars%3D1%26soQuestions%3D1&names=solidity%2Chaskell%2Cjulia%2Celixir%2Cclojure%2Cperl%2Cgroovy%2Cocaml%2Cgdscript%2Ccmake%2Cnix%2Cvisual+basic+.net - https://blog.soliditylang.org/ - https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html - https://julialang.org/blog/2022/08/julia-1.8-highlights/ - https://discourse.julialang.org/t/julia-v1-9-0-beta2-is-fast/92290 - https://elixir-lang.org/blog/2022/09/01/elixir-v1-14-0-released/ - https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ - https://clojure.org/news/2022/03/22/clojure-1-11-0 - https://godotengine.org/en/news/default/1 - https://ocaml.org/news/ocaml-5.0 - https://tjpalmer.github.io/languish/#y=mean&weights=issues%3D1%26pulls%3D0%26stars%3D1%26soQuestions%3D1&names=gdscript%2Czig%2Cpascal%2Cfortran%2Cnim%2Cf%23%2Ccommon+lisp%2Cwebassembly%2Ccrystal%2Ccython%2Cvala%2Cerlang%2Chaxe%2Cv%2Cd - https://ziglang.org/download/0.10.0/release-notes.html - https://ziglang.org/news/goodbye-cpp/ - https://nim-lang.org/blog.html - https://nim-lang.org/blog/2022/12/21/version-20-rc.html - https://www.erlang.org/news/157 - https://github.com/WebAssembly/proposals/commits/main - https://github.com/crystal-lang/crystal/releases - https://dlang.org/changelog/2.099.0.html - https://dlang.org/changelog/2.100.0.html - https://dlang.org/changelog/2.101.0.html - https://github.com/odin-lang/Odin/releases - https://gleam.run/news/ - https://gleam.run/news/gleam-v0.22-released/ - https://gleam.run/news/gleam-v0.24-released/ - https://github.com/idris-lang/Idris2/blob/102d7ebc18a9e881021ed4b05186cccda5274cbe/CHANGELOG.md - https://github.com/diku-dk/futhark/blob/master/CHANGELOG.md#02111 - https://grain-lang.org/blog/2022/06/06/new-release-grain-v0.5-durum/ - https://rescript-lang.org/blog/release-10-0-0 - https://www.roc-lang.org/ - https://simon.peytonjones.org/assets/pdfs/haskell-exchange-22.pdf - https://vale.dev/ - https://www.val-lang.dev/

[2] tc39 on Github. ECMAScript Finished Proposals.

Check out the proposals page for info on what (may be) coming to JS: https://github.com/tc39/proposals