Post by Amos in [Meta] itch.io

Viewing post in [Meta] itch.io

Quick update: Continuous Integration is now mostly set up, our CI server is running (and publicly readable) at:

https://ci.itch.ovh/

(That domain name totally isn't hiding other cool stuff behind login or whatever)

And our configuration lives in a private BitBucket repo (although since all credentials are privately held by the CI server itself, it might not even make sense to keep that closed-source either). It's all being built by cigale, which can now use the Jenkins API to create and update job configurations.

So, jenkins is orchestrating various tasks being ran on Windows, Linux & OSX computers/VMs, and it'll help us push new version of stuff quickly and help spend less time doing mindless maintainer tasks.

In other news:

Today I've always taken a look at trying to make itchio-app run without transpiling ES2015 to ES5 using Babel, because that step has gotten slow (installing dependencies to do so takes forever, and it's an annoying step when iterating on something).

I've come up with a minimal electron app that does several things the itchio app really needs. I've opened a GitHub issue to track my progress on this, I believe it would really be a step forward and it might not even require that much work!

https://github.com/itchio/itchio-app/issues/66

That's it for today, thanks for following!

Like Reply

Elisée8 years ago(+1)

Interesting experiment getting rid of transpilation. No way we could do it for Superpowers anytime soon since we're in browsers a lot and have to browserify so much. But I'm excited for the day where ES2015 modules + HTTP2 makes it possible to do a lot of raw stuff again. Though I love them types too...

Have you tried using watchers for quick iteration? I don't know if babel has any, but TypeScript does tsc -w and browserify has a watchify counterpart, I think they are pretty fast. Still, it's more stuff to run and keep up-to-date...

Like Reply

leafoAdmin8 years ago(+2)

The babel performance stuff is pretty bad, even when using a watcher. I was building another project on my netbook (admittedly a slow computer) and it took 10 seconds (!) to compile a single 400 line es6 file. There's so many people using it now I'd be shocked if it wasn't improved rather quickly, but still it's pretty wild that it got launched like that. (On my desktop it takes about 1.5 seconds for the same file, for comparison)

Like Reply

Amos8 years ago(+1)

Yep, you can check in the Gruntfile, it's incremental already. If it wasn't it would've become unbearable a lot sooner!

Note that Babel's performance got worse in the 6.x series, which is a shame (my understanding was that it was supposed to eventually become faster).

By comparison, I remember TypeScript's incremental recompilation to be a lot faster, but it comes with its own set of compromises

For now, carefully writing vanilla ES2015 + tests seems like a really attractive option :)

Like Reply

grifdail8 years ago

Using webpack (and webpack-dev-server) give you as small boost as it recompile only what have change. (It not the case with thing like browserify or most babel version). By switching from gulp+babel to webpack (both with watcher) I was able to go from a 5sec of compilation every time I changed a file to instant compile.

Like Reply

Amos8 years ago (1 edit)

If you read carefully the old Gruntfile.js, you'll notice it was already using a watcher, only recompiling changed files (cf. newer task), and loading babel only once. (I did manage to get a similar setting with gulp and watchify but it was significantly messier — my experience is that gulp is verbose more than it is flexible...)

And yet, getting rid of that transpilation step, be it 5s from scratch (+ maybe several minutes or more of npm install) that has to be run on every CI run, or ~1s of recompilation, that I still have to worry about when developing, is freeing. More than once, I've gotten bit by relaunching the app before transpilation was over, or relaunching it while transpilation had failed with an error and it was buried in a console somewhere.

I appreciate the help trying to make Babel work for us, but I'm not trying to make it work for us anymore, it's simply come to a point where both Node.js and Chrome support most of the features we were using Babel for anyway (except for async/await, which nodent does better than babel anyway), and getting rid of transpilation is simply a mark of the language maturing. We couldn't have done it even a few months ago, so really, it's all good news :)

Like Reply