3 ms·
If you don't have an established build process, I would consider a one-time minification of an established codebase to be a pretty poor decision. Either setup
by reificator 9y ago
If you don't have an established build process, I would consider a one-time minification of an established codebase to be a pretty poor decision.
Either setup a trivial build script, or don't do it at all.
EDIT: Clearly HN disagrees with me. Tell me, what does being a cowboy get you here?
If it's a measurable performance boost, then as soon as you patch it again your site will seem slower. Unless you then manually minifiy again. And again. Until you setup a build script.
If it's not a measurable performance boost, (And I doubt that you know either way because if you're not setting up a trivial build script then I highly doubt you're putting in the time to profile) then what do you get? The next person to come along gets to have a harder time debugging because you don't have source maps?
- Mandatum 9y agoI agree. Minify once it's released and you can test it quickly once to make sure there's no reference screw-ups, but as part of your development process - don't touch that file. I'd say most web developers follow this process though, I'd be interested to see statistics on minified sources. I'd say at least half of the websites I right-click view-source don't minify.
- stevenicr 9y agoand stats on how many times these minify and unminify sites have been used would be interesting. I've used them more than a dozen times. Some sites get the minification just to ramp up a google pagespeed number - not really for the end users - so why bother with a build process? Write some html, ftp. Then pagespeed numbers matter to some people and in some competitive industries - view source, web minify, ftp. done.
- reificator 9y agoBut again, if it's so important, then why leave it a manual process? If it's critical to the business needs, script it. If you need to do it every time you fix a bug, make it automatic.