JSMin+ 1.3

Op zijn weblog heeft crisp een nieuwe versie van JSMin+ vrijgegeven. De tool is hierdoor bij versie 1.3 aangekomen en is hier vanaf de Tweakers.net-fileserver als zip-bestand te downloaden. JSMin+ is een 'JavaScript minifier' die via PHP een JavaScript-bestand als het ware kan verkleinen. Dit verkleinen, ook wel minification genoemd, 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 release notes van versie 1.3 zijn hieronder gepost:

Version 1.3 of JSMin+ is available for download. This version fixes some issues with empty bodies in if/else and loop-constructs, and it fixes precedence issues in nested ternaries (which actually is a Narcissus bug which has been reported here). Furthermore it has some minification improvements.

Changelog:

Fixed loop-constructs and if with empty body

Fixed hook:colon precedence issues (https://bugzilla.mozilla.org/show_bug.cgi?id=492445)

Combine concats of strings with same quotestyle

Combine var-statements

Known issues:

JScript conditional compilation support is (still) not complete yet

Performance can be improved

No support yet for variable-name minification

Note that we *do* take patches for any of a.m. issues!

Lees meer

Reacties (23)

.Johnny 18 mei 2009 21:47

Wat zijn de voordelen eigenlijk als je al server side compressie op apache aan hebt staan? Door de bank genomen decomprimeert een browser sneller dan 'ie kan downloaden, dus met iets als mod_gzip krijg je toch nog veel kleinere .js files? helemaal in combinatie met een degelijke expiration header (voor terugkerende bezoekers en om je server niet te vaak te belasten).
enige dat je dan niet hebt is de optimalisaties die jsmin+ maakt, maar dat lijkt me ook een kwestie van netjes je js programmeren.
of mis ik hier iets?

[Reactie gewijzigd door .Johnny op 23 juli 2024 20:24]

ACM Software Architect @.Johnny • 22 mei 2009 12:44

Een expires header is natuurlijk alleen interessant voor bezoekers die terugkeren, niet voor het eerste bezoek.

De totale winst bij ook gzip gebruiken is natuurlijk een stuk kleiner, het zijn in veel gevallen sowieso kleine winsten die stuk voor stuk niet zo heel interessant zijn. Zelfs de winsten van javascripts samenvoegen zijn in de meeste gevallen subseconde verschillen.

Als je voor je bandbreedte moet betalen is een reductie in filegrootte van je meest opgevraagde bestanden natuurlijk ook mooi meegenomen.

plofkip @.Johnny • 18 mei 2009 23:28

Hoe meer hoe beter zeg ik maar...
Dus: JSMin + GZIP + Exp. header + goed coden...
En wat je hierboven ook kan lezen, zorgt JSMin er dus ook voor dat de client het stukje js code sneller kan parsen.

plofkip 17 mei 2009 15:50

Ik denk nog steeds dat je beter van die packers kunt gebruiken...
Deze dus: http://dean.edwards.name/packer/

Origineel: 50,2 KB
Minified: 38,7 KB
Packed: 26,1 KB

[Reactie gewijzigd door plofkip op 23 juli 2024 20:24]

crisp Senior Developer @plofkip • 17 mei 2009 22:37

Een ander nadeel van packer, naast het feit dat het indien je gebruik maakt van HTTP compressie uiteindelijk weinig extra voordeel oplevert maar wel extra client-CPU tijd kost bij elke pageview, is dat het ook bepaalde eisen stelt aan de syntax van je script: een (optionele) puntkomma 'vergeten' en je script werkt niet meer.

Uiteindelijk, en iets dat we ook voorzien voor JSMin+ in de toekomst, levert minificatie van variabele-namen samen met HTTP compressie de kleinste bestanden op zonder dat daar een extra clientside kost tegenover staat. YUI Compressor kan dat al want die tool heeft met JSMin+ gemeen dat er een echte javascript parser gebruikt wordt voor het ontleden van het script

_Thanatos_ @crisp • 18 mei 2009 14:39

Haal je script gewoon eerst door JSLint heen. Zodra die geen errors meer geeft, kun je je script veilig packen. Dat heeft inderdaad vornamelijk betrekking op missende puntkomma's, maar dan moet je die maar niet vergeten. Ja ze zijn optioneel, maar het is onverstandig om ze weg te laten, omdat het de foutgevoeligheid van je script verhoogt. Zelfde geldt voor de optionele accolades voor statement-blocks van 1 statement.

crisp Senior Developer @_Thanatos_ • 18 mei 2009 15:58

Optionele tekens toevoegen aan je script zodat de minifier ze vervolgens weer kan weghalen

Overigens zie je in de praktijk dat mensen terminators op veel plekken toch weglaten; bijvoorbeeld na functiedeclaraties. Een tool die daar niet mee overweg kan is contra-produktief

_Thanatos_ @crisp • 18 mei 2009 21:23

Een tool die daar niet mee overweg kan kun je ook juist productief noemen, omdat het je forceert nette code te schrijven. Optioneel of niet, iets weglaten "omdat het niet hoeft" maakt het niet netjes en zoals ik al zei, foutgevoelig. Op de lange baan zorgt het dus juist voor kwalitatief betere code.

En ja, de minifier haalt dingen juist weer weg. So what? Het gaat erom dat je bron netjes is, en dat de minifier iets naar de browser stuurt wat nog volledig begrijpbaar is.

Ander kun je ook wel ophouden met indenten, toch?

crisp Senior Developer @_Thanatos_ • 18 mei 2009 23:47

Er is imo een verschil tussen nette code en nutteloze talismannen. Een goede minifier moet gewoon elke syntactisch correcte code kunnen processen, of het nou nette code is of niet.

Vergelijk het met een browser: het zou wat zijn als browsers valide HTML niet zouden wensen te parsen omdat je een optionele tag (bijvoorbeeld een <tbody> element - wie gebruikt dat consequent in tables?) bent vergeten. Hoeveel mensen zouden van zo'n browser gebruik willen maken op het web?

Een minifier moet, net als een browser, doen wat 'ie moet doen. Voor stricte validatie zijn andere tools en het een zou niet afhankelijk moeten zijn van het ander.

_Thanatos_ @crisp • 21 mei 2009 13:09

Maar JSMin+ is dan ook geen verplichte kost. Stricte validatie is dan gewoon een gevolg van de keuze om te minifien. En zo moeilijk is het echt niet om je script strict-correct te krijgen. Gewoon alles met een puntkomma afsluiten, geen implied globals maken (vars declareren dus) en geen with-statements gebruiken.

Als je daar geen zin in hebt, moet je dus ook niet gaan minifien. Dat is op dit moment dus gewoon het gevolg.

crisp Senior Developer @_Thanatos_ • 22 mei 2009 12:11

Rare conclusie, temeer daar JSMin+ bewijst dat stricte validatie niet noodzakelijk is om te kunnen minifyen

Zodra je doorschiet in het puriteinse ben je gewoon niet efficient bezig; in sommige gevallen is strict niet noodzakelijkerwijs gelijk aan beter. Als dat toch een vereiste is voor het gebruik van een bepaalde tool dan is die tool gewoonweg niet toereikend en is het slimmer om te kijken naar alternatieven dan je werkwijze op draconische wijze aan te passen.

plofkip @crisp • 17 mei 2009 23:25

Ik zal je JSMin (jij hebt hem gemaakt toch?) in de praktijk gaan gebruiken voor behoorlijke webapplicaties. Ik denk inderdaad dat het beter is dan packen.

Blaise @plofkip • 17 mei 2009 16:05

Nee, want dat kost bij elke request client-side CPU om steeds te unpacken. Staat ook in de aankondigingspost op de blog van Crisp:

Should not have a negative impact on clientside performance.
The major goal of minification is to improve clientside performance. A tool like Dean Edwards' Packer is very effective in drastically reducing javascript filesize, but it comes with the added cost of the client having to 'unpack' the javascript files on every pageview. The benefit of the smaller size doesn't really outweigh that cost.

In het voorbeeld wat gegeven wordt is 14,23kb 'geminimized' naar 11,46kb. Voor zover ik weet is dat met de snelheden van tegenwoordig verwaarloosbaar.
Alle beetjes helpen, en een besparing van 20% vind ik niet verwaarloosbaar. Zeker als het bestand groter is en de pagina moet wachten op het laden van het bestand voordat het verder kan. En natuurlijk verschilt het ook per Javascript-bestand en de hoeveelheid code commentaar en whitespace.

plofkip @Blaise • 17 mei 2009 16:12

Ok, dat heb ik niet gelezen. Ik wist wel dat het wat CPU client-side kost, dus dan moet je een keuze maken

- Nóg kleinere files, maar dus een beetje CPU client-side nodig
- Of iets grotere files, maar geen extra CPU client-side nodig...

418O2 @plofkip • 18 mei 2009 11:06

Op een mobiele telefoon is rekenkracht nog steeds niet echt super, dus dan heb je met uitpakken wel een vertraging... En dat is dus niet handig.

Wim Leers @plofkip • 17 mei 2009 16:26

Da's geen keuze. Als je voor de nóg kleinere files kiest, ben je simpelweg dóm nog niet goed ingelicht.

De gedownloade files worden gecachet door de browser. Met een primed cache gaat de pagina dus sneller inladen bij de iets grotere files, aangezien die niet élke keer opnieuw CPU-tijd kost.

Eenmaal een zeer minimale besparing versus zeer veel keer een relatief grote besparing (testen hebben uitgewezen dat het makkelijk meer dan 100 200 ms (bron: http://www.julienlecomte.net/blog/2007/08/13/) kan duren om packer zichzelf te laten decomprimeren), dan weet je wel wat je kiest.

De enige zinnige omstandigheid waar je packer kan gebruiken is indien je zeker kan zijn dat de .js in kwestie slechts 1 keer gebruikt moet worden in een grote tijdspanne. Bijvoorbeeld in een AJAX/AHAH applicatie die na de initiële page load enkel nieuwe data ophaalt d.m.v. XML/HTML/JSON/whatever.

[Reactie gewijzigd door Wim Leers op 23 juli 2024 20:24]

moto-moi @plofkip • 17 mei 2009 22:12

niet alleen hij hoor

Wat jij niet schijnt te snappen is dat deze minifier iets anders doet dan de code alleen maar kleiner maken; deze tool zorgt ervoor dat de parser van de browser minder moeite hoeft te doen om dezelfde code te parsen als de originele file. Dat de code daardoor ook kleiner wordt om over te sturen is een voordeel wat uiteraard is meegenomen, maar niet het hoofddoel, in tegenstelling tot de tool waar jij naartoe wijst. Uiteindelijk heeft Bashrat een goed punt, elke keer een file decomprimeren, parsen en valideren is veel kostbaarder aan de client kant. iets wat wij bij Tweakers.net graag voorkomen. Onze tool houdt daar wel rekening mee, de jouwe niet. As simple as that.

plofkip @moto-moi • 17 mei 2009 23:24

Ik weet niet hoe het komt dat je denkt dat ik niet begrijp dat een minifier iets anders is.
Na het lezen van de reactie van Bashrat begrijp ik nu ook dat een minifier vaak de beste keuze is, ik was het er gewoon totaal niet mee eens over hoe hij het verwoorde.
Dat ik dan de grond in word geboord met mijn reactie boeit me niet, ik wil in ieder geval laten merken dat zulke reacties niet gewenst zijn (ook al scoort die beter, maar goed).

Wim Leers @plofkip • 17 mei 2009 19:27

Ik vind dat niet. De cijfers geven het duidelijk aan.

Mijn verwoording kan echter persoonlijk opgevat worden, en daarvoor mijn excuses. Ik ben er zeker van dat als je een keer de cijfers hebt gezien, dat je dan alleen maar tot dezelfde conclusie kan komen

EDIT: ik besef dat ik de bron niet vermeld heb. Hier is er eentje: http://www.julienlecomte.net/blog/2007/08/13/.

[Reactie gewijzigd door Wim Leers op 23 juli 2024 20:24]

CasEbb 17 mei 2009 15:34

In het voorbeeld wat gegeven wordt is 14,23kb 'geminimized' naar 11,46kb. Voor zover ik weet is dat met de snelheden van tegenwoordig verwaarloosbaar.

Misschien dat de weggehaalde whitespaces een positief effect hebben op het parsen van de javascriptjes?

Vordreller @CasEbb • 17 mei 2009 19:38

Dat is inderdaad zo voor de individuele gebruiker.
Die haalt het js bestand 1 keer binnen en voor hem of haar is daarmee de kous af.

Maar als je een site hebt die dagelijks duizenden en duizenden bezoekers heeft, dan is het voor de beheerders van de site van alle belang dat wat zij moeten versturen naar de gebruikers, zo klein mogelijk is. Het is tenslotte ook hun bandbreedte die verbruikt wordt.

ACM Software Architect @CasEbb • 22 mei 2009 12:25

De meeste mensen denken bij besparingen aan de ruime bandbreedte die ze hebben en denken dan "3KB dat merk je bij 20Mbit niet". Maar 3KB zijn ook twee (of meer) complete netwerk-packets minder. Bovendien wordt bij de meeste browsers het renderen van content gepauzeerd totdat die file binnen en geparsed is.

Hoeveel het echt scheelt is natuurlijk afwachten, bij een zo'n bestandje zal het inderdaad niet zo heel goed merkbaar zijn, maar het is niet automatisch verwaarloosbaar omdat het op je maximale snelheid niet veel zou schelen.

Op dit item kan niet meer gereageerd worden.

Versienummer	1.3
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	crisp
Download	http://files.tweakers.net/jsminplus/jsminplus.zip
Bestandsgrootte	13,00kB
Licentietype	Freeware

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

Software-update: JSMin+ 1.3

Update-historie

Lees meer

Reacties (23)

Sorteer op:

Weergave: