Web Performance Optimization on MSDEV Show

The podcast for my recent conversation with MSDEV show is up.

Check it out here: MSDEV SHOW

Having an -informed- opinion.

Today I had the pleasure of speaking with the smart guys at MS Dev Show about website performance optimization. It was born out of an article written about http://crunchyowl.com/ performance tweaks which you can read about here: http://crunchyowl.com/improving-performance-on-crunchyowl-com/.

Relevant: I made an abbreviated performance checklist here.

Carl at one point asked me if I had an opinion on spriting versus data URI’s. I mentioned iconfonts too as a contender, but disembarked from productive podcast territory by ducking the issue completely. Without specific context, I noted that each has it’s own merits, and above all else, the fact that we are having the conversation at all is big win. In reality - any solution that delivers an optimal experience for users is a good one.

It might not make for controversy and talking points (I don’t think that was Carl’s goal), but declaring a wishy-washy answer is sometimes the right one. Understanding the pro’s and con’s of each solution is important, but like with many things, there is often more grey than black and white. Don’t know the answer for a particular problem? Go find your shade.

Again, thanks to MS Dev Show for getting me thinking about web design and performance anew.

Maintenance Release of Patternlab Node Released

I just published Patternlab Node 0.1.4 to github. While researching a pull request I noticed nested pattern rendering was not functioning. Apologies to anyone that encountered this.

Here’s the changelog, then.

  • Support for forward slash in flat pattern names for unix systems
  • Fixed issue with nested pattern rendering

Time for a test suite! #opensourcelessons

Upcoming Podcast Appearance: MS Dev Show

Catch me soon on MS Dev Show Podcast with Jason Young and Carl Schweitzer where we talk website performance optimization!


Just pushed patternlab-node 1.2, check out the release here

Here is the changelog:

  • ADD: Abstracted template rendering into a function for easier swapping of rendering engine
  • ADD: Smarter filtering of files to support other templates Thanks
  • ADD: Help command line agument
  • ADD: Version command line argument
  • ADD: Patterns only command line argument
  • ADD: IshControlsVisible options. Can now hide any ishControls you like.
  • ADD: Documented the command line interface
  • CHG: Put debug flag in conf.json instead of package.json
  • CHG: Aligned styleguide css with patternlab-php
  • FIX: Removed node .8 from travis
  • FIX: Code and annotation support in patternlab viewer
  • THX: thanks @ivanmayes and Shoptology crew for contibutions!

More change coming

Interest in patternlab-node is steadily increasing, as as such it needs to mature out of its brute-force port mentality. A notable watcher, Addy Osmani says on his blog:

First do it, then do it right, then do it better. This is one fundamental I always keep in mind when developing anything.

Patternlab node needs to do this. Next steps, extract patternlab-node into a core engine and allow different build systems to run it as a module. Grunt/Gulp, here we come!

Lesson Learned: Angular + jQuery

It’s pretty clear if you dig into Angular that its control of the DOM should be absolute and exclusive - at least if you want to avoid getting out of sync with your model.

I experienced this firsthand today with the following snippet:

$( "#weekStart" ).datepicker({
  showAnim: "fadeIn"

Having wrote my webapp over a couple weeks, this datepicker initialization code slipped through at the bottom of my html, tucked neatly inside a domReady event, while the rest of the app was handled by angular.

When it came to implementing app data model persistence using local storage, I noticed only one instance where the stored JSON was not reverting state- the datepicker.

Clear as day now - but a definite hmmmm moment. The fix took a minute within Angular, but I chalk this up as an instance of grasping for the familiar instead of thinking in a more data-centric way.

Have a similar experience? I’d love to hear about it!

Pattern Lab Node v1.1 Released

I’ve just published Pattern Lab Node 1.1 to Github. It comes at the onset of a journey toward adherence to the pattern lab specification created by @dmolsen


This release cleans up some messy dependencies, and really sets the stage for more meaningful development.

  • FIX: Removed View All Pattern SubItem Link Logic, no longer in reference implementation
  • ADD: Flag for generating debug file
  • ADD: Travis CI test support!
  • ADD: Contributing file
  • ADD: Repository to package.json
  • FIX: Manage Mustache dependency using NPM
  • THX: thank you @tbranyen for tip on repository, Mustache, and NPM!

Toward a More Perfect Pattern Lab Node

Stay tuned for version 1.2, already under development in the dev branch! With that version comes a moderate refactor of the builder, more unit tests, and some specification-mandated features. I also hope to get lineage and annotations functional - these have been gaps for too long.

Thanks for the continued interest and support in pattern lab and pattern lab node.

Type Exploration #7

Type Exploration on Code Pen

Wire One from Google Fonts

On Pattern Lab - Node

Dave Rupert sparked a conversation today about Patternlab after some initial usage, which elicited a nice round of feedback from others.

Brad Frost summed it up nicely:

It’s been a process to make Pattern Lab simultaneously flexible and robust

I want to put some thoughts to paper about how this process has played out for me.

Patternlab-PHP was rather feature-rich when I started. I likely missed the conversations Brad and Dave had about what PL should and shouldn’t be. It was simultaneously an amazing living reference, but also a skyscraper to understand, deconstruct and finally rebuild with different materials. Dave Olsen helped immensely in those first steps.

I can feel the desire to turn PL into more than it already is, to turn it into a platform through which an entire project can grow, mature, and finally be deployed. I have also experienced first-hand the complexity that can creep into the solution when attempting to support so many features.

To me, Pattern Lab is:

  • A tool to build reusable, scalable markup and css snippets. As Brad intended, you can decouple atomic design principles altogether if you so choose, but it’s also…

  • A tool to glue components together in an iterative, incremental fashion.

  • One of many ways a web project could be built, but not the only way. A multi-tool, but not the best for every job.

  • An alternative to photoshop comps and high-fidelity mockups as an acceptable design deliverable

So, as I reread this, and wonder at which features to implement next against the living spec that is the PHP version, I question what feels missing to me. (Also excited at the prospect of Dave and Brad writing a spec!)

What pain points have I experienced?

  • Initial project setup is cumbersome. Hopefully some npm, grunt, dependency maturity in the near-term will help. As others have stated, attempting to obfuscate patternlab internals should be a goal. Addy Osmani suggested a pure node implementation which would be most agnostic. To me, grunt feels more consumable than pure node. I need to look into Assemble.

  • The iframe-viewer still gets me sometimes. Living in this responsive age, I naturally try to resize my window instead of using the controls. I’v felt at times that the ish controls are not perfect, but haven’t been able to determine if it’s my problem or something in the implementation yet. I wonder if this can be configurable.

  • The port is inelegant and immature. I brute-forced the processing of templates, instead of globbing as the PHP version did initially. While I think this is straight-forward and decently documented, it is not DRY or unit-testable. A refactor would do some good.

As a peripheral member of the community, it’s exciting to see other’s interested in the same problems that drew me to Patternlab too. I’m also excited to see what ground we can make on PL-PHP :)