True! I’d love to hear from someone who tried out both and settled on one.

Sizzy seems to have been abandoned. The developer has been unresponsive and the last update was botched with no way to actually get it. It’s a shame because I preferred Sizzy's experience over the alternatives. It just felt more polished to me.

Looking really cool! Hope there will be talks about implementing this and the benefits that it will bring.

Is this also coming to IOS or are there app store regulations that would prevent apps including Hermes from being uploaded?

It will probably never reach iOS since App Store rules prevent engines from JIT’ing (is considered “arbitrary code execution” and could circumvent their own static sandbox verification requirements).

theres the AbortController [1] that can be used on a few new promise based APIs such as the Fetch API [2]

[1] https://developer.mozilla.org/en-US/docs/Web/API/AbortContro...

[2] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

But there's no easy way to inject this AbortControl into existing libraries, or use it easily with async/await. I'm looking for an easier standard.

React team members seem to be hinting at some sort of official "adopt" (https://github.com/pedronauck/react-adopt) api which would allow for a slightly nicer way of getting access to render prop arguments. (although you still done get access to them in lifecycle methods). In the meantime this seems pretty nice: https://github.com/Astrocoders/regenerator

Would be interesting if it would be possible to take the Rust approach and guarantee at parse/compilation time that the DOM interactions are safe without runtime overhead. Probably a terrible idea for mobile devices though...

That would only work if it isn’t shared with unsafe code.

The graphs for major programming languages shows a decline in the number of monthly active users using JavaScript, interestingly this decline seemingly coincides with the incline of TypeScript users. I'd love to see whether people who stopped using JavaScript started using TypeScript instead.

It's also a bit strange in that Flow and TypeScript are competing JS language extensions with nearly the same goals and scope, yet TypeScript is seen as its own language and Flow isn't. And, of course, JSX isn't valid JavaScript, but React programmers view themselves as writing code in JS. IMO, it would be better to put TypeScript projects in the JavaScript category and optionally have more detailed stats on the different JavaScript variants.

When I introduced TypeScript to my team at work, one of the things that I had to emphasize was that TypeScript isn't a new language; it looks and behaves just like JS, it just has some new syntax to declare types.

I suppose the practical matter here is that GitHub language stats can distinguish TypeScript because it uses the .ts extension, while other JS variants just stick with .js (and JSX sometimes is .jsx, but not always).

Of course! When my company decided to embrace javascript, I spoke out against javascript and pushed for typescript, the entire engineering team is writing typescript instead of javascript.

Its called literate programming; for example https://wiki.haskell.org/Literate_programming

Some examples of "transpilers" targeting Javascript but writen in other languages:

https://github.com/google/closure-compiler

https://github.com/BuckleScript/bucklescript

https://github.com/fastpack/fastpack

Seems like on the average it does offer a boost in performance.

And there is some aditional work providing javascript parsers for rust (which you could build tools like babel on top of): https://github.com/dherman/esprit

I think part of BuckleScript's speed may come from the source language, OCaml, being easier to parse. There may also be fewer passes necessary to transform OCaml to JavaScript.

BuckleScript using Reason (with a similar syntax than JS, slower parser than vanilla OCaml) is still one of the fastest around. Mostly a case of very careful and dedicated engineering here (I work on Reason with the author of BuckleScript). Additionally, we try to work smart and delegate most of the build process to Ninja, which itself is one of the fastests around.

But I believe the topic here was about runtime performance of using a language to compile JS, not about the build speed of working in that language itself. In which case you’ll still get some wins writing a JS toolchain in BuckleScript (compiled to JS), just from the JiT-friendliness of the BuckleScript JS output.

But realistically, you’d be compiling to native OCaml through the same codebase. We did see a 10-25x perf jump from converting a part of a Babel pipeline to native OCaml. I mean, these languages are basically designed over decades with AST manipulation in mind, so that’s not surprising.

I agree so much. The first season was amazing with the split story line between the main crew and Miller on Ceres but it all went downhill when the proto-molecule was introduced and suddenly there were massive shootouts (with characters who admitted only episodes earlier to never having killed/fired a gun)

I really love the political aspects and cultural differences between the various factions though.

> I really love the political aspects and cultural differences between the various factions though.

Same here, I was quite annoyed when the books veered away from the excellent political stuff into the silly alien monster stuff.

If anyone is looking for a book series that doesn't veer away, I'd recommend John Scalzi's Collapsing Empire. If anyone knows any others please suggest!

Isn't announcing you've never fired a gun in a fictional work an example of Chekov's Gun? By announcing it the narrative is setting up the "dramatic tension" ahead of when the character is confronted by a situation potentially requiring firing a gun or killing someone.

That's kind of ironic. Although macgyver said he hated guns and managed to never fire them

Didn’t he build a shit ton of bombs to “solve” various problems though?

I never said he was a pacifist, he just doesn't fire guns

the `=>` de-sugars to:

    var currentUrl = function(_) {
        return window.location.href;
    }

the underscore is used so they don't have to type `() =>` instead

Ahhh. I think I was confused why referring to `window.location.href` would be needed to be put into a function, and then called as `currentUrl()`, rather than having currentUrl be a string value. Is this best practice? I mean, is there some `window.location.href` isn't a global object?

Because the value may change. If 'currentUrl' was a constant (eg. `const currentUrl = window.location.href`) it would capture the href at the start of the application, even though it might change later on (history API, pushstate etc).

Why wouldn't you just reference `window.location.href` when needed, instead of wrapping it up in `currentUrl`?

Yeah that was my question. I was racking my head thinking of when this window.location.href wouldn't refer to what a program would want given how it almost acts like a global function in some ways (e.g. `window.location.href="http://example.com"` can be used to change the page). Maybe currentUrl is supposed to be a wrapper just incase window.location.href changes (which seems highly unlikely but again, I'm out of the loop with modern JS).

Some snippets, like this, read a lot like codegolf functions.

Code Golf is about using the most terse syntax (and frankly, showing off while doing it).

This was a new syntax added to the language spec to reduce the amount of boilerplate required for common tasks.

Also, the "fat arrow function" handles "this" different inside of the function, so it can serve a slightly different function and in many event-handling cases it can be even more terse than traditional JS functions.