you don't have to use coffeescript anymore

[aeosynth]

it's 2016 and what is this

[ccd0]

i do want to migrate away from Coffeescript, but not enough that I'd rewrite everything just to do so. But I've been considering a gradual replacement.

[aeosynth]

in my new projects i use babel and make (instead of grunt)

[ccd0]

Speaking of grunt and make, needless recompilation is something I want to fix: #833

[aeosynth]

make automatically does that, looks at timestamps to figure out what needs compiling

[aeosynth]

makefile tutorial: https://gist.github.com/isaacs/62a2d1825d04437c6f08

[aeosynth]

there's a coffee -> es6 convervter: https://github.com/decaffeinate/decaffeinate. it fails easily, but it should help.

[r3c0d3x]

How should we go about converting it to ES6 without disrupting the current development? Maybe have it on a separate branch until it's completely converted?

[aeosynth]

i mean isn't there already a system where coffee and js get combined?

[ccd0]

@aeosynth That should help if it's not too broken. I suspect some stuff will still have to be handled manually, but we could take it a few files at a time starting with modules we're changing and need to test anyway.

@r3c0d3x We already have a few files in plain JS, and we can run the JS files through babel if needed. Although when browsers are ready I'd like to get to a point where there's no compilation step at all, just interpolating a few templates, linting, and concatenating.

It would also be worth seeing what @zixaphir and @vampiricwulf think of this since if Appchan X continues to be developed it would make merges and/or cherry-picking from/to 4chan X more difficult unless they also make the switch.

[aeosynth]

I suspect some stuff will still have to be handled manually

more like, some stuff might not need too much manual handling

we're already at the point where native js is good enough. i'm using babel mainly for module + jsx syntax, neither of which are used in this project.

[ccd0]

As decaffeinate is right now, all uses of a?() and a?.b have to be converted manually (https://github.com/decaffeinate/decaffeinate/issues/176), as well as many instances of for loops used as expressions (https://github.com/decaffeinate/decaffeinate/issues/156). The lodash templates used throughout the codebase will have to be converted manually regardless of improvements in decaffeinate. And some of the code generated by decaffeinate appears to be broken. So this will definitely be a semi-manual process, but I think decaffeinate will expedite it.

[aeosynth]

you'll convert from your custom template syntax to template literals i assume?

also you could think about embracing the es6 module system, instead of making everything global. rollup is the bundler that i'm using, and it supports adding headers, etc.

[aeosynth]

babel's a generic compiler; you can use it just to compile templates

[ccd0]

you'll convert from your custom template syntax to template literals i assume?

It's mostly just a matter of converting things like

'<%= readBase64('ferongr.unreadDead.png') %>'

(https://github.com/ccd0/4chan-x/blob/1.11.35.2/src/Monitoring/Favicon.coffee#L15) into

`'<%= readBase64('ferongr.unreadDead.png') %>'`

at which point they should convert just fine. The ones like <% if (type === 'crx') { %> are more work, but not used as often.

also you could think about embracing the es6 module system, instead of making everything global.

Probably going to do something like that, but I expect I'll first have to fix a bunch of circular dependencies.

[aeosynth]

you could look at the inline environment variables transform, or maybe make your own transform

modules should be fine with circular dependencies

i'm not familiar with the current state of the code, so my suggestions have to be vague

[ccd0]

That's good, although I want to get rid of the circular dependencies anyway since they make analyzing code changes more complicated.

A bigger concern I have about module bundlers is that if they take more than a second to run and/or have any chance of outputting broken code (and would therefore need to have their output linted), that breaks incremental builds. Rollup in particular looks like complexity I don't need, but a simpler bundler might be useful.

[aeosynth]

rollup is about the simplest module bundler out there; what complexity are you referring to? anything simpler would be the current method of simply concatenating files. any tool has a chance of containing bugs, but module bundlers are a common tool for production use.

edit: rollup does support incremental builds, so the speed is fine

edit2: in the end, i suppose it's just preference. if you're fine with the current build system, keep using it.

[ccd0]

Looking at rollup some more, I definitely don't want to use it for 4chan X, because apparently the output would look something like this http://bit.ly/1rjOwZD with everything combined into one namespace, no indication of what module they came from, and $1, $2, etc. appended to names where there would be clashes. That's fine if you're only ever going to edit the original module files, but users will often want to make edits to the userscripts they've downloaded without bothering with the original source code. Unless there's some option that would change how the imported functions are named, this doesn't work for me.

[ccd0]

I suppose I could do this http://bit.ly/1VTm9hG but then I'm not sure what I'm gaining over just writing it that way in the first place and concatenating everything.

And even that starts to look ugly again if I start to define private functions: http://bit.ly/1ULlKbL whereas what I would do with concatenation is just stick private_function inside an IIFE where Feature1 is defined.

[i-cant-git]

Thank you @ccd0 but you don't have to listen anybody when they have no contributions to the script. I personally like CoffeeScript that I prefer it over TypeScript or ES6.

[ccd0]

Aeosynth started 4chan X, but if people currently contributing or interested in contributing prefer CoffeeScript, I could stick with that. But this isn't just something aeosynth wants, it's something I've wanted to do for a while.

I'm personally worried that the use of CoffeeScript is limiting potential contributors. I do see a lot of people saying that they would contribute if they knew CoffeeScript instead of just Javascript. I am a bit skeptical that anyone who couldn't pick up enough CoffeeScript to work on the project in a few hours would contribute very good code in any language, but even a small barrier can cause people to lose interest.

Another issue with CoffeeScript is that it adds complexity to the build process which can result in errors. These aren't necessarily bugs in CoffeeScript itself, but it's not uncommon for CoffeeScript to surprise people when converted to Javascript. Putting a for loop at the end of a function is an example of something that surprises most people. Arguably this is a matter of people being less proficient with CoffeeScript than with Javascript, but is anyone not more proficient with the latter? You have to know the latter to do the former.

Compilation also makes the build process slower. I'd prefer a build process that wasn't much more than concatenation. Switching to ES6 wouldn't allow us to drop compilation immediately if we want to keep supporting Pale Moon and other minor browsers, as we'd need to use babel until the rebase finishes, but it would definitely mean dropping the compilation step within about a year or so. If any forks don't support the ES6 we want to use by then, we should consider them dead and drop support for them.

[aeosynth]

any update on this? i was thinking converting files could be a neat warmup exercise.

[mahkoh]

I'm personally worried that the use of CoffeeScript is limiting potential contributors.

If I may say so: One obstacle is the size of the repository. At over 400MB it takes more than one hour to do a full clone from github.

[ccd0]

@mahkoh I think I could get it down to ~20 MB if I removed all the builds/ stuff. Then that could go in a separate repository. But this involves rewriting history (although I would keep the old version in the other repository), so let's make this into a new issue for visibility's sake.

Alternately, if you don't need the full history, you can check out only recent history by adding --depth 100 or even --depth 1 to your git clone command line. This is mentioned in https://github.com/ccd0/4chan-x/blob/master/CONTRIBUTING.md.

[ccd0]

@mahkoh New issue: #1107

[hails]

Hey, I'm considering to rewrite this using THE BEST OF THE JAVASCRIPT OF $CURRENT_YEAR Jokes aside, I want to help to write everything using just plain ES6, maybe some webpack + babel (because you know, Javascript)... Let's do it!

[aeosynth]

best js of current year is probably typescript

[ccd0]

I would be more interested in TypeScript if it could detect issues like this:

const dict1: { [x: string]: { [y: string]: string } } = {}
const remoteInput: string[] = ["__proto__", "polluted", "yes"]
dict1[remoteInput[0]][remoteInput[1]] = remoteInput[2]

const dict2: { [x: string]: boolean } = {}
const result: boolean = dict2.polluted
alert(result)

[saxamaphone69]

issue opened 4 years ago

Damn, time does fly.

I assume the decaffeinate process has improved since then? Realistically, what timeline/next steps/more needs to be done to move to away from coffeescript to ES6 (if that's still the current consideration) or otherwise?

[ccd0]

It's just waiting on me right now. The switch and your pull request should be the next things to get looked at when I get around to making major changes again. I intend to update to Coffeescript 2 first which will switch the compiled output to ES6, then modules will have their source code changed into more natural-looking ES6 one by one, possibly with the help of decaffeinate, whenever they get major changes.