The post New Release for 2019 appeared first on Get Shipwright.

CSS Variables

That’s right!  Shipwright will now come, out of the box, with CSS variables baked in.  Support for CSS variables is now far and wide, with the only straggler being IE11(but don’t worry, we have a polyfill baked into Shipwright just for that!).  This means you can declare theme colors, font sizes, faces, etc, in just one place, then continually call these as variables in your CSS code.  Yes yes, I know, this sounds a lot like SASS.  Except, ya know, no need for specialized programs, compiling, and making nigh-unreadable CSS files with extra steps.

The Latest Font Awesome

We’ve also added the latest version of FontAwesome to the latest build of Shipwright, ensuring the best in lossless icon delivery.

The post What is in the Next Release? appeared first on Get Shipwright.

‘Great!’, you might say, but you might also wonder what I’m still being dinged on to keep me from 100 on GTMetrics and Pagespeed Insights.   It’s the usual song and dance about parsing of javascript(and Oh no, I have a whole 129 BYTES of JS inlined! HORRORS!), oh and the ever insistent demand I minify my CSS.

I still won’t minify.  According to Pagespeed Insights, taking my beautiful, human-readable CSS and compressing it into an unreadable mess that I will have to use bower or some other godawful client-side/server-side toolkit to compile/decompile my CSS would save the website viewers from loading the horrors of extra whitespace in my CSS totalling up to… 2.4 kilobytes.

Now, I know we’ve talked about this before, but I’m going to talk about it again.  I’m not going to add additional server-side tools to compile CSS files for me to save 2.4 kilobytes.  I’m not going to keep human-readable and machine-readable files side-by-side to save 2.4 kilobytes.  I’m not going to change my workflow for 2.4 kilobytes.  

Now, the reason people love minification is because they love their toolkits.  They love pre-processors, post-processors, setting up environments, and big, clunky frameworks that has so much excessive styling and code that you might actually get real savings if you minify the CSS files.  I propose the problem is not that I don’t minify my CSS, but that your workflow is so clunky that you NEED to minify your CSS.

Minification would only save me 2.4 KB.  You need to be a on a 28.8 modem before the time difference in loading the extra 2.4KB would be noticable.  The site loads in less than half a second on a 3G network.  I’ve decided to do a little experiment: I’ve compiled the css measurements of my site both with and without g-zip compression and minification, both using Shipwright and using Bootstrap.

My entire CSS stack, including custom CSS for this site and Shipwright as a framework weigh in, together, g-zipped at 16kb.  Non-minified and non-gzipped, the site css weighs in at 81kb.  

If I take Bootstrap and my custom css together, impling any custom code to duplicate the site I built would, at minimum, mirror what I wrote for Shipwright, the site would weigh in, non-minified and non-gzipped, at 221kb.   Gzipped, the size would be 25kb.  Non-compressed, the CSS stack is nearly triple the size simply by using Bootstrap.  Compressed, the size is nearly double.  

What we have here is a systemic problem of people used to large, bloated frameworks that bloat the web, creating the false dilemma and need to minify CSS, destroying readability in favor of savings that measure less than a megabyte.  You can get even more savings by using a lighter framework, or even no framework at all.  You can also decrease the number of programs you use for development, decrease the number of steps you need to use before deployment of changes, and overall simplify your life.  

The most radical thing I will declare right now is we should stop listing CSS minification as a speed optimization if the resulting minification reduces file sizes less than 10kb.  The minification process does not produce meaningful savings that are noticeable by the end-user, and listing them as an optimization process only encourages younger devs to destroy human-readability versus teaching them good dev habits.

The post Let’s Talk again about Minification appeared first on Get Shipwright.

Overall, it’s safe to say, I know a thing or two about email development.  So imagine my surprise when I found out that frameworks have been created for email development.  Wait, what’s that?  Frameworks?!?  For Email?   So I researched further.

The Frameworks In Question.

Foundation for Email is the first one I really looked at.  Foundation promises SASS in email, a responsive grid, it’s own unique markup language, and many many more features.  MHML promises yet another markup language, a responsive grid, and many other features.  There’s also been several attempts to create a Bootstrap for Emails too.   The biggest problem I have with this is the concept of a framework for emails is inherently flawed.

Want to Learn Latin?  Ok, First Learn French.

Just as I detailed in my earlier post about pre-processors, browsers function by reading HTML, CSS, and Javascript.  Email clients don’t really read javascript, and, due to standards present from Outlook, we have to use very little to no CSS, thus most times emails are coded in tables, with inlined styles.  Because of preview panes, most emails will be designed to be between 500 and 600 pixels wide, well under the width of even the most narrow tablets.  The limited nature of CSS support in emails means that any mobile layout would, naturally, default to a single column look most likely.

There’s much more to making emails; bulletproof buttons, bulletproof backgrounds, webfonts, Outlook hacks, webmail hacks, etc., that going over everything would be more in place at Litmus’s wonderful community.  The point remains that, on a whole, most emails should not have that much code in them, if you can help it.  Afterall, we are talking about a piece of code that is sent via email.  Honestly, emails should rarely be over 30kb in file size, or over 1,000 lines of code.  Tables, archaic as they are for forming layouts in HTML, are still valid HTML code, even in an HTML5/CSS3 world.

These newer, ‘easier’ formats for writing emails provided by Foundation and MHML create the exact same issues I wrote about in my pre-processor post.  This is the creation of a similar, but not exact language used for software to later interpret into valid code.  And, once more, the existence of Foundation’s INK(what they call their markup language), an MHML’s markup language, plus what I can imagine is many others out there, is creating various competing standards of language when, again, in the end, the browser can still only understand HTML.

This is like saying to a language student Hey, want to learn Latin?  Ok, first learn French.  

No to Frameworks, Yes to Boilerplates

While I don’t believe in frameworks, I do believe in starting all emails on a basic email boilerplate.  Something that has 90% of what I always use in every email.  It’s small; compact, and has no grid system, no SASS, and no unique markup language.   It’s a boilerplate.

It’s a Friggin’ Email

I really really want to emphasize this.  This is a piece of HTML/CSS that you’re writing that will most likely be less than 30kb.  It’s something that, with practice, you should be able to write in just under 2-3 hours.  This is an email.  This is not a landing page, a website, web-app, or anything else that would require a code-base that would honestly eclipse the size of the email itself.  This is like having to build a sandbox in your backyard and renting a backhoe.

The post Frameworks for Email?! appeared first on Get Shipwright.

When Did It Matter?

Even just three years ago, I can see the argument that we should keep compatibility for IE9,  IE8 or even IE7.  These sorts of issues required very specialized testing tools, including some very shady installs of multiple versions of IE on one Windows install.  Some shops even included several older computers, virtual machines, and other clever tricks to test older and older browsers.

IE of yesteryear had issues with the box model, with float clearing, and overall only just barely supported the base CSS2 spec, much less had any CSS3 features.

What Changed?

Quite simply, Windows 7 happened.  And with it and later versions of Windows, the vast majority of Windows XP users finally upgraded.  Those that didn’t were more likely to use a browser other than IE anyways.  Microsoft made IE updates part of their monthly security updates, and the other major browsers packaged automatic updates into their systems as well.

This meant that the vast majority of people were most likely using the latest, if not the second-latest version of any major browser.   You would actually have to put in effort; actual time, research, and energy; into keeping an older version of a browser running on your system.

After checking total browser user-share statistics, the number of people actually using browsers that can’t use calc, flexbox, vw and vh is only .58%.  Not Fifty Eight percent.  Point Five Eight.  A little bit over Half a single percentage.   You would have to get 200 people gathered before you find one of these people that purposefully sets their browsers to be behind the curve for god-knows whatever reasons.

So How Far Should We Go?

I usually set a rule that I support browsers for 2 major version releases back.  When I explain why, with the statistics and data available, I have never had someone go “Well, let’s support IE9 anyways.”.  Make your lives easier: Let’s drop IE9 support.

The post How Far Should We Go With Browser Compatibility? appeared first on Get Shipwright.

Before I start any project, I always ask myself Self, should I use a framework for this project?  Even with a simplified framework like Shipwright, there are times the answer is a resounding No, and it is up to us a developers to listen to that No.  A month ago, I was given a single page web-app that needed front-end development.  After asking myself the initial question and weighing in pros and cons, I decided for this project, the answer was No.  So I started work on this web-app’s front end dev, and a mere 2 and a half hours later, I was finished.

Honestly, if I had used Shipwright, the timeline most likely would have been about the same, but there would have been the added bulk of Shipwright added to the project.  Shipwright is still pretty light at 46kb of CSS.  But this webapp I created; it’s CSS was only 18kb.  There has to be time that you can develop out out whole cloth versus relying on a framework, ANY framework.

Examining The Why’s

Another example I have is where I was working on a project site, and there was a single landing-page being added to the site.  The rest of the site was developed by me, while this one landing page was developed by another developer.  Prior to the development of this landing page, the whole site’s stack was rather light.   This landing page could have been, and probably should have been, developed with no framework.  Unfortunately, it was developed with Bootstrap, simply because this other developer was simply ‘comfortable’ with Bootstrap.

A ‘Bootstrap Developer’

Or, if we’re willing to examine the truth, he was a ‘Bootstrap Developer’, not a ‘Web Developer’.  This simple act of adding another framework also quadrupled the site’s size.  This is yet another trend I’ve noticed with most web developers I’ve met; they’re usually dependent on the framework and tools they were taught and, once out of their comfort zone, seize up.  I still hold a lot against the way devs are taught, and again think that frameworks, the way they are taught, are more of a detriment than a solution to a problem.  Or, more likely, it’s a problem looking for a solution.

When You Have a New Hammer…

There’s an old saying my dad taught me.  When you have a new hammer, everything will start looking like a nail.  What this means is whenever you’re taught a new technique or tool, you want to use it whenever or where ever you can, regardless if it’s the right tool for the job.  You’d be surprised at how many development jobs you do that require only a stylesheet, an HTML file, and some good old coding know-how versus an out-and-out framework.

The post I’m a Web Developer, not a Shipwright Developer appeared first on Get Shipwright.

What is a CSS Pre-Processor?

Whenever you load a website, several things always happen.

1. The browser reads the direct HTML provided.
2. The browser then reads any and all CSS attached, be it inlined or in it’s own CSS file, and uses that information to start styling the HTML.
3. The browser then reads any and all javascript attached, be inlined or in it’s own .js file, and uses that information to start writing to the HTML.

Regardless of whatever you do beforehand, these three things always occur.  The Browser will always read only three languages: CSS, HTML, and Javascript.  SASS and LESS are CSS-Like languages created that follow the same basic syntax of CSS, but with added features in the syntax.   There’s an easier way to explain this:

Imagine CSS is Latin.  For the sake of this example, the browser understands only Latin.  Now imagine SASS is French.  SASS, like French, is derived from Latin, but it is not Latin.  It shares lots of things with Latin; the most notable being a common alphabet and some base grammar rules.  But, if you speak French to a Roman at around 100AD, they would not understand you.   This example is a bit extreme, since the overall syntax of SASS is nearly the same as CSS, save for variables, nesting, and extensions.

1. Variables in SASS are much like variables in any programming language.  You set a variable, like $main-font to be something, like arial, sans-serif.  This way, every time you want to call the main font family, you just insert $main-font into the font-family declaration.
2. Nesting in SASS is basically a way to write styles for children of a parent object by implying the child/parent relationship with a tab versus writing the parent name.
3. Extensions is basically making an entire style block a variable that you can insert multiple times in a document, but declare only once.

The Downside to Pre-Processors

Now, while these things do sound nice, let’s talk about the downsides to using SASS.  The first being, as I said, the browser can never ever be able to read SASS files, much less interpret them as CSS.   As I said, it would be like speaking French to a Latin-speaker.  You would need to pre-translate the SASS into CSS.   Lots of tools exist that compile and create a CSS file for SASS file changes, but most of these tools are paid tools.   You can also do this server-side, if you are willing to install RUBY.

This is the part where the advantages of a Pre-Processor starts looking less glamorous and more cumbersome.  Specialized tools?  Installing a whole other server-side language on your environment just to interpret a front-end language?  Isn’t the purpose of tools to make our lives easier, not harder?   That’s not to mention that, as the CSS spec itself matures and changes, the features of SASS that made itself useful are becoming parts of the CSS spec itself, albeit in it’s own way.

CSS has announced variables becoming a part of the language for some time now, and with the pace of browser updates, it will be rather soon that we can adopt this standard.  What’s more is, CSS variables are in a very different syntax than SASS variables.  Why learn two different standards of writing something?  Also, the SASS language syntax and it’s similarity to CSS might seem like a strength, in reality it’s also it’s greatest hindrance.  I have worked with several other developers in my career, and I have seen times when a front-end dev pops into a CSS file to make a quick fix and accidentally throws a mixin into a CSS file.  The languages being too similar invites this sort of accident into happening.

Also, let’s say that you need to make a quick CSS change to an existing site, and you’re away from your usual toolset.  If the site was built on Vanilla CSS, all you need is an FTP client and a text editor.  IF you’re using a pre-processor, you can certainly make that quick fix with the same tools, but you would then need to make an edit to your SASS file and CSS file, or just the CSS file and note to yourself what the change is so you can make it in your SASS file, thus creating what is known as a maintenance nightmare.

And What They’re Taught in School

I was working as Lead Developer at a shop, and we were interviewing several front-end devs for an open position.  We gave the applicant a working interview(meaning he was paid for his time and effort); a simple project with a designed PSD file and told to do front-end development ONLY.  I remember this gentleman well because he was a recent college grad, and had some very peculiar habits that bugged me; habits I learned are taught to pretty much every web developer now.

This gentleman spent a good 3 hours setting up his environment to develop, including wrestling with a bower.js file.  Twice during this painful process, I told him that he needn’t bother with this; this is a front-end only examination.  He has the PSD file, he had an HTML editor; he didn’t need anything else.  He disagreed; he felt that it was more important he got his environment set up perfectly; his SASS working and compiling versus writing HTML and CSS to pass an employment test.  And this wasn’t the first time.  Every time I meet a young developer who just graduated or just finished an internship, they are always busy with every project setting up an elaborate environment, getting SASS and pre-processing working.

Getting their environment perfect seems to be more important to teach than teaching CSS nowadays, it seems.  Out of 5 young devs I’ve met, 3 didn’t know what the box-model was.  4 of them didn’t know what the checkbox hack was.  2 didn’t know how to vertically center an object without display: table.  But, ask them to set up a SASS environment, and all 5 could probably do that.

In Closing

CSS is a very mature and powerful markup language.  Could it benefit from variables?  Absolutely.  Is SASS the end-all, be-all that teachers try to preach it to be?  Most certainly not.  Does it speed up development?  In MY case? No, I write Vanilla CSS faster than those 5 young devs writing SASS.  Your own cases may vary, but all I ask is that you look at the scope of your next project before you decide that it warrants SASS and maybe… just maybe…. tinker with some good old Vanilla CSS and expand your knowledge on some of the newer things you can do, like with nth-child, flexbox, or even calc before you run on over to SASS.

The post Pardon my French about CSS Pre-Processors appeared first on Get Shipwright.

I’m sure, somewhere, there’s an audible gasp from my audience.  How DARE he question minification! I question it because no one else will.  Let’s look at a site I recently launched, Shady Oak Barbeque.  This site’s entire CSS stack is, unminified, 175kb in size.  Unminified, the CSS is human-readable and human-maintainable.  There’s no need for pre or post-processors on the site environment or my working environment.  Making any addition would require just a text-editor and FTP access.

Minifying the site’s CSS, and thus adding the need for more tools for maintenance, and making the CSS un-human-readable will save me a grand total of….. 417 bytes.   417 bytes?   Wow, that’s anti-climatic.  The very first computer available on the consumer market, the Altair 8800, which had no screen, no keyboard, and a series of switches on the front, shipped with 256 bytes, just to give you a perspective of how little minification can save your site size in loading.  I could let you know how many 10ths of a millisecond that 417 bytes could load, but I think that would be giving more thought to the math than the math requires.

I’ve always called Minification “Spending Dollars to Save Pennies”, and I think this example is a great way to illustrate that.  Why overload your environments with bulky pre and post-processors to handle minification when the grand total of savings average less than a kilobyte?    Honestly, better image compression practices and GZip compression in your htaccess file gives you better, more obvious returns than minification.

The post Why I Don’t Minify my CSS appeared first on Get Shipwright.