Mailing List Archive

Farewell JSMin, Hello JavaScriptDistiller!
For those of you who didn't see bug 26791, our use of JSMin has been
found to conflict with our GPL license. After assessing other options (
https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I
decided to try and use the minification from JavaScriptPacker, but not
its overly clever but generally useless packing techniques. The result
is a minifier that outperforms our current minifier in both how quickly
it can minify data and how small the minified output is.
JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript
code at about 2x the speed of Tim's optimized version of JSMin, and 4x
the speed of the next fastest PHP port of JSMin (which is generally
considered the standard distribution).

Similar to Tim's modified version of JSMin, we chose to retain vertical
whitespace by default. However we chose not to retain multiple
consecutive empty new lines, which are primarily seen where a large
comment block has been removed. We feel there is merit to the argument
that appx. 1% bloat is a reasonable price to pay for making it easier to
read production code, since leaving each statement on a line by itself
improves readability and users will be more likely to be able to report
problems that are actionable. We do not however find the preservation of
line numbers of any value, since in production mode most requests are
for many modules which are concatenated, making line numbers for most of
the code useless anyways.

This is a breakdown based on "ext.vector.simpleSearch"

* 3217 bytes (1300 compressed)
* 2178 bytes (944) after running it through the version of JSMin that
was in our repository. Tim modified JSMin to be faster and preserve line
numbers by leaving behind all vertical whitespace.
* 2160 bytes (938 compressed) after running it through
JavaScriptDistiller, which applies aggressive horizontal minification
plus collapsing multiple consecutive new lines into a single new line.
* 2077 bytes (923 compressed) after running it through
JavaScriptDistiller with the vertical space option set to true, which
applies aggressive horizontal minification as well as some basic
vertical minification. This option is activated through
$wgResourceLoaderMinifyJSVerticalSpace, which is false by default.

The code was committed in r80656.

- Trevor (and Roan)


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On 20 January 2011 22:13, Trevor Parscal <tparscal@wikimedia.org> wrote:

> For those of you who didn't see bug 26791, our use of JSMin has been
> found to conflict with our GPL license.


On behalf of all aspiring Dark Lords, may I thank the Wikimedia
Foundation for protecting our freedom to use MediaWiki for evil. BABY
MULCHING WIKI IS GO!


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
Trevor Parscal (2011-01-20 23:13):
> For those of you who didn't see bug 26791, our use of JSMin has been
> found to conflict with our GPL license. After assessing other options (
> https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I
> decided to try and use the minification from JavaScriptPacker, but not
> its overly clever but generally useless packing techniques. The result
> is a minifier that outperforms our current minifier in both how quickly
> it can minify data and how small the minified output is.
> JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript
> code at about 2x the speed of Tim's optimized version of JSMin, and 4x
> the speed of the next fastest PHP port of JSMin (which is generally
> considered the standard distribution).
>
> Similar to Tim's modified version of JSMin, we chose to retain vertical
> whitespace by default. However we chose not to retain multiple
> consecutive empty new lines, which are primarily seen where a large
> comment block has been removed. We feel there is merit to the argument
> that appx. 1% bloat is a reasonable price to pay for making it easier to
> read production code, since leaving each statement on a line by itself
> improves readability and users will be more likely to be able to report
> problems that are actionable. We do not however find the preservation of
> line numbers of any value, since in production mode most requests are
> for many modules which are concatenated, making line numbers for most of
> the code useless anyways.
>
> This is a breakdown based on "ext.vector.simpleSearch"
>
> * 3217 bytes (1300 compressed)
> * 2178 bytes (944) after running it through the version of JSMin that
> was in our repository. Tim modified JSMin to be faster and preserve line
> numbers by leaving behind all vertical whitespace.
> * 2160 bytes (938 compressed) after running it through
> JavaScriptDistiller, which applies aggressive horizontal minification
> plus collapsing multiple consecutive new lines into a single new line.
> * 2077 bytes (923 compressed) after running it through
> JavaScriptDistiller with the vertical space option set to true, which
> applies aggressive horizontal minification as well as some basic
> vertical minification. This option is activated through
> $wgResourceLoaderMinifyJSVerticalSpace, which is false by default.

Yes, I know I'm stubborn, but 6 bytes (0.6%)? Seriously? Doesn't seem
convincing to me and seems like it could at least use
$wgResourceLoaderMinifyJSHorizontalSpace (even if true by default).

Regards,
Nux.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On Thu, Jan 20, 2011 at 2:33 PM, David Gerard <dgerard@gmail.com> wrote:
> On 20 January 2011 22:13, Trevor Parscal <tparscal@wikimedia.org> wrote:
>
>> For those of you who didn't see bug 26791, our use of JSMin has been
>> found to conflict with our GPL license.
>
>
> On behalf of all aspiring Dark Lords, may I thank the Wikimedia
> Foundation for protecting our freedom to use MediaWiki for evil. BABY
> MULCHING WIKI IS GO!

Amateur.

I'd describe my evil effort, but it's too sensitive to even be on the net.


--
-george william herbert
george.herbert@gmail.com

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On Thu, Jan 20, 2011 at 5:13 PM, Trevor Parscal <tparscal@wikimedia.org>wrote:

> For those of you who didn't see bug 26791, our use of JSMin has been
> found to conflict with our GPL license.


Thank you for removing JSMin! Thou shall use mediawiki for evil! ;)

-Katie (@aude)



> - Trevor (and Roan)
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
2011/1/21 Maciej Jaros <egil@wp.pl>:
> Yes, I know I'm stubborn, but 6 bytes (0.6%)? Seriously? Doesn't seem
> convincing to me and seems like it could at least use
> $wgResourceLoaderMinifyJSHorizontalSpace (even if true by default).
>
Trevor probably didn't choose a very good test case. He also tested it
on jQuery, though, and found that the unmodified version of JSPacker
was faster than JSMin and produced output that was 1% larger after
gzip. So in the general case, JSDistiller probably doesn't quite
minify JS optimally, but the difference with JSMin is small and the
difference in performance is ridiculous. That, and it doesn't present
legal problems.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
Roan Kattouw (2011-01-21 00:50):
> 2011/1/21 Maciej Jaros<egil@wp.pl>:
>> Yes, I know I'm stubborn, but 6 bytes (0.6%)? Seriously? Doesn't seem
>> convincing to me and seems like it could at least use
>> $wgResourceLoaderMinifyJSHorizontalSpace (even if true by default).
>>
> Trevor probably didn't choose a very good test case. He also tested it
> on jQuery, though, and found that the unmodified version of JSPacker
> was faster than JSMin and produced output that was 1% larger after
> gzip. So in the general case, JSDistiller probably doesn't quite
> minify JS optimally, but the difference with JSMin is small and the
> difference in performance is ridiculous. That, and it doesn't present
> legal problems.

You've misunderstood me. As long as it's well tested and performs nicely
then I'm all for (though I don't remember using MediaWiki for Evil ;-)).
Great job, really. I was only hoping to have an option to fully preserve
vertical space, but I've made a rotation in the name :-). So the option
could be $wgResourceLoaderMinifyJSVerticalSpacePreserved or maybe
$wgResourceLoaderMinifyJSPreserveEmptyLines.

Regards,
Nux.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On 21/01/11 09:13, Trevor Parscal wrote:
> For those of you who didn't see bug 26791, our use of JSMin has been
> found to conflict with our GPL license.

You're talking about the "good not evil" joke clause?

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
Joke or not, it's in there, and it's a violation of the GPL.

- Trevor

On 1/20/11 5:44 PM, Tim Starling wrote:
> On 21/01/11 09:13, Trevor Parscal wrote:
>> For those of you who didn't see bug 26791, our use of JSMin has been
>> found to conflict with our GPL license.
> You're talking about the "good not evil" joke clause?
>
> -- Tim Starling
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
2011/1/21 Trevor Parscal <tparscal@wikimedia.org>:
> Joke or not, it's in there, and it's a violation of the GPL.
>
Plus the alternative is better anyway.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
As mentioned in the bug, it would be nice to have configurable support
for the closure-compiler as well ;) ( I assume Apache licence is
compatible? )

Has anyone done any tests to see if there are any compatibility issues
with SIMPLE_OPTIMIZATIONS with a google closure minification hook?

--michael

On 01/20/2011 04:13 PM, Trevor Parscal wrote:
> For those of you who didn't see bug 26791, our use of JSMin has been
> found to conflict with our GPL license. After assessing other options (
> https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I
> decided to try and use the minification from JavaScriptPacker, but not
> its overly clever but generally useless packing techniques. The result
> is a minifier that outperforms our current minifier in both how quickly
> it can minify data and how small the minified output is.
> JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript
> code at about 2x the speed of Tim's optimized version of JSMin, and 4x
> the speed of the next fastest PHP port of JSMin (which is generally
> considered the standard distribution).
>
> Similar to Tim's modified version of JSMin, we chose to retain vertical
> whitespace by default. However we chose not to retain multiple
> consecutive empty new lines, which are primarily seen where a large
> comment block has been removed. We feel there is merit to the argument
> that appx. 1% bloat is a reasonable price to pay for making it easier to
> read production code, since leaving each statement on a line by itself
> improves readability and users will be more likely to be able to report
> problems that are actionable. We do not however find the preservation of
> line numbers of any value, since in production mode most requests are
> for many modules which are concatenated, making line numbers for most of
> the code useless anyways.
>
> This is a breakdown based on "ext.vector.simpleSearch"
>
> * 3217 bytes (1300 compressed)
> * 2178 bytes (944) after running it through the version of JSMin that
> was in our repository. Tim modified JSMin to be faster and preserve line
> numbers by leaving behind all vertical whitespace.
> * 2160 bytes (938 compressed) after running it through
> JavaScriptDistiller, which applies aggressive horizontal minification
> plus collapsing multiple consecutive new lines into a single new line.
> * 2077 bytes (923 compressed) after running it through
> JavaScriptDistiller with the vertical space option set to true, which
> applies aggressive horizontal minification as well as some basic
> vertical minification. This option is activated through
> $wgResourceLoaderMinifyJSVerticalSpace, which is false by default.
>
> The code was committed in r80656.
>
> - Trevor (and Roan)
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On 21/01/11 12:46, Trevor Parscal wrote:
> Joke or not, it's in there, and it's a violation of the GPL.

Did you try emailing the author and asking for a dual license?

On 21/01/11 12:58, Roan Kattouw wrote:
> Plus the alternative is better anyway.

Sure, but Trevor is claiming that he wrote it because of the license
issue. Since he has publically ranted three times:

<http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50082>
<http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50910>
<http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73196#c13027>

about how terrible my changes to JSMin.php were, in September,
December and January, I can't help but think that there was another
motive for this rewrite.

I have no problem with Trevor reverting that change, I said so the
second time this came up, so I think it's amusing that Trevor needed
the excuse of license incompatibility before he actually did
something. I'm glad that he's finally found the motivation from
somewhere, so that he can stop bothering me with his periodic rants.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
iirc there are some issues with the Apache license in GPLv2. GPLv3
however is fine with the Apache license.

As for dropping JSMin... I never really liked Crockford anyways, nor
JSMin... so I don't really have any problem. I also don't like the idea
of maintaining what's essentially a local fork from the upstream, so if
this is a performance improvement and eliminates the need to fork
something to get it to do what we want... perfect.

Personally I always had a preference towards YUI's minifier. I haven't
quite jumped onto closure just yet... in the early days I wasn't sure
about trusting it to not introduce edge cases into code (since it
basically does some rewriting of code above what other minifiers do and
I wasn't sure about it's implementation.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On 11-01-20 06:57 PM, Michael Dale wrote:
> As mentioned in the bug, it would be nice to have configurable support
> for the closure-compiler as well ;) ( I assume Apache licence is
> compatible? )
>
> Has anyone done any tests to see if there are any compatibility issues
> with SIMPLE_OPTIMIZATIONS with a google closure minification hook?
>
> --michael
>
> On 01/20/2011 04:13 PM, Trevor Parscal wrote:
>> For those of you who didn't see bug 26791, our use of JSMin has been
>> found to conflict with our GPL license. After assessing other options (
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I
>> decided to try and use the minification from JavaScriptPacker, but not
>> its overly clever but generally useless packing techniques. The result
>> is a minifier that outperforms our current minifier in both how quickly
>> it can minify data and how small the minified output is.
>> JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript
>> code at about 2x the speed of Tim's optimized version of JSMin, and 4x
>> the speed of the next fastest PHP port of JSMin (which is generally
>> considered the standard distribution).
>>
>> Similar to Tim's modified version of JSMin, we chose to retain vertical
>> whitespace by default. However we chose not to retain multiple
>> consecutive empty new lines, which are primarily seen where a large
>> comment block has been removed. We feel there is merit to the argument
>> that appx. 1% bloat is a reasonable price to pay for making it easier to
>> read production code, since leaving each statement on a line by itself
>> improves readability and users will be more likely to be able to report
>> problems that are actionable. We do not however find the preservation of
>> line numbers of any value, since in production mode most requests are
>> for many modules which are concatenated, making line numbers for most of
>> the code useless anyways.
>>
>> This is a breakdown based on "ext.vector.simpleSearch"
>>
>> * 3217 bytes (1300 compressed)
>> * 2178 bytes (944) after running it through the version of JSMin that
>> was in our repository. Tim modified JSMin to be faster and preserve line
>> numbers by leaving behind all vertical whitespace.
>> * 2160 bytes (938 compressed) after running it through
>> JavaScriptDistiller, which applies aggressive horizontal minification
>> plus collapsing multiple consecutive new lines into a single new line.
>> * 2077 bytes (923 compressed) after running it through
>> JavaScriptDistiller with the vertical space option set to true, which
>> applies aggressive horizontal minification as well as some basic
>> vertical minification. This option is activated through
>> $wgResourceLoaderMinifyJSVerticalSpace, which is false by default.
>>
>> The code was committed in r80656.
>>
>> - Trevor (and Roan)
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On Fri, Jan 21, 2011 at 5:30 AM, Tim Starling <tstarling@wikimedia.org> wrote:
> On 21/01/11 12:46, Trevor Parscal wrote:
>> Joke or not, it's in there, and it's a violation of the GPL.
>
> Did you try emailing the author and asking for a dual license?
>
I believe that people from Redhat have already tried that and failed.


Bryan

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On Thu, Jan 20, 2011 at 8:30 PM, Tim Starling <tstarling@wikimedia.org> wrote:
> Sure, but Trevor is claiming that he wrote it because of the license
> issue. Since he has publically ranted three times:
>
> <http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50082>
> <http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50910>
> <http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73196#c13027>
>
> about how terrible my changes to JSMin.php were, in September,
> December and January, I can't help but think that there was another
> motive for this rewrite.
>
> I have no problem with Trevor reverting that change, I said so the
> second time this came up, so I think it's amusing that Trevor needed
> the excuse of license incompatibility before he actually did
> something. I'm glad that he's finally found the motivation from
> somewhere, so that he can stop bothering me with his periodic rants.

This is really unnecessary and unhelpful on a public mailing list. I
think we'd all be better off if snark like this were kept to private
channels.

--
Andrew Garrett
http://werdn.us/

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On Fri, Jan 21, 2011 at 10:49 AM, Andrew Garrett <agarrett@wikimedia.org> wrote:
> This is really unnecessary and unhelpful on a public mailing list. I
> think we'd all be better off if snark like this were kept to private
> channels.

Agreed. Or better yet, not said at all. Since we evidently no longer
have a benevolent dictator whose word we all accept without question,
we need to work amicably to resolve disputes, and getting into fights
about <1% size savings vs. dubious increases in readability is really
not useful. At least get into fights about something *significant*.

(FWIW, I was and am against removing *all* newlines from JS output,
but I'm fine with collapsing consecutive newlines. This way errors
will actually point to a recognizable line.)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On Fri, Jan 21, 2011 at 7:21 AM, Aryeh Gregor
<Simetrical+wikilist@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 10:49 AM, Andrew Garrett <agarrett@wikimedia.org> wrote:
>> This is really unnecessary and unhelpful on a public mailing list. I
>> think we'd all be better off if snark like this were kept to private
>> channels.
>
> Agreed.  Or better yet, not said at all.  Since we evidently no longer
> have a benevolent dictator whose word we all accept without question,
> we need to work amicably to resolve disputes, and getting into fights
> about <1% size savings vs. dubious increases in readability is really
> not useful.  At least get into fights about something *significant*.
>

I agree. Talk about the code, not the committer.

But I really don't think we need a benevolent dictator. Brion never really
had to step in and play traffic cop; we've all gotten along and worked well
over the years without generally needing one and I see no reason why
that needs to change now.

And yes, I think we should keep the arguments confined to major things.
Ok everyone stop for a second.

We're arguing about a few lines of vertical whitespace. Full stop.

Lets argue about complex architecture changes or something else
worthwhile. It's really not worth it to waste so many bytes (and my e-mail
now just adds to the pile, I know) over something so incredibly trivial.

Back to the subject at hand...

While I happen to think the licensing issue is rather bogus and
doesn't really affect us, I'm glad to see it resolved. It outperforms
our current solution and keeps the same behavior. Plus as a bonus,
the vertical line smushing is configurable so if we want to argue
about \n a year from now, we can :)

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On 21/01/11 23:21, Aryeh Gregor wrote:
> On Fri, Jan 21, 2011 at 10:49 AM, Andrew Garrett <agarrett@wikimedia.org> wrote:
>> This is really unnecessary and unhelpful on a public mailing list. I
>> think we'd all be better off if snark like this were kept to private
>> channels.
>
> Agreed. Or better yet, not said at all. Since we evidently no longer
> have a benevolent dictator whose word we all accept without question,
> we need to work amicably to resolve disputes, and getting into fights
> about <1% size savings vs. dubious increases in readability is really
> not useful. At least get into fights about something *significant*.

Why does everyone think I care about the issue when I keep saying that
I don't? My email was an expression of frustration at the fact that
Trevor keeps attacking me about the change I made despite the fact
that I made it abundantly clear last time around that I don't care
about it and don't want to hear anything more about it.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On 01/21/2011 08:21 AM, Chad wrote:
> While I happen to think the licensing issue is rather bogus and
> doesn't really affect us, I'm glad to see it resolved. It outperforms
> our current solution and keeps the same behavior. Plus as a bonus,
> the vertical line smushing is configurable so if we want to argue
> about \n a year from now, we can :)

Ideally we will be using closures by then and since it rewrites
functions, variable names and sometimes collapses multi-line
functionality, new line preservation will be a mute point. Furthermore,
Google even has a nice add-on to firebug [1] for source code mapping.
Making the dead horse even more dead.

I feel like we are suck back in time, arguing about optimising code that
came out eons ago in net time ( more than 7 years ago ) There are more
modern solutions that take into consideration these concerns and do a
better job at it. ( ie not just a readable line but a pointer back to
the line of source code that is of concern )

[1] http://code.google.com/closure/compiler/docs/inspector.html

peace,
--michael

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
This sounds like "thinking out loud" (not to say whether it's true or false).
It seems like there "just has" to be some better, more private, means to
discuss things like this...

Tim Starling-2 wrote:
>
> On 21/01/11 12:46, Trevor Parscal wrote:
>> Joke or not, it's in there, and it's a violation of the GPL.
>
> Did you try emailing the author and asking for a dual license?
>
> On 21/01/11 12:58, Roan Kattouw wrote:
>> Plus the alternative is better anyway.
>
> Sure, but Trevor is claiming that he wrote it because of the license
> issue. Since he has publically ranted three times:
>
> <http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50082>
> <http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/50910>
> <http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73196#c13027>
>
> about how terrible my changes to JSMin.php were, in September,
> December and January, I can't help but think that there was another
> motive for this rewrite.
>
> I have no problem with Trevor reverting that change, I said so the
> second time this came up, so I think it's amusing that Trevor needed
> the excuse of license incompatibility before he actually did
> something. I'm glad that he's finally found the motivation from
> somewhere, so that he can stop bothering me with his periodic rants.
>
> -- Tim Starling
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>

--
View this message in context: http://old.nabble.com/Farewell-JSMin%2C-Hello-JavaScriptDistiller%21-tp30723860p30729894.html
Sent from the Wikipedia Developers mailing list archive at Nabble.com.


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On 22/01/11 02:49, Aaron Schulz wrote:
>
> This sounds like "thinking out loud" (not to say whether it's true or false).
> It seems like there "just has" to be some better, more private, means to
> discuss things like this...

Fair enough. Apologies to the list.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
Michael Dale (2011-01-21 16:04):
> On 01/21/2011 08:21 AM, Chad wrote:
>> While I happen to think the licensing issue is rather bogus and
>> doesn't really affect us, I'm glad to see it resolved. It outperforms
>> our current solution and keeps the same behavior. Plus as a bonus,
>> the vertical line smushing is configurable so if we want to argue
>> about \n a year from now, we can :)
> Ideally we will be using closures by then and since it rewrites
> functions, variable names and sometimes collapses multi-line
> functionality, new line preservation will be a mute point. Furthermore,
> Google even has a nice add-on to firebug [1] for source code mapping.
> Making the dead horse even more dead.
>
> I feel like we are suck back in time, arguing about optimising code that
> came out eons ago in net time ( more than 7 years ago ) There are more
> modern solutions that take into consideration these concerns and do a
> better job at it. ( ie not just a readable line but a pointer back to
> the line of source code that is of concern )
>
> [1] http://code.google.com/closure/compiler/docs/inspector.html

Great. Now I only need to tell the user to install Firefox, install
Firebug and some other addon, open the page in Firefox... Oh, wait. This
error does not occur in Firefox...

Please, I can live with folding new lines (thou I don't believe those
few bites are worth it) acutely compiling the code (or packing as some
say) would be just evil for Mediawiki or Wikimedia to be more exact.

Just remember that people all over the world are hacking into Mediawiki
all the time. Making it harder won't help a bit.

Regards,
Nux.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On Sat, Jan 22, 2011 at 5:40 PM, Maciej Jaros <egil@wp.pl> wrote:

> Great. Now I only need to tell the user to install Firefox, install
> Firebug and some other addon, open the page in Firefox... Oh, wait. This
> error does not occur in Firefox...
>
> Please, I can live with folding new lines (thou I don't believe those
> few bites are worth it) acutely compiling the code (or packing as some
> say) would be just evil for Mediawiki or Wikimedia to be more exact.
>
> Just remember that people all over the world are hacking into Mediawiki
> all the time. Making it harder won't help a bit.
>

Making it more powerful and more self-aware may, however, help a **lot**.

ResourceLoader provides a relatively sane module-loading system for managing
what bits of code and data are flying around. Consider supplementing this
better encapsulation with in-browser development tool helpers -- say, to
provide a code editor with syntax highlighting and flagging of errors, and
to let you load your custom site/user/gadget JS modules in context while
you're working on them.

Common tasks like adding custom tabs or grabbing some part of the existing
UI to modify can be made much easier by a script editor that knows these
things exist, and can help you identify which bits of the UI you want to
work with by clicking on them.


Even coming back down to earth, consider that current versions of every
major browser now have at least a basic Firebug-like debugging console and a
DOM inspector available. Debugging JavaScript on IE used to consist of
getting a dialog box with a file name and line number that were usually
*entirely wrong*... other browsers gave you better error messages but not
much more.

Debugging JavaScript in today's browsers can at least pop up the live code
in context for you, and by sticking '?debug=false' on your URL, all our
minification will be conveniently gone from view, and the individual modules
easier to identify by hand. (This too could probably be given a nice UI
helper in a script debugging tool or even in a global error handler... which
could also do things like report JS errors upstream to MediaWiki
developers.) Whether you have all the magic of a "real" debugger or not,
that's *hugely* useful in debugging, and has made a world of difference in
my experience.

-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
2011/1/23 Brion Vibber <brion@pobox.com>:
> Debugging JavaScript in today's browsers can at least pop up the live code
> in context for you, and by sticking '?debug=false' on your URL, all our
> minification will be conveniently gone from view, and the individual modules
> easier to identify by hand.
I recommend using ?debug=true for that ;)

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Farewell JSMin, Hello JavaScriptDistiller! [ In reply to ]
On 1/22/11 5:40 PM, Maciej Jaros wrote:

> Just remember that people all over the world are hacking into Mediawiki
> all the time. Making it harder won't help a bit.

I think minification is orthogonal to the hacking question.

I've said it before here but the key to enabling hackers is to have a
stable and documented API (both a remote web service, and an API for
things one might want to do in Javascript on the page).

We know that people are going to hack and that we like that, but if we
don't want to be trapped into supporting old APIs forever we should
document what's likely to change and what we will aim to keep stable.

--
Neil Kandalgaonkar (| <neilk@wikimedia.org>

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 2  View All