266 karma · joined March 28, 2016
> "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."
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
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.
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)
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!
> 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.
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.
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.
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?
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",
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.
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
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
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 work on Babel)
atm you have to add `<?php` at the beginning.
Basically, if there is native support but it's not as fast as compiled/polyfilled we could continue to compile.