Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

you don't have to use coffeescript anymore #829

Open
aeosynth opened this issue Apr 2, 2016 · 37 comments · May be fixed by #3341
Open

you don't have to use coffeescript anymore #829

aeosynth opened this issue Apr 2, 2016 · 37 comments · May be fixed by #3341

Comments

@aeosynth
Copy link
Contributor

aeosynth commented Apr 2, 2016

it's 2016 and what is this

@ccd0
Copy link
Owner

ccd0 commented Apr 3, 2016

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
Copy link
Contributor Author

aeosynth commented Apr 3, 2016

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

@ccd0
Copy link
Owner

ccd0 commented Apr 3, 2016

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

@aeosynth
Copy link
Contributor Author

aeosynth commented Apr 3, 2016

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

@aeosynth
Copy link
Contributor Author

aeosynth commented Apr 3, 2016

@aeosynth
Copy link
Contributor Author

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

@r3c0d3x
Copy link
Contributor

r3c0d3x commented May 19, 2016

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
Copy link
Contributor Author

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

@ccd0
Copy link
Owner

ccd0 commented May 19, 2016

@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
Copy link
Contributor Author

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
Copy link
Owner

ccd0 commented Jun 12, 2016

As decaffeinate is right now, all uses of a?() and a?.b have to be converted manually (decaffeinate/decaffeinate#176), as well as many instances of for loops used as expressions (decaffeinate/decaffeinate#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
Copy link
Contributor Author

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.

ccd0 added a commit that referenced this issue Jun 12, 2016
@aeosynth
Copy link
Contributor Author

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

@ccd0
Copy link
Owner

ccd0 commented Jun 12, 2016

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
Copy link
Contributor Author

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
Copy link
Owner

ccd0 commented Jun 12, 2016

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
Copy link
Contributor Author

aeosynth commented Jun 12, 2016

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
Copy link
Owner

ccd0 commented Jun 12, 2016

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
Copy link
Owner

ccd0 commented Jun 12, 2016

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
Copy link

i-cant-git commented Jun 12, 2016

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
Copy link
Owner

ccd0 commented Jun 12, 2016

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
Copy link
Contributor Author

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

@mahkoh
Copy link
Contributor

mahkoh commented Sep 24, 2016

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
Copy link
Owner

ccd0 commented Sep 25, 2016

@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
Copy link
Owner

ccd0 commented Sep 25, 2016

@mahkoh
New issue: #1107

ccd0 added a commit that referenced this issue Sep 30, 2016
@hails
Copy link

hails commented Sep 16, 2017

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
Copy link
Contributor Author

best js of current year is probably typescript

@ccd0
Copy link
Owner

ccd0 commented Mar 29, 2020

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
Copy link
Collaborator

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
Copy link
Owner

ccd0 commented Mar 29, 2020

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.

@saxamaphone69
Copy link
Collaborator

Happy to help and assist in any way, and as always, look forward to seeing 4chan X continue to develop/improve/add features and appreciate the effort you put in.

@aeosynth
Copy link
Contributor Author

aeosynth commented Mar 29, 2020

fyi es6 = es2015 and is now 5 years old. most of es2020 is supported by my browser (firefox), except for 2018 regex features

https://en.wikipedia.org/wiki/ECMAScript#Conformance
https://kangax.github.io/compat-table/es2016plus/

@aeosynth
Copy link
Contributor Author

aeosynth commented Mar 29, 2020

Damn, time does fly.

everyone from the old crew is or is approaching boomerhood.

@saxamaphone69
Copy link
Collaborator

boomerhood

My first userstyle for 4chan was 2009. 11 years later and I'm still doing the same shit. Boomer confirmed.

@aeosynth
Copy link
Contributor Author

aeosynth commented Feb 3, 2022

any updates? i see you're still using coffeescript 1.x

@TuxedoTako
Copy link
Contributor

I started a fork to a js/ts migration. It's still work in progress, but I'm optimistic I can get it fully functional soon™. https://github.com/TuxedoTako/4chan-xt

@aeosynth
Copy link
Contributor Author

4chan x lives on

@TuxedoTako TuxedoTako linked a pull request Mar 3, 2023 that will close this issue
30 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants