I was recently tasked with re-architecting Emerge Interactive's website, a CMS site based off of Expression Engine, which involved the usual work flow of creating requirements, and moving pixel to code. Previous enhancements to our website included classic bandwidth saving strategies: minification of CSS, uglification of js, lazy loading, inlining the crucial CSS to speed up time-to-paint, and such. However, we never touched images until now which is one of the easiest places to shave off hundreds of kilobytes.
I've had an affinity for image optimization, going as far as to test out Google's guetzli. I decided to revisit something I've been meaning to test out: Alternative image formats.
For those who aren't as versed in image compression, our choices are familiar for bitmapped images: JPEG (lossy, no alpha), PNG (Can do alpha, optimized by pre-processing with lossy strategies) and GIF (LZW and a complete waste of bandwidth). However, there are other image formats that browsers support: JPEG 2000 (Safari 5+), JPEG-XR (IE9-11, Edge), and Webp (Chrome, Opera, Android Browser). If you're keeping score, you're probably noticing two things: That's a fractured landscape, and FireFox wasn't mentioned, both are true. FireFox so far hasn't backed a format, and instead chose to write its own JPEG encoder that offers a 5% data savings as opposed to adding support for WebP, BPG or either JPEG format.
There's plenty of other places that perform comparisosn but the long and short is that per kilobyte. JPEG2000, JPEG-XR and WebP deliver considerably better images than JPEG and (often) PNG and it doesn't take too much effort. I'd recommend reading the following, David Walsh's WebP images and Performance and playing with the incredibly nifty a format comparison tool
All three do not require any purchases.
What you need:
- A high quality source file (preferably lossless)
- JPEG-XR: Microsoft provides a free photoshop plugin that can be downloaded here or nab xnview
- WebP: WebPonzie provides the most painless and easy to use solution. XNView also has WebP support.
- JPEG2000: Photoshop, Preview both have native support. XNView also has JPEG2000 support. (I've had the best results using Apple's Preview for whatever reason)
Adding multi-format support doesn't require much, just a picture element. Below is an example of a simple picture. This can be mixed with srcset.
Really, that's all it takes. Notably on macOS previewing JPEG-XRs are a pain, whereas at least WebP can be previewed in Chrome. It takes Photoshop or opening a JPEG XR in Xnview and going to the actions tab, applying a filter so you can view the original JXR file. At the very least, you'll be providing better images at the same file sizes as a normal JPG.
Last week I had an interesting conversation with a co-worker. She had taken her laptop to Apple. Apple restored her computer but it wiped her iTunes library, and she was confused as she assumed she'd get her music back. She doesn't have Apple Music or Match, but he did get some of it back. She only has the free iCloud 5 GB library which was sufficient to restore most of her docs, and the rest were on cloud services like Google Drive (as our office uses Google Drive). Add in another layer, Apple allows all music purchases to be redownloaded but doesn't extend the service to users without buying match. While hardly an Apple apologist, my knee-jerk reaction was "Well, yeah, you have to pay for it." However, I kept thinking about it after the conversation. Expectations being what they are, media is no longer finite. It lives and always lives: Spotify, Apple Music, Google Play, Netflix, HBOGo, Hulu, Audible, Amazon Kindle, Apple Photos, Google Photos. While we do not expect physical books, CDs/Vinyls, DVDs, Blu-Rays, Photo albums to magically exist in vast media centers, the cloud hype has given a strangely disconnected permanently ephemeral (ephemerally permanent?) quality to digital media; that it should be forgotten until remembered. Google already gives away music/photo storage for free, and Amazon does as part of it's mostly buried Prime services so why doesn't Apple?
iTunes has been a mess for years, and there's been a cottage industry of music purists who've abandoned iTunes, with utilities like Waltr, PhoneView, iMazing, and the music players Swinsian, Tomahawk and Vox Music Player. Perhaps match should be the driver to keep people in the iTunes sphere.
While it's nothing new to point out the brokenness of iTunes, iTunes Match should be a killer feature provided for free with iTunes long as you're using an Apple ID as a free service or included as a bonus for anyone who pays for iCloud regardless of the storage tier. It's confusing and disjointed for the average user.
It's not every day I discover a task manager GUI utility that I haven't heard of. Apparently, today is such a day as I randomly came across SqueezerApp, a minimalist pre-processor.
Pictured: Main app window is sparse
In my previous reviews of GUI task managers for front-end development, I went so far as to write glossaries for them so novice readers could find the reviews more accessible. However, due to the narrow lens of this utility, I'm going to skip this. I highly suggest novices read my review of CodeKit 3 as it goes far far more in-depth than this review ventures into the world of task managers, preprocessors and code compiling. I do my damnest to make my reviews effable, convert esoteric front-end web developer speak into human speak rather than pointless pontification. I'll be using words/phrases like task manager, minification, and uglification, with the assumption that you are already familiar with them or you've skimmed through CodeKit 3 Review.
Capitalizing on the need, both CodeKit and Prepros have filled the niché of GUI task managers, (and quite well I might add). CodeKit 3 is powerful enough to be viable in a professional environment, and my review of CodeKit 2, I used CodeKit 2 off and on professionally for 9 months (mixed with Grunt). However, GUI task managers do not offer the flexibility of Grunt, Gulp or Webpack. GUI task managers are about ease of use as most users find GUIs far more intuitive than using a terminal and text configured files. The value that a GUI task manager is the simplicity and ease of use it brings.
Pictured: General settings only allow one single path to export compiled code/images to.
Squeezer's website is a bit low on info. There's no information as to what engines it's using to process files, versions of compressors and so forth. It's a mystery box and poking inside the app reveals little. The website is almost a non-entity, and it's developer, Yanis Zafirópulos lists himself as "Dr. Kameleon", adding to the mystery.(If there's ever a red flag, it's someone who calls themselves a doctor without a full Ph.D.). Also, Chameleon? I could infer plenty more. To be clear, I'm joking... I doubt that there's any ulterior motive to less transpicuous.
Part of the reason I'm learning just now about the application is that there are several "Squeeze" named OS X applications, like the high-end video compressor, Sorenson Squeeze (formerly Squeezer), PDF Squeezer, and a few other utilities making for a tough SEO battle. Finding the official website takes more google-fu than one would expect.
Squeezer supports the following:
- HTML: Minification
- CSS: LESS, Stylus, Scss/Sass and CSS compiling/minification
- Images: PNG, JPEG (compression), SVG (minification)
Unlike CodeKit or Prepros, Squeezer isn't made for monitoring your entire project. Typically, with CodeKit or Prepros, the setup project looks something like this:
- Drag project folder into application window and wait for a second for the application to scan your project
- Via the GUI's folder structure, click on the parent Sass/Less file, JS file and set the output locations. Configure JS concatenation.
- In the project settings, enable/disable features like Linting
- As long as CodeKit or Prepros is open, it will compile your code. The application will remember your settings and create settings a file in your project folder that can be distributed with your project so others can quickly jump in with minimal configuration.
- Errors are logged in a central error log. The error log highlights problems in your code
Squeezer is significantly different. Squeezer only wants to know about your parent files. Dragging the entire project into Squeezer will create unexpected results, creating a bunch of partials of compiled code. I made this mistake when testing it and ended up with a CSS file matching every Sass file in my project, plus the properly compiled code when it hit the parent most CSS file. To make matters more confusing, if you enable file watching, Squeezer will not automatically trigger files unless the parent Sass file is manipulated. Even on single page sites, I like to divide up my Sass into separate .scss files. The shortcomings are immediately apparent, as I'm used to Gulp / Grunt / Webpack / CodeKit / Prepros which watch all your Sass and/or CSS and/or JS and recompile your CSS / JS whenever any of said files are manipulated. This isn't simply a preferred methodology, is the most sensible as you never have to remember to trigger your CSS or JS builds. Everything happens automatically.
So this leaves Squeezer in a strange space. It's a minimalist utility, but it also is more work to use. If you're simply looking to process Sass files in a project just once with the aid of a GUI, I still find CodeKit and Prepros easier.
Pictured: There's a few mystery options such as "advanced optimizations" and "remove all special comments except the first one."
Squeezer doesn't offer a proxy server either to inject your CSS changes, or trigger reloads when your JS/HTML (or other assets like Python/PHP) changes. Quite simply Squeezer is the most minimal task manager.
Who is it for?
If you only need to compile one type of code, then perhaps this is the GUI utility you've dreamed off. Just drag in the parent file, and it'll recompile on saves or perform a single compile. The problem is, I don't know anyone who works like this.
Lastly, it's worth mentioning that Squeezer is the cheapest of the GUI utilities.
Pictured: JS options are thin
Several things jumped out at me while writing this review:
- The one day trial for a development utility feels mildly insulting. I wanted to test the software and found myself against the gun to test it. I'm unwilling to pay $15 for something that I'm unable to even test drive properly. In fact, I may have missed settings and may have some inaccurate information in this review.
- Squeezer is not as easy to setup as CodeKit or Prepros nor does it have an easy way to specify multiple paths for individual file types.
- Little documentation, no real support to speak of and a few "mystery" options that'd require me looking at the code to see what they do. I didn't have time to test all options. My review contains more information about Squeezer than its documentation.
- Even at almost half the price of its competition and functionality, it's not a viable utility outside of the most bare-bones projects.
- Image optimization actually managed to INCREASE file sizes of many PNGs and JPGs run through ImageOptim and proceeds to overwrite them with the larger files. If image optimization is increasing the file size, then it shouldn't bother to apply changes.
- Squeezer logs inaccurate minification stats for Sass as it compares the parent file vis the entire compiled CSS, rather than unminified compiled CSS vs the newly minified CSS.
- There's no error console, and files that shouldn't have compiled still compiled.
Pictured: Squeezer did a great job with vector images but ended with questionable results with PNGs
I hate to trash on an indie developer I but just cannot recommend Squeezer when CodeKit and Prepros exist, even at double the price. I do think there is room for an even more simple task manager than CodeKit or Prepros but I found Squeezer too simplistic to mimic a workflow even for a very straightforward static website. It may fit others workflow and it has a free trial but even that has its shortcomings of being laughably short, making it difficult to evaluate if there are workable patterns for Squeezer. Add in the lack of documentation or clarity on the compiler versions, no proxy serving/live-reload and stupid logic on image compression, and Squeezer is a bit of a dud. It functions as advertised but without much grace. Squeezer feels like a beta more than a refined application.
Pictured: The Misc options mostly should exist under other tabs like "Just compile".
Squeezer isn't a total bust, it performs the tasks it purports to do but without any finesse. It really wouldn't take much to make this utility a viable solution. It's a good start and perhaps it could be a useful task manager if just a few things changed. The biggest changes I'd ask for out the gate are:
- Allow multiple export paths, at the very least by file type. Compiled JS goes into JS folder, compiled CSS goes to CSS folder, images go to the images folder, etc.
- Extend the CSS/JS watch to include imported files or allow the entire directory to be moved into the project window.
- Clean up the options; it's baffling that there are "just compile" options in the Misc tab instead of under the file types they pertain to.
- Add in an error log. I didn't see an. The file size savings is misleading if Sass files or JS files contain imports. The app either should compare the compiled file against all the sources or not at all.
- Add at the very least live-reload support (CSS Injection would be nice)
Adding those five features would make this usable and inexpensive alternative.
Version Reviewed: 2.0
I don't post much in the way of code on my blog, most of my tech posts are bug fixes or esoteric configuration. I’ve been sitting on a nifty sass mixin for about two years. and I've recently ported it to codepen. It’s clever for color theming elements. What it requires is:
- A predefined list/set of colors
- The desire to use all of these colors on multiple CSS attributes (borders, backgrounds, color, etc) and UI elements
- A simple way via CSS to set the color dynamically
Sass doesn't have arrays. Thus you need to iterate through multiple lists, one to define the CSS name and one with the corresponding color value. This can be taken further so other elements on a page could use other themes, even if the parent theme is different.
In no way is this limited to colors only, this could be done with lists of any attributes and values.
This is a slightly belated follow up to "Thoughts on Front End Development in late 2016". The idea is to chronicle thoughts I've had between the last time I wrote about front-end development by quarter. I like to pretend this blog is about front-end development and not random hacks for emulators, pining for new Mac Pros and audio gadgetry.
- I finally used Docker on a project and its wonderful (I'll admit I did not do the tooling to set up the container). It'd be interesting to try and fold in the front end techs into a docker container.
- Chrome is kinda glitchy again when dealing with React. I've had better luck with code injection on Safari the past few weeks.
- • I set up Webpack for our two apps at my company. Webpack is mysterious (unlike piping in Gulp) but damn if it isn't necessary for React. I even saved the day for a coworker with custom fonts. It turned out to be configuring MIME types for font loading. It really shouldn't be this hard, but it is.
- I started on another side project like CSSFilterGenerator.com, and it'll be on React.
- I'm happy to work on another Django project. I wish I had more projects with Django.
- Drupal 8 should be headless and do away with its own goofball templating. Ship it with popular templating options.
- For the first time I'm (almost) full stacking a site (at my current job), with Expression Engine.
- The next step for React and me is getting into Redux.
- Windows 10 S makes me sad. It means Edge will gain market share. It's also pretty much an anti-pattern, desktops are open, and Windows best strength has been: its huge library of software. Limiting it to the Windows Store is pretty much terrible, sure its $50 to "unlock" it but if I were Apple, I'd be laughing myself to sleep.
- I wish Node apps idled better.
- Changing OS X to target tabs instead of new windows really has been a surprisingly big change in my day-to-day.
- Net Neutrality is on the ropes again... If there's ever an example of nepotism and a conflict of interest, its appointing Ajit Pai to run the FCC. We're living in a kleptocratic kakistocracy
I wrote this some time ago as part of a review of a Focusrite Scarlett 6i6 audio capture box, but decided to break it out into its own separate page. This calculator uses the signal-to-quantization-noise ratio formula, Nyquist frequency, and bitrate formulas to calculate various properties of uncompressed PCM digital audio quickly.
Enter bit depthBit
Enter Sample RateKHz
Enter Audio Channelschannels
Maximum Dynamic Range
Pressure Level Values
Frequency Range (folding frequency)
*DVD-A has multiple format options, and uses MLP (lossless compression) so the bitrates represent the decoded data-stream.
Google posted Guetzli last month. Curious about testing it out, I decided to give it a go. Image optimization is one of the bazillion things a front-end developer needs to know something about. For the sake of sanity, I'm going to assume that readers understand that PNGs are (mostly) lossless and JPGs are lossy. However, most programs that encode to file formats often include additional metadata, or do not make the most efficient usage of the codec thus not all encoders are created equally. Perceptual encoding is tricky and thus assumptions are made within the constraints of the codec as how to interpret the input data. Based on this, there's frequently wiggle room to improve encoders to make them "smarter" and deliver better results.
Optimization doesn't end at the encoder. In the interest of delivering the smallest file possible, people have written many series of optimizations designed for existing formats, specifically for this article: JPEGs and PNGs. The easiest (and incidentally one of the most effective) is ImageOptim. Without going too deep, ImageOptim combines several popular image optimizations specific to both JPEGs and PNGs and makes it into brain dead easy optimization. It shaves off valuable kilobytes without affecting the image quality. Usually, I export assets from Photoshop or Sketch then treat them with ImageOptim and ImageAlpha (for PNGs). Often front end developers will use Grunt and Gulp tasks that use many of the same libraries that ImageOptim uses to auto-optimize images in a project. Google's Guetzli is a new JPEG encoder which offers new opportunities over my usual post-export optimization tweaks. Guetzli promises better results as opposed to simply smaller files.
I downloaded guetzli using the HomeBrew version for OS X/macOS. For my test, I started with high fidelity non-lossy phtoographs captured in RAW and converted to PNG source files.
Rather than inline my source images, here are the below links for reference and the relative time it took to encode on my MacBook Pro 2016 2.5 GHz Intel Core i7, 16 GB RAM, at 84 quality as defined by Guetzli.
- Guetzli Test Image 1 (19 MB) - roughly 16 minutes, Result 1.7 MB, Compare against Photoshop (6 out of 12 quality) at 1.1 MB
- Guetzli Test Image 2 (2 MB) - roughly 2 minutes, Result 223KB, Compare against Photoshop (6 out of 12 quality) at 236K
Apples and Oranges
The big problem is that Photoshop uses a 0-12 quality setting which has never been very sensible. Unlike video codecs that allow you target file sizes via bit rates, there's no real way to produce file sizes at the same size a Guetzli's JPEG engine. Instead it was a guess work, trying to figure out what Photoshop quality produced nearish the same file sizes. After testing several images, Photoshop's 6 out of 12 was the most "like" setting and its highly imperfect. For my very large image, the Photoshop 6 out of 12 quality JPEG was much smaller than the Guetzli's minimum 84 setting. However, when the images were much smaller, all other tests found Guetzli's 84 quality setting producing smaller files than Photoshop's 6 out of 12 quality setting. All images were also run through ImageOptim for further optimization.
Guetzli just isn't that effective on high resolution images and at least with my test source, the differences were not very profound. I debated running Guetzli on several 16 MP images but with 16 minutes per-convert, the practical application isn't there for most use cases. This left me going back to the drawing board. I downscaled my image to represent a more likely scenario.
Zoomed In Test
The following images are screen captures of the zoomed in results of the PNGs/JPGs for comparison. Linked next to each image is the original image (prior to zooming in). Right click to open up the zoomed images for full sized images. My two main test images are both images that have large gradients, where JPG artifacting often is the most visible.
Original PNG (size 1.2MB)
Photoshop JPG (size 95k)
Guetzli JPG (size 88k)
Surprisingly, Guetzli doesn't come out ahead. You can see the gradient blockiness in Guetzli's JPG. It's more apparent viewing this on a non-Retina display or at 2x on a retina display. The JPEG blur of the default Photoshop image works to its advantage on the gradients. I certainly didn't expect Photoshop's JPEG engine to win any test. That said, the Guetzli image is 7k smaller.
Original PNG (size 2MB)
Photoshop JPG (size 236k)
Guetzli JPG ( size 223k)
Guetzli comes out ahead quite a bit in the detail of the sky, something JPGs tend to foul up quite a bit. Guetzli certainly wins in this instance and looks better than the Photoshop image.
Guetzli is slooooooooooooooooooooow. Converting a 20 mb PNG (4,608 x 3,456) image under a normal load (a few applications open, Atom, Preview, Messages, Safari, Chrome, iTunes, Sketch, Codekit, textedit, 1password, Lightroom, Tower), cost roughly 16 minutes of CPU time on a 2015 MacBook Pro (2.5 GHz i7 / 16 GB Ram). First off Guetzli is a single thread application, occupying 99-100% of the 4 cores on my CPU. Sadly, it left 80% of my MacBook idling. Optimization for OS X is nearly non-existent.
Guetzli is designed for high quality JPGs, by default the quality slider is limited to 84. Anything else will throw up an error in the CLI. It is possible to bypass this by building the binary yourself. Guetzli also is designed to delver higher quality at the same file size than a JPEG encoded by lesser image encoder, as opposed to simply produce smaller JPGs.
Guetzli assumes the color profile for the JPEGs is SRGB with a Gamma profile of 2.2, this is the same as the default for Adobe RGB (1998) buuuut not as wide of a color space as it'll read as an untagged image color profile. Thus images you've been viewing in a different color profile may look less end up looking less saturated or vibrant or different
For static assets that rarely change, Guetzli is certainly an option but for my Front End flow, it's not going to be anything I lean on. There's certainly been some impressive image optimization utilities for JPEG over the past several years but my guess we're coming up against the limitations of JPEG. The sadistic side of me wonders if it could be used for Motion JPEG, which is eschews interframes/keyframes and thus is still a great video codec for high motion scenes.
The Mac Pro is a frequent topic in my blog as I've been a bit of an enthusiast. To this date the most read article is Recommended Mac Pro Upgrades. Needless to say, when Apple redesigned the Mac Pro 2013 as a glorified iMac, my reaction to it wasn't kind. I needed some good news today and I got it, Gruber at DaringFirelball.com came away with the biggest scoop today, and I quote:
We’re not going to get into exactly what stage we’re in, just that we told the team to take the time to do something really great. To do something that can be supported for a long time with customers with updates and upgrades throughout the years. We’ll take the time it takes to do that. The current Mac Pro, as we’ve said a few times, was constrained thermally and it restricted our ability to upgrade it. And for that, we’re sorry to disappoint customers who wanted that, and we’ve asked the team to go and re-architect and design something great for the future that those Mac Pro customers who want more expandability, more upgradability in the future. It’ll meet more of those needs.
While the word "PCIe" isn't present, expandability and upgradability show up in the above quote, inferring hopefully a return to towers. My 2008 Mac Pro is still going strong and remains easily the best computer I've ever bought, and quite possibly the most over-engineered beautiful computer to date, down to the RAM upgrade trays, to the dual CPU, dual bus design that has made it a viable computer for almost a decade. It's a problem that Apple left us all wondering about it's fate.
If they're releasing a new Mac Pro, with a few PCIe slots and drive bays, I'll be the first in line to upgrade.
You can read the whole thing here
I created a photoshop action after being annoyed with favicons and all the variants. It's on GitHub for download. There's quite a bit to it but it creates 13 icons in total. The support list is loooong! I tried to cover everything and this includes (but not limited to): IE11, Edge, Chrome 4+, FireFox 2+, Opera 10.1+, Safari 3.1+, iOS Safari 6+, Google TV, Android Browser 2.1+, Chrome for Android, FireFox for Android, UC Browser for Android, Samsung Internet, QQ Browser, Chrome Store, Windows 8+ pinned sites.
Size Name Purpose 32x32 favicon-32.png Standard for most desktop browsers 57x57 favicon-57.png Standard iOS home screen
(iPod Touch, iPhone first generation to 3G)
76x76 favicon-76.png iPad home screen icon 96x96 favicon-96.png GoogleTV icon 120x120 favicon-120.png iPhone retina touch icon
(Change for iOS 7: up from 114x114)
128x128 favicon-128.png Chrome Web Store icon 128x128 smalltile.png Small Windows 8 Star Screen Icon 144x144 favicon-144.png IE10 Metro tile for pinned site 152x152 favicon-152.png iPad touch icon
(Change for iOS 7: up from 144x144)
167x167 favicon-167.png iPad Retina touch icon
(change for iOS 10: up from 152x152,
not in action. iOS 10 will use 152x152)
180x180 favicon-180.png iPhone 6 plus 195x195 favicon-195.png Opera Speed Dial icon
(Not working in Opera 15 and later)
196x196 favicon-196.png Chrome for Android home screen icon 228x228 favicon-228.png Opera Coast icon 270x270 mediumtile.png Medium Windows 8 Start Screen Icon
(not in action)
558x270 widetile.png Wide Windows 8 Start Screen Icon
(not in action)
558x558 largetile.png Large Windows 8 Start Screen Icon
(not in action)
- Download the Photoshop Action and double click to decompress
- In Photoshop in the actions menu, click the hamburger menu and select load actions
- Locate the Favicon Creator
Using the action
The default image must be square and above 228 x 228 pixels (I personally recommend using higher than this). Click play and the action will create 13 icon sizes in PNG.
Unoptimized PNGs from Photoshop tend to be quite large. I highly recommend for macOS users the free application ImageOptim for lossless PNG compression. It's brainlessly easy. Drag and drop all the newly created PNGs to shave off valuable KBs off your images without any quality hit.
For the more obsessive, macOS users, ImageAlpha (works in tandem with ImageOptim) as it allows users to use indexed color profiles to even further reduce file sizes. PNGquant works natively from Photoshop and TinyPNG provides a free service usable from your web browser. See favicon cheat sheet for CLI utilities.
Favicons and you
As mentioned above this suite of Favicons includes support for (but not limited to): IE11, Edge, Chrome 4+, FireFox 2+, Opera 10.1+, Safari 3.1+, iOS Safari 6+, Google TV, Android Browser 2.1+, Chrome for Android, FireFox for Android, UC Browser for Android, Samsung Internet, QQ Browser, Chrome Store, Windows 8+ pinned sites.
So what does that leave off? IE8-IE10 and Windows Start Screen Icons. IE8-10 require .ico formats. Notably if you opt to include a favicon.ico, Safari will use the Favicon.ico (macOS/OSX) over the PNG version. This means you will need to create a retina caliber icon. See DaringFireball's guide.
Due to the unusual formats of the Windows 8-10 tiles, I'd recommend creating these separately.
HTML (place in your head)
<!-- generics -->
<link rel="icon" href="/path/to/favicon-32.png" sizes="32x32">
<link rel="icon" href="/path/to/favicon-57.png" sizes="57x57">
<link rel="icon" href="/path/to/favicon-76.png" sizes="76x76">
<link rel="icon" href="/path/to/favicon-96.png" sizes="96x96">
<link rel="icon" href="/path/to/favicon-128.png" sizes="128x128">
<link rel="icon" href="/path/to/favicon-228.png" sizes="228x228">
<!-- Android -->
<link rel="shortcut icon" sizes="196x196" href="/path/to/favicon-196.png">
<!-- iOS -->
<link rel="apple-touch-icon" href="/path/to/favicon-120.png" sizes="120x120">
<link rel="apple-touch-icon" href="path/to/favicon-152.png" sizes="152x152">
<link rel="apple-touch-icon" href="path/to/favicon-180.png" sizes="180x180">
<!-- windows -->
<meta name="msapplication-TileColor" content="#FFFFFF">
<meta name="msapplication-TileImage" content="/path/to/favicon-144.png">
Is all of this really necessary/is there any penalty to including all these images?
How often do you really bookmark websites? It's an honest question. Favicons are most useful for desktop browsing as they give a nice indicator. The 32x32 is the only Favicon that truly matters, the rest are Favicons for bookmarking sites. If you only created a single 32x32 favicon, you'd support roughly 95% of desktop users and mobile users (albeit with caveats). The biggest losers are mobile Safari, Chrome for iOS, Opera Mini, Blackberry browser being the odd men out either requiring their own formats or not supporting the 32x32 at all. iOS Safari/Chrome only use use the favicon touch icon sizes for bookmarks within the dock. Chances are your users would never see the icon.
Today, Web browsers are very smart. The only requests made are for the favicon that matches your browser's parameters. Since it takes almost no effort with this action, you may as well include all the favicons for the edge case users.
Twitter Cards and FaceBook OpenGraph is the new Favicon
Users now expect Favicons and social media shares to be equally as compelling. Both OpenGraph and Twitter Cards take a little more effort to support: you need to fill out additional meta data but the image sizes can be found below. Either set can be used with regular meta data to make other services (Slack or iOS's Messages in iOS 10/macOS's Messages) social sharing with more beautiful site previews.
Next up is creating an OS X automator version of this, so you won't need Photoshop at all :D
I finally took time to fire up Final Cut Pro X. The experience was surreal; it's eerily a foreshadowing of the Apple to come: a paternalistic and patronizing tone to its professional users that seems to shout "We know best" rather than "You know best, and we want to provide you with the best." It's the Apple that removes headphone jacks and dreams TouchBars are a feature for professions. The writing was on the wall: The Xserve. The Mac Pro. Final Cut Pro. Soldered on RAM in the MacBook Retina, all in the span of a year. Let it be known, 2012 was the last year Apple cared about creative professionals.
2016 didn't kill the Apple that we once loved; it happened five years ago when Final Cut Pro 7 was replaced by Final Cut Pro X. If it weren't for OS X, I don't think any of us will still be buying Macs..
"Speaking of the Mac Pro, I was reminded today about a time when Apple was proud of the professional Macs they shipped. Until the middle of last year, they had a dedicated page for professional users and case studies." - Nick Heer, PIXELENVY
". In the Mac line, at least, 2017 Apple seems a lot like 1994 Apple: misguided products, propped up by gouging the loyalists. The difference is that today’s Apple isn’t dependent on computers, and indeed barely cares about them thanks to the timespace-warping enormity of the iPhone. It’s like being in an alternate timeline where the Newton was a smash success, so the Sculley/Spindler era went on indefinitely."
"I’m honestly not sure Apple is even a consumer electronics company anymore. I’m starting to think they’re more a fashion and luxury goods company instead. When they make the devices thinner just for aesthetics, at a genuine cost to their performance or utility, the old “form over function” slam rings a little more true than it used to. As does the idea of charging high prices because they can" - Chris Adamson. Time Code
"But here’s the problem: in retrospect, what they built was a device based around their own ego needs of proving their critics wrong, not a device that served the purposes of their power users. It’s not configurable, it’s not upgradeable, it’s not expandable: It’s pretty, and full of (for 2013) innovative hardware design, but is that really what Apple’s power users needed?
I don’t believe so. I think they were much better served by the “cheese grater” Macs of the previous generation, and I think Apple needs to rethink this, and for the high end, go back to more of a developer machine which gives users flexibility to expand it and customize it to their needs. Just like the old Mac IIci, one of the best computers Apple ever built. I propose just this in a piece I wrote about this.
The Mac Pro, and its possible successor are serving niches within the niche that is the Mac market overall, but it’s an important niche: it’s the power users, the influencers and the developers who build all of the Mac and IOS apps we all depend on. These are important people that support and evangelize the Mac AND IOS platforms and ecosystems, and Apple has done a poor job of supporting their needs for a good three years now." - Chuq Von Rospach, chuqui.com
"I use a Mac as my daily driver, and have rarely made a tech-related purchase I regretted. And I've never returned a Mac, until today.
The 2016 MacBook Pro is a mixed bag. Many features (most shared between the two models) are huge improvements in the Pro lineup—like the SSD speed, size and weight, keyboard feel, and Thunderbolt 3/USB-C. Other features (like the Touch Bar) are worse than useless—they make the user experience worse.
I hope Apple realizes the blunder with the Touch Bar (and with the confusing lineup of laptops they currently sell) and either fix it or remove it entirely. I'd be happy if Apple only preserved the Touch ID/power key combo." - Jeff Geerling, jeffgeerling.com
While Brooks and others are arguing that iPad will eventually replace the Mac, Gruber is arguing there will always be a need for macOS—specifically a desktop operating system. Despite what my aforementioned dalliance with iPad might suggest, I’m firmly in Gruber’s camp. - , Delusions of Grandeur
I find a bit of solidarity that other Mac faithful seem to be echoing my initial reaction to the Mac Pro. As much as I like the iPhone, there's a viable alternative to it. As a web developer and creative professional, OS X is the beginning and end of why I use Apple products. There is no real competitor even on the same field, mixing a clean UI, and the power of *nix Apple's "courage" is taking its toll. Computer updates do not need fancy press releases but rather a constant component refresh of the latest and greatest, and ability to accommodate the power users rather than Jonathan Ive's whims. As someone who codes, blogs, designs, creates music, and does visual effects compositing (all of these at some level of professional capacity) OS X is vastly superior. iOS always feels like an apology when I try to do real work. It's great for some people, but for those who value raw power and/or raw efficiency, it's OS X or die.
I doubt I'm the first to notice this, but when will Apple learn that a tiny high end/professional, virtually un-upgradable desktop is the computer no-one wants? The 20th Anniversary Mac, G4 Cube, and the Mac Pro 2013 all have been flops.
My brother, sister-in-law, and dad started a cidery, Bandon Rain and I've been slowly building up its web presence. The website, while far from done, is finally ready to be viewed by the public. There's a lot more to be done (lazy loading, better high-density screen handling, more info, better design, press kit and inevitably a backend for others to manage the copy) but it's finally taken the mighty first step. They'll be at First Taste Oregon and I'll probably be there as well.
Update: Bandon Rain is starting to make a splash (bad pun). It can be found on tap in many southern Oregon cities on the coast, as far north as Eugene and Portland.
The last OS X native GUI is forever locked in 2013 at version .149.1 but fear not, you can run the current version of MAME ( version .180 as of writing this). However, there is a current MAME port for Intel OS X by @sdlmame_osx.
Download and install SLD
Go to libsld.org download and download the DMG. Then install the SDL2.framework into (in your root) Library/Frameworks. SLDL2 is a library for cross-platform development designed to provide low-level access to hardware such as I/O and graphics cards (many Steam games are based on this library for OS X).
Download MAME/MESS for Mac OS X - 64-bit Intel
Go to sdlmame.lngn.net and download MAME and decompress it into a folder of your choosing
Create Roms folder
Create a roms folder and place your roms within the newly created folder.
You can stop here but you'll probably want to download the m64 launcher from github.com/bamf2048/bamf2048.github.io (Direct link) to zip and place it in the directory. This will launch the app without the terminal and default to the installed games.
It isn't pretty but it'll get you the latest MAME compatibility. Notably sites like emuparadise have the rom sets. You may want to consider setting up OpenEmu with Mame if you want native GUI. Enjoy!
OpenEmu also sports MAME Arcade emulation support but its a bit tucked away.
Step 1: Download OpenEmu Experimental
Go to openemu.org and click the swatch and download OpenEmu Experimental, and install it.
Step 2: Install the MAME core
Once installed launch OpenEmu, open preferences and select cores. Click the install button next to MAME.
Step 3: Install games
Games can be nabbed from the usual suspects like emuparadise, the legality of this is fairly grey. OpenEmu only supports zipped roms so if the rom comes in a .gz or .rar, be sure to decompress its contents and rezip it. Name it the exact name as before (but with the new extension of zip). OpenEmu's mame core is version 0.149.1 so its significantly behind the windows version (from 2013 to be exact). Some sites will list the earliest known support needed for the rom in question.
Notably, you'll want access to the dipswitches, hitting F2 repeatedly while the game is launching will take you to most ROM bios screens that enable modes like free play. Note, I had issues resuming games and had to force quit MAME resuming so you may want to hold off resuming games.
Optional: NeoGeo Emulation
Emulating NeoGeo games requires one extra step, you'll need to get the NeoGeo rom, the one I used is from emuparadise (just go there and search for Neo Geo Bios) or try a popular search engine. Drag the Neo Geo zip into OpenEmu. You'll see the NeoGeo rom in your game list but ignore it and double-click the games as you normally would.
Good luck with OpenEmu.
Other recommendations from this blog:
- Running up MAME Arcade emulation with MAME/MESS - How to setup the most current version of MAME on MacOS. OpenEMU's MAME core is 4+ years old, there's quite a bit of newer arcade games supported in more recent versions.
- Installing Provenance on iOS 11 with a Jailbreak - Provenance is an iOS multi-console emulator based off of OpenEMU, supporting conoles from the 8 bit and 16 bit eras.
Back in January of 2015, I posted the longest continuous blob of text I had written since college, a review titled 9 months with Codekit 2: A review, which was a meditation on task management in the world of front end development. The review was popular enough to be ripped off by a few hack writers on other blogs like yourwebsitefirst.com which managed to use a verbatim copy of my review's final points. As the saying goes: Imitation is the highest form of flattery. It seems fitting that this now is officially the most longspun single article I've written for my blog. I'd like this review to be as accessible to novice coders and beginners as possible but it will inevitably be more technical as the differences between CodeKit 2 and 3 requires such vernacular, vocabulary, terminology, and industry acronyms. Readers may want to revisit my previous review for context as I spend more time explaining the usefulness of a task manager and Sass.
Also, this review may sound like I'm focusing on the negative (isn't that the way of 2016?), this is because CodeKit 3 is a very mature, very stable product and you probably should buy it if you like CodeKit 2 or fancy a GUI for task managing. (How's that for a review? You can essentially skip the rest of this review if you want.)
As with my previous review, I'm starting with a mini-glossary of terms and how they relate to the review below.
Mini-Glossary of Terms
Command Line Interface(CLI) - A GUIless (graphical user interface) way to interact with a computer. Commands are entered and run via the terminal on a computer, for most users this is done via a BASH terminal on a Linux/Unix variant like macOS (Formerly OS X) or Ubuntu (Linux). For web development, many utilities/libraries (like Node.js and docker) require some basic terminal knowledge to use.
Preprocessor - a utility that processes and converts one type of data into another type of data that another program can use. Preprocessors are not compilers, but when they process code, is often referred to as "compiling." For the sanity of this article, I will refer to the action of "compiling" exclusively within the context of preprocessing. Compiling is often used as a blanket term for programming languages that require processing for the code to be a browser readable language. Sass, Less, and TypeScript are often referred to as preprocessor languages.
Linting - a utility that runs to check code for potential errors and/or enforce coding style guidelines. Linters exist for almost every programming language.
Task Manager / Task Runner - a program that once configured can automatically perform common/routine tasks. Task managers can “listen” for events and automatically run a series of instructions based on event parameters. For web development, this usually means when a file is saved, or project structure is altered, or a specific command is entered into the CLI. These events trigger a series of actions such initiating a preprocessor to compile code, followed by refreshing a page. Popular task managers include:
- CodeKit - A Mac-only utility with a graphical user interface
- Prepros - A cross-platform utility with a graphical user interface
- Gulp.js - a command line utility built on Node.JS + Node Package Manager (NPM) built on Node Streams (asynchronous data flows) via 'pipelines.'
- Grunt.js - A command line utility built on node.js + Node Package Manager (NPM). Predates Gulp.
Gulp, Grunt, and Webpack are open source command line utilities that allow you to execute custom code or functions in other utilities to compile / minify / uglify / concatenate, pre-compiler languages such as Sass and TypeScript automatically each time you hit save. This is hardly all they can do. Both can be configured to use popular plugins like BrowserSync, a server wrapper that acts as a middleman to live-inject CSS changes and reload when various files are changed like HTML/PHP/Python/JS/JSON files and synch mouse clicks/scrolls across multiple browsers. They can be configured to do auto vendor prefixing for CSS, remove unused CSS, optimize CSS to shorthand, image optimization, image resizing, svg minification, svg merging, create custom builds of libraries like Modernizr, perform Linting, use Unit Test libs, create basic style guides, generate CSS icons, move files/folders, rename files and folders, zip files/folders, search and replace strings, and even integrate with Google PageSpeed analytics, create screenshots and monitor file sizes. These events can be chained together in any combination that one sees fit. Developers are free to create their own utilities to run within task managers.
That's quite a list of things that can be automated, and sadly both Gulp and Grunt aren't the most forgiving utilities for those new to web development (Webpack even less so). They can be cumbersome or annoying to set up for developers who are in a turn-and-burn environment where project timelines do not account much time for tooling/setup. Most seasoned devs using Gulp/Grunt (self-included) have a template that they use to easily configure with several favorite tasks, and call it a day.
DOM (Document Object Model) - As a front end web developer: This is your life. Think of it as the rendered version of your HTML/CSS/JS. A good cliff notes introduction to the DOM is the CSStricks article, "What is the DOM?". Web browsers have the ability to expose the DOM structure via developer tools such as "Inspect Element."
Package Manager - a package manager, automates the process of installing, upgrading, configuring, and removing software, and the respective dependencies. This term often refers to package managers used by operating systems, but for the sake of this review, I will be only using this term for web0centric package managers. Node Package Manager and Bower are the most popular package managers for front end developers. When a project requires installing libraries to run,these often are referred to as "dependencies." However, Bower and Node are not dependency managers. node.js is much more than a package manager.
This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years.
Auto-prefixing - Browsers often add features before they're an official CSS spec. The supported-but-not-official specification features would require a vendor prefix like -webkit-font-smoothing or for Firefox, -moz-osx-font-smoothing. Keeping track of these is a pain. Depending on your support configuration, writing a simple gradient such as:
Will also generate all the browser prefixed code such as:
This will ensure your code will work on older browsers that require prefixes and prepare for the day when prefixes aren't needed. This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years. Also, prefixing may become a thing of the past one day, as webkit announced that it was doing away with prefixes.
Sass - Syntactically Awesome Style Sheets. If you are still writing vanilla CSS, you really should stop and start using Sass. It's more or less assumed today that developers are using Sass (or at least LESS).
This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years. If you'd like a quick explanation of why you should be using Sass, please visit my original CodeKit 2 review or visit an article such as Scotch.io - Getting started with Sass.
LESS - An alternative to Sass, and syntactically is very similar. LESS's primary user base tends to be asp.net developers.
Stylus - An alternative to Sass, the least popular of the major three CSS preprocessors. Unlike Sass and LESS, it makes use of whitespaces, making it the most unique of the three.
This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years.
Bless - A lesser-known bug in Internet Explorer which causes CSS to be completely ignored after the limit of selectors allowed in a single CSS file is reached. Bless provides a simple solution: parse the CSS file into multiple files. See blesscss.com for more details.
BrowserSync - an open source application that allows for synchronized browser testing, and the ability to manipulate the page in real-time via code injection. The most common use is pairing with Gulp or Grunt and used to trigger browser reloads on code changes or live CSS code injections after a task manager detects the CSS file has been altered. This allows the browser to seamlessly change the layouts in near real-time or trigger page refreshes on HTML/PHP/Python/JS/etc changes when properly configured. It even allows the user to pair page interactions to multiple devices. If a user clicks on a menu in one browser, the same menu will be opened in all other browsers that are using the BrowserSync web server. It's rather magical to click a link on an iPhone and see both the desktop browsers and the iPhone load the requested page. If that weren't enough, BrowserSync also features remote device inspect element by using the JS library Wienre. Wienre gets several mentions on this page because it can be a massive time saver for extreme edge case browsers that do not have the ability to inspect element. For more info, visit browsersync.io. There are few utilities that make my life easier on a daily basis than BrowserSync + Sass.
This has to be one of the biggest sanity checks for front end developers in the past 5 to 6 years.... (you get the idea)
About My Workflow
What is CodeKit?
Simply put: Everything that CodeKit does can be performed by Grunt or Gulp. What you're paying for is a refined GUI for extremely quick and nimble setup and a much lower learning curve. Even as a seasoned dev, I'll admit that I can get rolling with CodeKit within less time than with my grunt or gulp starter templates. CodeKit's primary value is that it lowers the barrier to coding, and cuts out some of the initial setup. Drag and drop your project in, then create a few paths for where compiled files go and which get concatenated, and you're back to your IDE. CodeKit isn't aiming to replace all complex tasks for edge cases that Gulp and Grunt can do but rather all the common ones. It's designed to be the daily warrior, akin to my favored task setup in my grunt and gulp template files.
For less seasoned devs, CodeKit is indispensable. While I'd argue eventually it's a good idea to familiarize yourself with a CLI task manager, the front end developer pool is a deep one to jump into head first. There's decades of tacit skills, like IE or Safari hacks (browser testing / device compatibility), learning how to vertically align things with CSS (this is still a problem even though CSS's W3C Recommendation dates back to December 1996), how to leverage ES6, learning the ins-and-outs of a syntactic sugar preprocessor, what new hot JS framework is bringing all the devs to HackerNews, and so on. The state of front end development is a precarious one, so anything that frees mental space for concentrating on core tasks is welcomed. This is where CodeKit truly shines.
First and foremost, CodeKit got a facelift... if you can call it that. It's gone hyper-minimalist to the point of abstraction or undesign. I found Codekit 2's "look" pleasing even if the interface was occasionally bumpy. I can't say I'm a fan of the new GUI. I also was not a fan of Yosemite's design or iOS 7's design. Both took several iterations to strike a balance between minimalism and design and I'm hoping perhaps CodeKit 3 will follow this trend of slash and burn and then replanting. Almost all text has been removed such as "Server," "Preview," "Assets". Even worse, a mouse hover doesn't bring up any tooltip explanation. Instead, you're left with "Click and hope for the best." When I first was writing this review, I initially missed CodeKit 3's package manager leading me to believe it had been removed. It took accidentally clicking on it to realize it was still there. It's not a great start for a utility that's value is explicitly that it is easier to use than a CLI. The redesign is not a total loss: there's a nice project overview that also includes a build project button so builds can be triggered manually.
That said, any caveats with CodeKit 3 are minor seeing as the primary function of a task manager is to operate silently in the background until something triggers it to take action (usually hitting save on a file). The real changes are under-the-hood. The full list is on CodeKit's website, but I'll highlight what I think are the most important new features. Don't worry if you're unsure what the differences are as I'll break it down later in the review.
- Build System: Trigger builds from UI. Project migration
- Image Optimization: SVG optimization, gif optimization. Better optimization engine for PNG/JPG.
- Server: Simple SSL Support
- Hooks: Matching support with RegEx, per file triggering, hook error logging
- Custom Language Support: Add Your own languages and combine with hooks
- Bower: Creates/updates bower.json, version support for components, rename/relocate bower folders
- CSS: Bless, auto-prefixing, Minification, Source mapping (for shits and giggles I suppose) for regular CSS files
- Other: Bitters framework support, Pug: Jade's successor with backward compatibility for Jade
My Wishlist from late 2014
For fun, let's compare CodeKit 3 to my late 2013 wishlist of features found in my CodeKit 2 review.
- Optional Remote Inspect Element (FireBug’s JS beta or otherwise would do nicely).
Remote server tuning (I get JS errors in IE10 and IE11) SVG minification
- Ability read Grunt or Gulp tasks and pair them to CodeKit’s functionality (A man can dream…)
Ability read Bower configurations and automatically install missing libraries
So of all the features other than my pie-in-sky dream of Grunt/Gulp pairing, all but one of my requests were addressed. Did Bryan Jones read them? Probably not, these were pretty reasonable and likely obvious feature requests. The best it can affirm is that I am a front end developer who has enough technical prowess to know there are thoughtful features that would make my life easier. I stress reasonable because I could wish for a "make website better button" but its insanely non-specific.
Overall I'm pretty happy that all but one target was hit. I'm still surprised that CodeKit doesn't have a remote element inspection mostly because it doesn't seem to use browsersync. BrowserSync has the ability to use Weinre, and track user interactions to pair across multiple browsers. As near as I can tell is it's a custom WebSockets configged server. Perhaps one day, CodeKit 3 may switch to BrowserSync.
CodeKit's primary function is compiling code. If you've used CodeKit 2, then configuring CodeKit 3 is pretty much the same process. CodeKit will read imports in JS/SCSS/LESS etc but the initial pathing is set up via the UI. CodeKit 2 never was perfect about making sense of project pathing, and CodeKit 3 makes no more attempts to improve it. It'd be helpful to see an overview of sorts to know what files are outputting to where at a glance. That said, it's no less esoteric than reading JSON config files. All linked files can be viewed from a master file but without any pathing info nor can listed files be right clicked to "show in finder" or "open in an editor.".
All the front end coding greatest hits are here: concatenation, minification, source map, auto-prefixing, and blessing.
Compiling is as fast as Gulp or Grunt, as the compilers in CodeKit are built around the same open source software. Without a technical way to benchmark, the best I can say is it feels as zippy as I'm accustomed to with Gulp. Compiling Sass can differ widely based on any number of factors like the apparent complexity of a project, how bogged down your computer is, and so on. What I can say with certainty is CodeKit idles well. Grunt taxes the CPU even when just watching files. Gulp seems to be much better at this and (to me personally) and marks the largest difference between gulp vs grunt (despite all the hype around Gulp's asynchronous abilities). CodeKit seems right in line with Gulp.
Builds are triggered by hitting "save" on a watched file or via hooks, and hooks can be set to trigger other actions. If you're adventurous, you could configure CodeKit on a save to copy files to an FTP.
CodeKit also comes preconfigured to refresh the page on HTML/PHP/Python/JS/Pug etc saves and to inject CSS without page reloads. If you're still in the old world of manually page refreshing, you'll wonder how you lived before code injection and auto-page refreshes.
CodeKit can also sort JSON content to be organized, and this can be triggered on file changes so you can always have alphabetized JSON files.
Lastly, like any good code compiler, the error log is the main event. More than likely, almost all your time in CodeKit will be spent in the error log. Its presented in a single pane, cleanly formatted. Successful builds are marked in green dots and bad in red. It's simple and effective and now has the ability to consolidate external compilers to the error log, which was to some ire of me before when I switched my Sass compiler to a newer version rather than waiting for a CodeKit 2 update.
If you've used CodeKit 2's server, it now has SSL provisioning and event syncing. I never knew or noticed the SSL issue since all my development is done locally but I imagine for some this is a crucial fix. Calling CodeKit's internal server, a "server" may be misleading. Akin to BrowserSync, it's a simple wrapper that can be mapped to any domain or directory and injects the necessary JS to trigger page refreshes and CSS injection.
CodeKit now features event syncing for any page clicks, forms and scrolls. This is incredibly useful for testing multiple browsers and devices simultaneously. This is a big addition.
As mentioned previously, Wienre allows for remote inspect element. This may not seem like a killer feature as Android and iOS offer remote device inspect element via using a desktop browser to run inspect element on physical device connected via USB or simulators. Occasionally as a Front End Developer, you may be asked to test on an esoteric browser like Amazon's Kindle's Silk which doesn't have Chrome or Safari device inspection. Wienre is the answer.
CodeKit's Servers works well for a wide variety of projects and even integrates with MAMP.
Saving an image from most image programs is not the most data efficient use of a file format. Often they bundle in meta data, and do not use obsession-tuning that makes the most use of compression, optimization techniques. For JPEGs and PNGs, there's a set of algorithms that optimize images and can shave significant amounts of data off them without affecting the image quality. Since these require zero input from the user other than what files to target, its a painless way to shave significant amounts of data off file sizes.
CodeKit's image optimization got a much needed revamp. Prior, image optimization worked but had some serious caveats. Edit: April 10, 2017. CodeKit now folds in ImageOptim's incredibly powerful image optimization algorithms. It's technically a lossy encoder but virtually unnoticeable (I haven't ever noticed it). While ImageOptim is free, this means one less thing you need to use. CodeKit now is the best of the best when it comes to auto-optimization (better than Grunt or Gulp). Notably, this isn't the same as treating a PNG image manually using ImageAlpha. Codekit 3 launched with a much-revamped image optimization, prior it did not have any SVG minification support. Prior to the addition of ImageOptim, In my tests of a 4.1 MB PNG, both ImageOptim and CodeKit 3 produced a 2.6 MB PNG file. CodeKit 2 produced a 3.1 MB image. Results will vary wildly based on the individual image. Also, Codekit 3 can be tuned to also watch files to recompress on a file change unlike CodeKit 2.
I'm quite fond of this and CodeKit provides the best quick UI for SVG optimization I know of. This is a tremendous win for CodeKit.
About the only thing CodeKit doesn't do is export inline SVGs or crunch all SVGs into a single SVG file, which are edge case optimizations. I guess for the truly ambitious this is obtainable, but this is pure speculation as I haven't had time to mess with hooks.
In future releases I'd like to see CodeKit go beyond simple optimization, specifically creating sets of resized images based on rules for responsive images. The would take some careful consideration to deliver a simple solution, but I'd love to easily create image sets from an original source image. Perhaps that's a sister utility waiting to happen for CodeKit? I'm not sure...
Codekit 2 made an admirable attempt to bring package management to CodeKit although I always found it a little confusing. CodeKit 3 is still no different, and the interface isn't entirely great. It's hyper-minimal and allows for a set of favorite components, and the ability to search for new ones. Unfortunately, the search bar is hidden and takes poking around to find.
CodeKit offers easy installs for a few well-used add-ons (Bourbon, Bourbon Neat, Bitters, Compass, Zurb Foundation, Susy, Nib, and Web Starter Kit) via the project preferences pane. CodeKit also offers Bower support and can read bower.json files to install dependencies. I'm unsure if CodeKit can use .bowerrc configs and I plan to test this when I have time.
CodeKit also offers the ability to create your own framework of commonly used files as before. I can't say I personally like CodeKit's package manager as I found it easier to simply search and find the frameworks or plugins I was looking for via google and installing them (via bower or node or manually) than the guess and check method of CodeKit. I do like the Bower config file support as even junior devs can understand the bower.json after a little bit of reading.
CodeKit doesn't offer package.json support for NPM (node package manager). Deal breaker? Not at all, but it is a nice-to-have feature to make CodeKit all-encompassing.
CodeKit 3's hooks allow you to tap into the underpinnings of your computer, as CodeKit 3 supports Bash scripts and Apple Scripts. Bash scripts allow you do infinitely powerful things, for example, I wired up CodeKit to ImageMagick to create JPEG 2000 and WebP images from PNGs. Rather than post an elongated how-to mid review, I've created a tutorial on how to do it. Admittedly this is scratching the surface.
Hooks this tiny script will create JPEG2000 and WebP images from PNG files when PNGs are modified.
CodeKit 3 easily could be set to watch your npm package.json file and when modified, run NPM install to keep packages up to date or upload image assets to a CDN when modified. The possibilities are as far-flung as CLI task managers with some minor caveats: Hooks cannot be interactive and require inputs.
This gives CodeKit much more versatility that what CodeKit ships with out of the box. As someone who uses Bash daily but not a prolific scripter, if you're a terminal junkie, your imagination probably is greater than mine.
The CLI task managers vs CodeKit 3
Gulp as exciting as it gets
Both Grunt and Gulp are immensely powerful. As I was working on transitioning a Cordova project to Gulp after using CodeKit 3, I was debating if I wanted to try out a plugin to auto-generate a style guide and to delete unused CSS. The last project, I created a customized Modernizr build based on scanning my CSS file for modernizr classes using a grunt task. runt and Gulp have amazing support, and it shows, but the setup is intensely unfriendly. It'd be easy for me to go "greybeard" and detest kids and their GUIs but they have their place.
How much is a clean and easy to use GUI worth? This is the most prescient existential question to CodeKit. It'd be easy to say not much or launch into a tirade about the superiority of Gulp but this for years was at the very crux of Apple's OS X as it was Unix but dressed up and cleaned for day-to-day use. This isn't the best analogym and we have better analogs to CodeKit 3.
CodeKit does for task management as what Tower does for Git; provide a GUI to CLI utilities. Even as a world weary-web developer, I still live by Tower. Tower can't do all things that Git does, but it does enough and makes it digestible enough where I rarely use Git via the command line. The only time I can really recall CLI Git in the past year was for git resets and nuking a branch. CodeKit can do the same albeit with a few more limitations. (Tower recreates the functionality Git whereas CodeKit recreates the functionality of a plethora of utilities)
CodeKit does something that I find valuable: it gets me to writing code more quickly. My personal portfolio always has been managed by CodeKit, and even when I start projects and need to rapidly code something up, I tend to lean on CodeKit. It reminds me of my early days as a digital musician. I learned to use Reason 1.0 in the year 2000. Reason was novel since it was immensely easy to spin up and start making music with minimal delay. Around 2004, I outgrew it and switched to Cubase and but I still pine for the simplicity of Reason in which project setup was a lot faster and took a lot less overhead. It wasn't as powerful, but it got my idea out much more quickly. It's also why I still use Apple Motion despite Adobe After Effects being superior. That's the niché of CodeKit to me today.
Depending on your job needs or workflow, CodeKit may be all you ever need, or you may quickly outgrow it (and anything in between). This is a question I cannot answer for you, but I can say that CodeKit can be useful even to an accomplished developer.
CodeKit 3 vs Prepros 6
Prepros (to my knowledge) is still the only competitor to CodeKit. Prepros offers a very similar feature set.
- Live Reload
- Minification, Uglification, Concatenation
- Browser Sync (Scroll / click / form sync)
- Image Optimization for PNG / JPEG
- Remote inspect element
- CSS Injection & Live Reload
- Minification, Uglification, Concatenation, Bless
- Browser Sync (Scroll / click / form sync)
- Image Optimization for PNG / JPEG / GIF / SVG + Keep original files
- Hooks to add support for other languages and execute terminal commands
- Package Manager via Bower & GUI
- Linting for JS/SCSS/Stylus/CoffeeScript
- Enforce Coding Styles
- Quick installs of popular frameworks
Absolutely the biggest difference between Prepros and CodeKit is, CodeKit is macOS / OS X only. Prepros also offers Wienre support which is nice, and a built-in FTP. For most people in production environments, the later isn't really useful, as you should be using staging servers managed by a utility like Jenkins, but that's another story.
I wrote a review on Prepros 5 that's still pretty relevant to Prepros 6 that's worth reading as I break down the superiority of CodeKit in detail. If you're a Windows user, you can effectively stop reading this review as CodeKit is OS X only or consider getting a Mac to run CodeKit. This isn't a slight against Windows as Microsoft has made some serious sweeping changes to allow Bash in Windows, which means no longer the dissonance of trying to use frameworks like node.js on Windows which required a special Node CLI. You'll be hard-pressed to find Windows front end developersm, but I assure you, they're out there and perhaps reading this review.
OS X users (excuse me, macOS) users have the agency of choice between Prepros vs CodeKit but Codekit is the clear winner. Codekit's ability to use external compilers saved the day on a few projects in the past for me. When I was working on a project that required a newer version of LibSass than CodeKit offered, I simply changed the engine to use the latest compiler instead of waiting for an update. Prepros does not have this ability. Also, Prepros doesn't have the nice framework library bundling, nor SVG optimization, ability to create hooks, create custom frameworks, and is a little more CPU heavy.
Looking forward: Where do we go from here?
I made some pretty bold feature requests back in 2014, and to my surprise, most were answered. So what would I like CodeKit to do in the future? This is tricky as some useful features like SVG-to-WebFonts have a limited shelf life, as webfonts are bad for accessibility.
- Single click install dependencies for new projects (including node)
- BrowserSync to replace the current server or something nearing its functionality
- HTML minification
- Responsive image processing (auto generate different image sizes based on parameters)
- Pie in the sky: Visual Regression Testing or jsDoc (auto documentation generation), TMI (too many images) reporting and/or PSI (Page speed analytics)
Are these the best features? Perhaps, perhaps not. I'm not as confident with my asks as I was in late 2014. This may be a case of the Aristotelian principle: "The more you know, the more you know you don't know" but I think the easy-fixes are mostly done.We're starting to get to more avant-garde features as Front End Development itself becomes more avant-garde.
I'll probably have some more insight as I start my venture into the world of React in 2017.
After jumping into React first Gulp then Webpack, I'm not sure where CodeKit 3 can exist in a framework centric flow. Webpack's killer feature is the ability inject code while maintaining states. For those who aren't using React, this means hitting save will keep all the components in the same state (forms, views, whatever) while the browser refreshes with the latest JS. While I haven't tried it, I assume CodeKit's babel support works with ES6 imports and JSX markup, thus could conceivably compile React and mimick a Gulp React workflow. Gulp and React aren't the smoothest, as every save requires a full recompile and thus zeros out any states on-screen that only stored in active memory. I quickly abandoned Gulp for Webpack and haven't looked back. I'll be honest and admit I didn't really understand Webpack and had a hell of a time getting it configged so if anyone brings sanity to webpack, I'd probably throw money at them. React/Angular probably are going to warrant specific tooling that CodeKit just cannot support for the foreseeable future. CodeKit may evolve as these frameworks mature, to support them better.
- CodeKit 3 is a logical step forward and almost all the things I wanted from CodeKit 2 are in 3.
- Backwards compatible
- Improved server now offers event syncing
- More languages and more JS centric features
- Much improved image optimization
- External processors and hooks
- ImageOptim's super awesome PNG compression!
- More build configuration
- Less resource intensive than Grunt when idling
- Seems a bit faster
- CodeKit 2 users get CodeKit 3 (sans new features) for free
- New GUI obfuscates features in nebulous icons and suffers for it
- If you're on a CLI task manager, not a hugely compelling reason to use CodeKit
- Must make current project active (Only watches one project at time)
- Even after weeks of use, still not a fan of the UI update
CodeKit is the beginning and end as far as GUI task managers go. It's quick. It's powerful. It lowers the learning curve for preprocessor languages like sass, typescript and even babel (a little). It's $35 for a first-time buyer and offers upgrade pricing. CodeKit 2 users can continue using CodeKit 3 but only with the CodeKit 2 feature set. It's a nice gesture for long-term support, and users can upgrade at any time. Currentl, the paid upgrade pattern for CodeKit is once every two years, so you can expect around 2 years of support for $35 and then upgrade pricing. CodeKit 2 had a lot of bug fixes and mild improvements over time. At launch CodeKit 2 didn't have Bless or auto-prefixing, which came in version 2.1.9 for compass projects or sourcemaps for stylus until 2.1.4. There are probably more features that are bound to hit CodeKit 3 that aren't on this list.
Edit: As if to prove my point, CodeKit 3 added ImageOptim to its codebase for PNG optimization. That's a helluva a feature addition. CodeKit 2 aged like a fine
wineimperial stout with the frequency of updates. CodeKit 3 looks to be the same.
If you outgrow CodeKit, chances are you'll still consider it money well spent.
3.0.1 to 3.1
Price: $35 first-time purchase.
Fun fact: After writing 11,000 words in three reviews between CodeKit 2, Prepros 5 and Codekit 4, I've written 42 pages single spaced or 84 pages now on GUI task managers for Front end development. This review isn't finalized, but I wanted to get this up ASAP, spelling errors, bad grammar and all.
12/21/16 update: Minor editing / grammar fixing, a lot more reference links, trimmed down intro.
12/23/16 update: Minor editing still, (a little list rambling, a little more content), better Prepros vs Codekit breakdown, error correction about event syncing
4/10/17 update: Added information about CodeKit's addition of ImageOptim and thoughts on frameworks + CodeKit.
5/12/17 update: Minor copy editing, added definitions for Style, Less and Linting
8/17/17 update: Finally added review notes to Hooks
10/10/17 update: Minor proof update
We hit a milestone. The Mac Pro 2013 was released December 19, 2013, marking 3 years without a single update.
The Mac Pro 2013 probably marks the most misguided product they've released. Even 4 years later, I can name several TV shows and even movies where editors re-use or rent 2012 Mac Pros in LA.
A successful Mac Pro would a simple rehash of the 2012 Mac program with an update:
- Bring back the old chassis or similar
- Modern CPU/Bus/GPU/RAM configurations
- User upgradable RAM
- 4 PCIe Slots
- USB 3 + 3.1c Ports
- ThunderBolt 3
- (at least) 2 legacy SATA drive bays internally
Pro users aren't looking for unique or avant-garde, but rather boring boxes that let you configure your desire with just boring yearly hardware refreshes with boring updates that the average consumer doesn't care about. Apple can phone it in, and the creative market wouldn't leave. However if they ignore it they will. There's sect of video editors/illustrators/video compositors/3D animators/audio professionals/scientific modelers/developers/power users that just want an upgradable box that runs OS X. These users do not need press events or big marketing campaigns, just an order page where they can throw their money.
Plugins that do mildly comical things have been around for awhie, but 2016 is the rise of the political browser plugins. While it didn't start with John Oliver, one of the first high profile plugins was Drumpfinator. While a fan of John Oliver, it was a one-note gag, and to me personally, wasn't that funny, but I appreciated commitment. There were a few others such as a browser plugin that replaces pictures of Trump with kittens, a plugin that attempts filter Trump mentions from any page, but that seemed to be the extent of it.
However, the rise of fake news spawned something far more interesting: injecting in-page fact-checking content. Slate created its This is Fake chrome extension that labels Fake news as such. Even more exciting and more resource intensive is Washington Post's RealDonaldContext which provides Washington Post's analysis on a per-tweet basis of Donald Trump tweet claims. This is something entirely new as far as I can think of as its an on-the-fly pro-active level of journalism that's responding to your interactions without having to even go to the parent website. I have a feeling it may be scratching the surface of what's possible. This strikes me as something new and unrecognized as such. Both Slate and Washington Post are avant-garde, stretching way we consume news with contextually aware experiences.
- Any desired font could be embedded into the flash file
- No images were required
- The same flash file would be used through the site, thus cachable and more efficient than images for bandwidth
- Any copy updates to the HTML were reflected immediately as the JS simply fed the text into the SWF
- Most people had flash, and if they didn't, the text in question would still be rendered as plain ol' text, just not with a custom font
- Predates jQuery
For the truly curious, you can find the sifr generator here.
Sure you took a significant performance ding in 2005 for polluting your site with random SWFs but ended up with a site with custom fonts. It was an elegant application to a stupid solution.
Fast forward to 2016: Flash is dead and websites now ask for permission to run flash. This is an unforeseen problem as it doesn't fail gracefully in modern browsers and in the case of FireFox leaves black squares on the web site, waiting for the user to allow flash to run.
How to fix
Fortunately the quick fix is easy, remove the sIFR.js. Look for sIFR.replace in your JS to see all the targeted text that's being replaced with an SWF, to write out new CSS rules to format. Hunting down the fonts can be a bit of a chore but hopefully the swfs are named after the font. If you can't find webfont versions, just hit the usual grounds of Google Fonts or Font squirrel to find "like" font replacements. In 2016, its unlikely many sites are still up using sIFR.js. Good luck out there!
Example of sIFR
As technology, social media, and politics meld ever deeper; we see what a presidential rule by tweets may look like: executive enforcement by twitter. The Washington Post asks, "Did Donald Trump tank Boeing’s stock because he was mad about a news article?" Regardless of motivation, the executive branch seems to have a new power and one that has no precedent for regulation.
The company I work for, Emerge Interactive launched its free A11y WCAG Accessibility Checklist, a simple checklist-based off of Luke McGrath's and W3C's recommendations. It can now be found on Apple's App Store and Google Play. This was an internal project spearheaded by former co-worker Joe Watkins but included most of our team. I lent my hand, especially in the development of the microsite.
Accessibility is essential when only 5% of a survey of 215,942 people were deemed fully computer literate, and 1/3 is can completely medium level tasks. What we design has to be digestible by all.
subscribe via RSS