HN user
Thanks for sharing, I'm very interested in how his ideas might help us understand open source as well! Actually just posted a few chats recently on Illich, the last one speaking on this and related essays. https://hopeinsource.com/illich, https://hopeinsource.com/silence
"a commons is a space which is established by custom. It can not be regulated by law. The law would never be able to give sufficient details to regulate a commons."
Thanks for sharing @andy_adams! Henry here, happy to chat with y'all (Victor and Tony) if you'd want
haha oops I totally wasn't looking at who I commenting with, definitely agree! Thanks!
Yep there's been various PRs for perf over the years but it's never been a focus per-se, and we've had help from various people including the v8 team https://twitter.com/left_pad/status/927554660508028929. Haha yeah no one wants to hear about open source sustainability in a thread about asking that tools be correct/fast/easy to use at the same time :D
It's true, speed is not really a concern on my mind at the moment - rather that we have enough people even willing to contribute back at all
Yeah I've had a difficult time figuring out how this was tested:
I would recommend using the benchmark at https://github.com/v8/web-tooling-benchmark in the future if it's currently not possible since currently it only seems to be testing ES5 (jquery.min.js) for the parser and a short ES6 snippet for the transforms.
If you can use test262's test suite you should be good, it looks like they are referring to Babel's tests for some of the features? example https://github.com/swc-project/swc/pull/86, I just checked really quick though.
In terms of perf, I'm sure rust will be much faster than JS. And this project's main goal is to be a faster version than Babel. I would suggest the perf test would be different though because it's testing code I would consider not to be representative of what Babel actually runs on. Example with the transform test: https://github.com/swc-project/swc/blob/222bdc191fcab7714319... it's a very small file with minimal transforms even necessary at all. And the parser test is for all minified js files, none of which are written in ES6+ https://github.com/swc-project/swc/blob/master/ecmascript/pa.... Currently it's not really testing ES6+, just how at a baseline it's much faster to process a ES5 file, so it's possible that it might be even faster.
edit: I will note that Babel does a lot more than what this project is doing currently (plugins, other proposals, ts/flow, sourcemaps, etc) but this is more about what could be so if people are willing to more on this effort in the long run (with funding/support/people) it could be super useful! I'm curious about how that will work when our project has such a struggle with contributors and Babel itself is written in JS. (I work on Babel :D)
We certaintly have PRs around perf https://github.com/babel/babel/labels/area%3A%20perf but we don't have explicit benchmarking for it, and have had work from v8 team and others https://twitter.com/rauchg/status/924349334346276864?s=20.
Henry here, didn't expect this post to ever be on HN heh!
The podcast is a 10 episode series (pre-recorded it over the last 5 months) with my friend Nadia (who isn't religious)
I'm writing up a post about making it from scratch (never made a podcast before) and will post it soon as well!
I also really liked the follow up on the three virtues, in the 2nd State of the Onion (http://www.wall.org/~larry/onion/onion.html)
Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.
These are virtues of passion. They are not, however, virtues of community. The virtues of community sound like their opposites: diligence, patience, and humility.
They're not really opposites, because you can do them all at the same time. It's another matter of perspective. These are the virtues that have brought us this far. These are the virtues that will carry our community into the future, if we do not abandon them.
If dependencies are an issue, I would like to make another package that just bundles it all into 1 package (reuse `babel`) so there aren't any "deps" to install but haven't gotten around to doing it, would be a useful contribution opportunity for someone though.
thanks for posting! I personally usually just use https://babeljs.io/repl/build/master!
Yeah, I did this for my Patreon as well (some people donate less but it's not the majority) https://www.patreon.com/henryzhu (I also quit a few months ago to do open source on Babel ). Maybe also depends on audience and type of Patreon (open source vs video/content creation)? I also tried to get a little creative with my tiers based on I what I liked: it's hard to justify making rewards for people when you already provide a service through working on open source already without it turning into more of a 2nd job though. Lots to talk about with that.
I work on tooling for a living, and have in fact tried to contribute back to babel but unfortunately there's so much noise and traffic that there's just as good a chance that your PR is stuck in limbo forever than being merged or even reviewed.
I agree it's a two way street and not all maintainers want to be "purely" what people consider a maintainer role unlike me - but it's a lot of responsibility on their part to have to look at every PR in a certain amount of time. I think contributors could also do more to ask and get involved although it will take more energy on both sides parts: like doing a hangout/video call etc even though it feels like people either maintainer or contributor just think making a PR suffices to get something merged when a lot of times it is so much more.
I think what I'm saying is that if you do get the time to make a PR and if employers allowed it, they should also allow for the time it takes to get through the noise and traffic by helping out with maintenance, not just the bug fixes, or that we need a priority kind of thing so that maintainers/contributors see effort from one another to make it better. Yeah it's definetely not that simple but I think we need more people/companies trying it out to really see what the problems are then just talk about it.
* From my measurements, TypeScript is quite a bit faster than Babel at compiling ES2017 to ES5. From a quick test, TypeScript took 35 seconds and Babel took 140 seconds when run on my codebase at work.
Hmm, I would of thought it would be the opposite but I guess it depends on the setup?
* TypeScript is probably easier to set up and configure.
Yeah given it's more of a "language" TS can decide on those defaults although you can just make your own preset for your company/project as well. I think we can fix that too with a default/separate thing but not sure yet.
Yeah I was hesitant due to not that much support in the community, etc but after hitting the typo-squatting issue over like 5 times (you'd think once would be enough) it just had to be done. There are other issues for our plugin ecosystem since people fail to know which ones are from us and which are just another plugin.
I think before they were part of the paid npm plain or just not enough information about them, and the questions on what being an npm org meant, etc. Maybe Babel switching to them will help move that forward even?
From what I understood, there is currently nothing to allow both ES5 and ES6 code to be published and let the bundler choose which one to include. Any ideas on how to change this?
Yeah it's mostly a conventional then we have to figure out.
Some people have different "dist" folders like say with redux_- https://unpkg.com/redux@3.7.2/ there is `src`, `lib`, `es`, `dist`.
In package.json, you can specify
"main": "lib/index.js",
"module": "es/index.js",
"jsnext:main": "es/index.js",
"typings": "./index.d.ts",
Hmm, sorry it feels that way! I don't use react-native and don't think anyone on the team was informed of that issue - but is it really an issue from Babel itself?
I guess in that case I would suggest not transforming files like ".json" which if it's a wrapper around Babel could do for you automatically? It's not intended to transform JSON since it would just have the same output, not sure how it's related to compiling JS specifically.
Oh cool, didn't realize someone posted to HN (I haven't been on HN in a while =D)! Open to questions and clarifications (on the actual content of the upcoming release, process, how to help, future, whatever)!
There are a few things we need to do like a upgrade tool and some other things that haven't been addressed like how library/module authors should publish to npm (do you include/exclude polyfills, do you compile down to ES5 or start introducing ES6+ code under a different folder or package.json string like "module" or "es2015" which will be out of date, etc)
Also didn't write much about the Typescript support yet but we want to help people use that too if that helps with their development
Yep you got that right!
Only thing I can think of (since changing the default to be non-spec would be odd) is just warning on larger code size outputs and saying you could try loose mode in certain plugins/situations. Lastly would be do start creating a tool that does runtime checks to determine how small the compiled output should be
I answered this on twitter: https://twitter.com/left_pad/status/936721918840983554
And added this option + optimization for v7 https://github.com/babel/babel/tree/master/packages/babel-pl... so can look forward to that now =D.
I'll update the post to give an idea of how it works, thanks!
Yeah, it doesn't doesn't anything that is multi-file like const enums since Babel operates per file.
(I work on Babel)
Gave a talk at React Rally that goes over this briefly. https://github.com/hzoo/so-how-does-babel-even-work, and a basic version of the actual Babel transform: http://astexplorer.net/#/gist/ccb201a61db3d581c8be3161bf7806...
It's parseable in Babel 7, issue to implement the transform is https://github.com/babel/proposals/issues/2
The purpose of https://github.com/babel/babel-preset-env is that it handles all this automatically (not run when it's supported natively)
If anyone wants to try this out (I did), just added it to the Babel website! https://babeljs.io/php
atm you have to add `<?php` at the beginning.
Yep, if anyone can/wants to help out with this effort I would follow/review the issues/PRs in our typescript label https://github.com/babel/babel/pulls?q=is%3Apr+is%3Aopen+lab... (I help with Babel). We'll be working with the TS team to definetely get some better docs on how to setup both Babel and TS once we land the changes in Babel and release 7.0
Yeah a good idea. I was thinking we could make a similar table to compat-table (maybe using six-speed or this) that we could use as data to https://github.com/babel/babel-preset-env so that Babel could compile based on the compiled speed relative to native support. Haven't really looked into in much yet (if anyone is interested, let me know)
Basically, if there is native support but it's not as fast as compiled/polyfilled we could continue to compile.
It's just about moving a dependency up a level of node_modules if they are compatible. So if for example 2 packages A and B have the same dependency on babel-core, instead of node_modules/A/node_modules/babel-core and node_modules/B/node_modules/babel-core you could just have node_modules/babel-core.