How JavaScript is like pepper

Gone are the days of "sprinkling" JavaScript over websites. Today, we discuss the one place where you should use JavaScript frameworks

This is a repost from 2007-Dec-04 titled "How AJAX is like pepper." I wanted to freshen it up a bit. It's amazing how relevant it still is today.

When I first posted this is 2007, AJAX was the latest craze blurring the lines between a desktop application and a web application. Heck, jQuery was just introduced in 2006. JavaScript was the wild, wild West back then.

Who knew fourteen years later, we would have browsers full of more JavaScript than HTML and CSS combined.

Today's post is meant to take a step back and possibly adjust your perspective as to whether you need a full-blown JavaScript framework that requires a loading screen for every page you visit on your site.

Take It From The Top

In a recent post about How Do I Get Into Programming?, I mention the best way to learn web development was to focus on the "Trinity of the Web."

• HTML - Provide the structure of a document
• CSS - Provide the presentation of a document
• JavaScript - Provide the behavior and interactivity of a document 

Learn the basics of these three technologies...in that order. They are the building blocks of the Internet and they've lasted over 25 years so I'mma betting they will last another 10!

The good news is once you learn one of them, you'll be able to apply the concepts to their open-source counterparts.

For example, once you learn about CSS, you can leverage your styling skills by learning either SASS or LESS. Each technology builds upon these core concepts.  

And then we come to the elephant in the room: JavaScript.

If we want to talk about projects spun off of JavaScript, I can name about fifteen open-source libraries in 30 seconds built to make your life easier when, in reality, it's slowing down websites.

You know that lag you get when you visit a site?

It's the Google Analytics loading in the background and sending data out for reports.

It's the jQuery on multiple pages because someone didn't use the slim build of the library.

It's the Ad Network script you added to your site so you can earn some extra money if someone clicked on an ad.

Oh, and it's the React framework in the background to provide a quick user experience while visiting your site.

Cue the splash screen with the "Loading..." message.

"But JavaScript is Totally Faster"

This was a discussion I had with a developer where they couldn't accept that anything was faster than JavaScript.

Each JavaScript framework/library has a price, but it's still not as fast as HTML.

I keep referring back to this tweet from Zach Leatherman:

Which has a better First Meaningful Paint time?

? a raw 8.5MB HTML file with the full text of every single one of my 27,506 tweets
? a client rendered React site with exactly one tweet on it

(Spoiler: @____lighthouse reports 8.5MB of HTML wins by about 200ms)

— Zach Leatherman (@zachleat) September 6, 2019

What does it mean?

It means the browser loaded an 8.5MB HTML file with 27,506 tweets faster than a client-rendered React site with exactly one tweet on it.

HTML wins again.

Google AMP Was On The Right Track

I touched on this subject briefly in the newsletter about Google AMP dying off and how Core Web Vitals are now becoming the standard for fast-loading sites.

With Google AMP, Google wanted content publishers to remove their extra fluff from heavy content pages (like ads, large images, and superfluous JavaScript) and provide a simple page with simple content.

Without the extra crap, the page would load faster therefore making it a better experience for the user.

Which is what we all want, right? 

So What's the Silver Bullet?

Well, for one, it's not a silver bullet. It's a collection of silver bullets.

1. Design with HTML

Think of HTML as a wireframe of your website and code as much as you can with simple HTML.

I know, I know, I can hear everyone saying, "<Framework> can help us with that." I can attest I'm just as guilty because I love Bootstrap for my websites.

If you absolutely have to, use a slimmed-down version of the framework/library. If there isn't one, try bundling and minifying the code with a Task Runner.

You'll thank yourself later (and so will your audience).

2. "Apply Lipstick to the Pig" with CSS

Once the HTML is done, you can easily apply CSS to your pages. Don't worry, it takes time to learn CSS. If you need assistance with learning CSS, I have a CSS Collection to help and, oh, make sure you check out the CSS Zen Garden. ;-)

While CSS frameworks do all of the heavy lifting for you, it's always good to understand how the 'C' (meaning Cascading) works in Style Sheets.

3. Introduce JavaScript Sparingly

Your JavaScript should be sprinkled throughout your web application...like pepper on food.

While it makes sense to "sprinkle" it on some applications, don't create an entire website running on JavaScript. The more you add to it, the more complex it will become to maintain and the more it will slow down the site. Slow websites cost you customers like Amazon discovered.

It's been proven.

Bottom line: keep it simple and use it with good judgment.

You'd be surprised what you can find with simple HTML and CSS.

If you need a modal, build a simplified version of a modal dialog without JavaScript.

Caveat

In my experiences, there is only one reason I would apply minimal JavaScript to a website:

Public-facing websites

If you are creating a full-blown application and it's behind a login for registered users, by all means, unleash the hounds of hell and build the best damn web application with as much JavaScript as you can. Keep in mind, though, it also has to be fast.

If you are using entire JavaScript frameworks to build a public-facing website, I would rethink the design of your site. I'm sure everyone will enjoy those slow-loading splash screens for those on low-bandwidth connections.

JavaScript should be a last resort on a public-facing website. Anonymous users on your site should have low to almost no JavaScript impediments when surfing your site. 

Conclusion

What nudged me into updating this post from 2007 was the weekly ASP.NET Community Standup with Jon Galloway, Damian Edwards, David Fowler, and Stephen Halter.

At the 0:23:35 marker, Jon Galloway mentioned the post titled "Why Simplicity? Choosing a Web Architecture" and suggested web developers resist the urge to use the latest JavaScript framework to build a site when HTML, CSS, and a sprinkle of JavaScript may be enough and provide a better user experience overall.

One of the headings in the post recommends,

"If your use case requires a bit of client-side interactivity, use the above options with a bit of JavaScript."

I'm with Jon on this one.

It seems we are writing code backwards. We're building applications written entirely in JavaScript before building the HTML and CSS.

Then I hear developers responding with "Why would I use HTML and CSS? Those are not languages. Hey! I have a great idea...let's absorb CSS into JavaScript!"

Oy!

Build your site initially with HTML and then add CSS. If you need interactivity, then introduce JavaScript.

While I get the fascination with JavaScript and how it's taking over the world as the most popular language, try to resist the shiny object and see if you can replace some advanced JavaScript with simple HTML concepts.

For another example, you may not need a JavaScript accordion when a simple <details>/<summary> tags are all you need to accomplish the same thing.

Think of JavaScript as pepper on food.

Is your website fast? How many JavaScript libraries are you using on your site? Post your comments below and let's discuss.