JSMin+ 1.1

Crisp heeft op zijn weblog in de vorm van 1.1 een nieuwe versie van JSMin+ vrijgegeven. JSMin+ is een 'JavaScript minifier' die via PHP een JavaScript-bestand als het ware kan verkleinen. Dit verkleinen heet ook wel minification en haalt alle onnodige tekens zoals spaties en commentaar uit een JS-file zonder dat de werking van het bestand wordt veranderd. In het geval van JSMin+ wordt deze lap JavaScript-code omgezet naar deze minified code. Meer informatie over JSMin+ is hier te lezen. De nieuwe 1.1-release van het programma wordt met de volgende release notes geleverd:

Version 1.1 of JSMin+ is available for download. This version has improved performance and fixes some issues. If you use labels in your javascripts you are strongly adviced to use this version to re-minify your scripts.

Changelog:

Improved tokenizer performance by reading smaller chunks for matching

Bugfix: jumplabels for break/continue statements were not written to output

Improved stringmatching: cases like '\' and '<newline>' now throw unterminated string literal error

Fixed linenumber offset bug caused by JScript conditional compilation blocks

nest() always calls Statement() so no need to use call_user_func() with a parm

Lees meer

Reacties (17)

Eusebius 12 april 2009 13:49

33% kleiner bestand klinkt leuk, maar wat doet het nou met de tijd?

moto-moi @Eusebius • 12 april 2009 14:03

de files zijn sneller binnen bij je clients, en in theorie duurt het parsen vande files aan de clientkant ook minder lang, omdat er minder witruimte is om weg te gooien. Maar dat is volgens ons nogal nihil, maar alle beetjes helpen natuurlijk

Verwijderd @Eusebius • 12 april 2009 13:55

Ik denk niet zo veel, aangezien het na een g-zip weer ongeveer even groot is...
lijkt me dat de winst die je hiermee boekt marginaal is. Maar misschien als je echt heel veel bezoekers hebt dat je wat bandbreedte bespaart.

crisp Senior Developer @Verwijderd • 12 april 2009 14:42

Gzipped is de besparing nog ongeveer de helft, dus als je minified versie 20% kleiner is dan bespaart je dat nog ongeveer 10% na gzip compressie.

De winst is inderdaad marginaal, maar niet geheel verwaarloosbaar. Op een bestand zoals onze general.js die uncompressed ongeveer 50KB is en waarop ik ongeveer 23% winst boek met minificatie zie ik een winst in laadtijd (gzipped geserveert, +/-12KB) van ongeveer 0.01 tot 0.02 seconde bij een lege cache op een 12Mbit verbinding voor dat ene bestand (ten opzicht van de niet-minified versie - gezipped +/-14KB). Aangezien dit bestand gelinkt wordt in onze <head>-sectie is dat ook een blocking download voor het parsen van de content. Bij meerdere gelinkte scripts neemt de winst nog verder toe, en bij tragere verbindingen is de winst relatief groter en dus ook merkbaarder.

Bandbreedte is in deze voor ons niet echt een argument geweest, wel het feit dat de content clientside eerder beschikbaar is*. Dit is ook echt een optimalisatie die je eigenlijk pas moet doen als je het ook eenvoudig kan implementeren. Bij ons zit dit nu geautomatiseerd in het deployment proces dus het kost ons verder geen extra tijd bij wijzigingen aan een JS bestand

* nog beter is om je scripts aan het einde van je <body> te linken, maar dat is niet altijd mogelijk...

[Reactie gewijzigd door crisp op 24 juli 2024 00:53]

poefel @crisp • 14 april 2009 10:29

Hulde. Of het nu veel scheelt of niet, ik kan vooral de manier van denken erg waarderen. Als alle softwareboeren zo dachten zou ik nou geen dual core processor nodig hebben om windows te draaien, en zouden programma's als bijvoorbeeld acrobat reader geen 150 MB of meer vreten.

xilent_xage @Eusebius • 13 april 2009 21:38

Naar mijn ervaring helpt het alleen als je het geminifiede bestand kunt cachen, anders ben je de clientside bespaarde 1ms weer kwijt aan het minifien serverside.

Maar ach, alle kleine beetjes helpen, en het staat opzich wel netjes vind ik.

Little Penguin @xilent_xage • 13 april 2009 21:48

Het minimizen gebeurt niet on the fly hè. Aan het eind van het ontwikkelproces worden de files door de minimizer gehaald en deze bestanden worden als een statische file op de server gezet. (op tweakimg.net om precies te zijn).

Minifien gebeurt dus maar 1x en dat is wanneer de bestanden in productie uitgerold worden...

Wiethoofd 12 april 2009 13:19

Hier de uitleg van crisp zelf wat deze tool doet: http://crisp.tweakblogs.n...ript-minifier-jsmin+.html

En even de uitleg waarom de tool geschreven is:

quote: crisp
For some time we have been looking for ways to minify the javascript and CSS files for Tweakers.net but were unable to find the right tool for this. If finding the right tool takes too much time there is only one other option: create your own tool, which is exactly what we did. Even better: we are releasing this tool to the public so you can use it too!

Verwijderd 13 april 2009 07:54

Misschien is renaming ook wel handig, aangezien je dan functies en variabelen met lange namen korter maakt, en dat parst ook weer sneller

crisp Senior Developer @Verwijderd • 13 april 2009 09:11

Nee, het hernoemen van variabelen en functienamen neemt risico's met zich mee en stelt zware eisen aan hoe je javascript ontwikkelt; je moet dan altijd expliciete referenties gebruiken en al je referenties moeten besloten zijn in hetzelfde bestand (tenzij je je beperkt tot variabelen binnen functiescope).

Dergelijke rigide eisen zijn counter-productive (net als de syntax-eisen die bijvoorbeeld de originele JSMin stelt) en wegen imo niet op tegen de extra winst.

_Thanatos_ @crisp • 13 april 2009 12:51

Welnee, de packer van Dean Edwards kan het toch ook (als je base62 encoding uitzet)... alleen private variabelen wordt verkort. Dus globals en object properties niet.

[Reactie gewijzigd door _Thanatos_ op 24 juli 2024 00:53]

crisp Senior Developer @_Thanatos_ • 13 april 2009 14:48

Dat zeg ik ook:

tenzij je je beperkt tot variabelen binnen functiescope

hoewel je dan alsnog geen truuken met eval'ed code moet doen en je dan ook nog risico loopt bij gegoochel met scope (with/call/apply)

Zie onder andere dit voorbeeld

Ik zie wel mogelijkheden though, dus wellicht dat ik het ooit nog inbouw

[Reactie gewijzigd door crisp op 24 juli 2024 00:53]

_Thanatos_ @crisp • 14 april 2009 02:02

with hoef je alvast niet te ondersteunen, want dat is een onofficiele uitbereiding die sommige parsers "toevallig" ondersteunen. Het is een statement dat - áls het werkt - sowieso voor ambiguïteit kan zorgen en dat is op z'n minst bad practise te noemen. Net zoiets als het const-statement, dat werkt ook niet overal.

Wat de problemen met call/apply zouden zijn, begrijp ik niet helemaal. een variabele is local of global. Er bestaat geen scope die "meer local" is dan local. Je kunt wel een functie in een functie maken, maar de variabelen daarin zijn niet meer of minder local dan andere, zegmaar

[Reactie gewijzigd door _Thanatos_ op 24 juli 2024 00:53]

crisp Senior Developer @_Thanatos_ • 14 april 2009 08:51

with hoef je alvast niet te ondersteunen, want dat is een onofficiele uitbereiding die sommige parsers "toevallig" ondersteunen.

Onzin, with is gedefinieerd in Ecma 262 (hd 12, p 10). Bad practice of niet, we moeten er mee leven. Daarbij zijn er meer 'extensies' die je toch niet zomaar kan negeren, JScript's conditional compilation is daar een voorbeeld van (hoewel die implementatie in JSMin+ nog niet volledig is).

Wat de problemen met call/apply zouden zijn, begrijp ik niet helemaal.

Met call/apply zijn inderdaad geen problemen, die heb ik te snel op de hoop met with en eval gegooid. Dat scheelt dus weer

_Thanatos_ @crisp • 17 april 2009 16:05

Ecmascript != Javascript.
javascript implementeert meer dingen niet, die ecmascript wel definieert...

crisp Senior Developer @_Thanatos_ • 18 april 2009 22:56

Je weet dat ECMAScript de gestandaardiseerde versie is van JavaScript, gesubmit door Netscape indertijd? JavaScript is op dit moment meer een superset van ECMAScript, ik heb echter geen idee of en waar JavaScript verder afwijkt van ECMAScript; als je voorbeelden hebt dan zie ik die graag

Maar with is zeker geen onofficiele uitbreiding en afaik ondersteunen alle browser-implementaties van ECMAScript dialecten het. Dit in tegenstelling tot bijvoorbeeld const wat inderdaad een JavaScript extensie is die niet gedefinieerd is in ECMAScript en ook niet ondersteund wordt door bijvoorbeeld JScript.

jeroenathome 12 april 2009 13:57

Afhankelijk van de grote van het bestand kan het voornamelijk op trage verbindingen meerdere seconden schelen per pagina die geladen wordt.

Op dit item kan niet meer gereageerd worden.

Versienummer	1.1
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	Crisp's blog
Download	http://files.tweakers.net/jsminplus/jsminplus.zip
Bestandsgrootte	12,00kB
Licentietype	GPL

05-'09	JSMin+ 1.3	23
04-'09	JSMin+ 1.2	7
04-'09	JSMin+ 1.1	17

Software-update: JSMin+ 1.1

Update-historie

Lees meer

Reacties (17)

Sorteer op:

Weergave: