Minify code for character count

[Ayplow]

Just came across the site today, and the concept is awesome, but I am finding the nature of 'make your code small' unhelpful in creating a site which people could learn from. It seems like it wouldn't hurt to allow more readable code, and minify it to test the character length. This would allow comments describing the behaviour and more useful variable names.

[dwitterer]

We've mostly covered this issue on Discord, and I don't think you're part of our server over there, so I'll sum it up here too:

• Dwitter's primary purpose is to challenge people who can already code in JS to create cool-looking canvas demos using as little code as possible. While making it learner-friendly would be nice, you'd be much better off looking at resources online which are written for the people learning JS, like tutorials, et cetera...
• One thing we could do, however, is to add a field where people can post their original code, as well as the "golfed" version (kinda like some JS1K submisssions)... However, that's kind of unnecessary, and we're currently working on some other things - feel free to work on this yourself if you want to :D
• Also - while this feature is not currently implemented, people can always post a pastebin link to their code in the comments. However, most people tend not to do that, unless the code has been compresed.
• Finally - keep in mind that most dweets are made by people playing around with canvas to eventually create something cool, so there won't always be an "original" version per se...

Discord people can correct me if I wrote anything wrong :)...

[dwitterer]

Also also, codegolf.tk has been mentioned - it's like a legacy dwitter, for code that's just a bit too long for dwitter. Some have also mentioned that allowing code over 140 might allow for dangerous code and exploits like data ultraporting, and the like.

[joeytwiddle]

Re-reading Tom's suggestion, if we interpret it like this then it seems to fit with the spirit of Dwitter:

• Allow code to be written with newlines, indentation and comments, for readability.
• Let Dwitter automatically strip the comments, indentation and newlines. (Cosmetic minification only)
• Only allow posting if the stripped code fits in 140.

So Dwitter would still only publish 140-char dweets, but it would present their code in a more readable form.

[ViStefan]

@joeytwiddle doing this, you have to implement smart minificator, which also removes spaces (but not spaces in "s t r i n g s" or in code like i=new Image()) and brackets if possible. But what is the reason to do this? People, who tends to minimize their code as possible, sometimes discover a lot of new ways to do something interesting and cool, and the way they hack their code to be little is also a part of masterpiece they create. Let haxx still be haxx, I think.

[lionleaf]

Thanks for the suggestion, @TomSputz. And glad you're having fun with the site.

While dwitter definitely can be used to learn javascript, the manual compression of the code is a big part of the challenge. Having an automatic minifier would defeat this part of the puzzle.

However, as @joeytwiddle points out there is definitely room for adding additional information and make it easier to understand the code. But allowing characters that are not counted in the actual code, like spaces and comments, is not going to work, as it would allow you to encode whatever you want in a comment and eval() it later, defeating the 140 character limit. So for something like that to work we would need a separate "annotation" system that lives outside the code itself. You can already post the longer version of the code in the comments, but only a few people do that. Maybe a "prettify" button that formats the code into a more readable version might be helpful. But I'm not sure that adds enough value to be a feature.

I also think syntax highlighting would help with readability. #395

[lionleaf]

I'm closing this. Feel free to reopen it if anyone feels it should continue. And if anyone has a concrete idea for how to increase readability and ways to help out new coders, you can open new issues :)

[joeytwiddle]

I think we can do it without any risk of exploit: We would simply run the minified/golfed code, not the annotated code. (There is no need to pass annotated code into the iframe.)

I think the core idea here is to provide better support for users to post an annotated version of the code. As lionleaf says, currently this is done in the comments or by linking to an external site. How could we support it better on our site? Make a dedicated textarea for that purpose, a dedicated field in the DB, and a nice way to present it?

To offer this feature, we don't really need an automated minifier at all. Converting between the annotated code and the golfed code could be done manually by the author. A minifier would only add convenience. At the end of the day, it is the golfed code that gets counted and run. The annotated code would only be for display.

What might assist this conversation is some imaginative sketches of how this feature might actually look on the site. A textarea takes a lot of space, so it would need to be done well! Authors on mobile need to be able to see the edit box and the iframe at the same time. For viewers, should there be a way to toggle between annotated and golfed code? A toggle button, or tabs? Syntax highlighting: hell yes! (If the author didn't provide annotated code, should another user be able to? Multiple users?!)

(Of course, the easiest implementation would be to force users to post annotated code on an external site. Because that is already supported. :wink:)

[Ayplow]

In retrospect, actually mininfying the code is clearly not in the spirit of dwitter - the improvements to the length of the code should be done by users. Optionally providing a more readable version of code for people who are interested is all I was really meaning, and I agree that displaying it nicely is going to be the main challenge.

However, simply providing an alternative text field to write in would raise a couple of issues -

1. Primarily, it would be very easy to accidentally write code that isn't actually equivalent, ending up misleading (and confusing) anyone reading it
2. It would end up being used to write whatever people wanted - ascii art, external links, complaints. Though this isn't bad in and of itself, it would make the flow of the site less clear.

Would it be practical to run both the 'real' and descriptive code for ~5 cycles, and make sure the output is the same?