Restive.js — One Giant Leap

Just in case you’re not familiar with Restive.js, it’s a designer-friendly jQuery toolkit for building responsive and/or mobile-friendly websites. There’s a pretty good introduction on the ‘why’ of Restive.js here.

Back in 2012 when I first started learning responsive Web design, I was really frustrated with CSS Media Queries. It wasn’t that the technology didn’t work, it was that it didn’t work as well as I would have liked. I can’t blame media queries too much though, because it wasn’t exactly built to handle the challenges it would eventually be called upon to solve, especially the challenge or responsive Web design.

I love CSS. I love the concept of the cascade, the execution of specificity, and the functionality of classes. It’s really the best part of my Web design workflow. Unfortunately, CSS doesn’t have have a great solution for responsive/mobile-friendly Web design in media queries.

The Problem

I still find it hard to fathom that the entire Web industry has somewhat standardized on a technology that has some very significant flaws.

CSS Media Queries for responsive Web design has 3 major problems I just can’t get over:

1. Limited Conditionality: a media query is sort of like a conditional statement. For example, in one plausible scenario it could be “if the viewport is between 320 pixels and 480 pixels, then apply this CSS rule.” However, media queries are very limited in terms of the actual conditions that you can target for. For example, you can’t target iOS or Android; smartphones or tablets; mobile or non-mobile devices, etc. There’s a very hard limit to the conditionality that’s available to you.
2. Indefinite Behavior: When you finally get passed the less than intuitive syntax of media queries, you’ll most likely come across another challenge; its demeanor. It may be clear to you what the CSS media query is supposed to do, but its behavior in the wild cannot always be predicted accurately. That’s why you usually have to test your Web page/site in multiple devices to make sure it works. This lack of definitiveness [and intuitiveness] is a workflow killer because of the extra time you need to build and test.
3. Slow Improvement Roadmap: Since CSS media queries are baked into browsers, they are more or less limited by the standards process; which means it takes ages for anything to be upgraded or improved [without the help of a dependable polyfill]. I’m not sure if you know much about standards process, but I find watching them evolve is about as fun as watching molasses run a marathon. This would explain why CSS media queries [for responsive Web design] are pretty much the same today as they were when the world started using them for Web design over a half-decade ago.

These challenges [and more] made it incredibly cumbersome for me to build a responsive Web page. I would have preferred a simpler method where I could leverage a simple selector, like a class, and then use that to customize the layout. Unfortunately, there really wasn’t anything workable I could find at the time, so I figured I’d try and build one.

The Solution

And that was how Restive.js — a designer-friendly jQuery toolkit for responsive Web design — was born. It was an incredibly traumatizing experience primarily because I knew jQuery, but I didn’t know much JavaScript. Writing a plugin for jQuery wasn’t as easy as I was led to believe from the numerous blog posts and official jQuery docs. I have to say a big thank you to the StackOverflow community for helping me get through.

It probably took me more than a few months extra to write, and a few more just to test it. I know this is probably against the open-source tradition of getting things shipped early and often, but there’s nothing that makes me madder than a piece of software that doesn’t work as advertised; open-source or no. If it was going to work, it had better work darn well.

I launched restive.js on Github in 2013, and the reaction was quite good. I know Github stars are all the rage these days, and restive.js has about 450 of them to date, but what was important to me was keeping the Star-to-Unfixed-Issue ratio low. Even if only 50 people were using restive.js, I wouldn’t want more than one or two to have non-fixable case-specific issues with it. I also greatly appreciate the personal emails I’ve received from Web developers thanking me for making restive.js happen.

Fast forward to today, Restive.js is currently being used by brands such as Samsung, Nascar, Zadarma, Brookside Chocolate, Aurubis, Dancing Deer Baking Co., and Universidad Americana. I don’t have definitive stats among developers, but I would say there should be at least a thousand developers using it. I could never have imagined that it would get that sort of traction for a personal project, and the experience has validated my expectations that CSS media queries were not working for everybody.

The TODO

Restive.js was quite capable as a plugin, but there were a few things it was lacking that needed to be addressed:

Performance optimization

Today, having a responsive and/or mobile-friendly website is no longer enough. If Google is a friend you pay close attention to, you’ll probably know by now that it needs your website to be both mobile-friendly and fast. Restive.js only handled one of these issues, and it needed to handle both. As a script, it also needed to run faster.

Remove dependencies

The major dependency that Restive.js has is jQuery; technically, it’s a jQuery plugin. I can’t even begin to express my love for jQuery, but it did add about 30 kilobytes [gzipped] to the existing payload of Restive.js. I don’t think I was even using up to 20% of its total functionality. So, one of the major goals was to optimize restive.js enough that it had a critical payload less than 14 kilobytes [gzipped]. This couldn’t happen without making some painful cuts, and jQuery had to be one of them.

Add More Features

There were more features I wanted to add to Restive.js to make it even more powerful and useful, but because of how heavy it was already [if 60-odd kilobytes gzipped is heavy in today’s Web], I couldn’t justify the extra bloat without optimizing for dependencies first. Features like scroll breakpoints that would add a class to the target DOM element when you scroll past a point in a page; automatic turbo-classes that added the relevant classes without you having to set them up first, and a slew of methods to do a few useful things like routing, data-binding, lazy-loading, and more were all in the pipeline.

Improve Docs and Tutorials

One of the major mistakes I made with restive.js was not taking a lot more time to improve the documentation and learning content around it. Even though it was pretty easy to get started using it, better documentation and more tutorials would have helped, especially for novice Web designers/developers who would’ve needed a lot more hand-holding. I had actually created a list of about sixty (60) or so tutorial concepts, but I just didn’t follow through, and for this I apologize. Amends loading.

Making all these things happen with the current restive.js structure is possible, but difficult. Sometimes, you just need to make a step change for that step to count for something. So that’s what’s going to happen.

The Giant Leap

Restive.js being a JavaScript library dependent on jQuery can be quite easily extended [given enough time and patience], but now it’s time to make one giant leap. God willing, in about a month or two from now, Restive.js will be relaunched as rScript.

It’s been completely rewritten from scratch to remove any unneeded dependencies. I built a slim micro-library called rQuery to replace jQuery. Another interesting thing happens around the way it’s packaged. rScript has a performance pack that splits its payload into 2 files: critical and non-critical. All you need to do is load the critical file [which happens to be less than 14 Kb gzipped], and it will load the non-critical file in a non-blocking manner; speeding up your Web page in the process.

In addition, rScript is now even more designer-friendly because there’s like one line of JavaScript code to set it up. After that, it handles all the viewport and scroll tracking (throttled, of course) behind the scenes; you do the rest in your CSS. This ability is very useful if you’re building Progressive Web Apps and want to use one CSS file to build layouts for multiple OS platforms on multiple device classes in multiple orientations, and then some. rScript is also extensible.

And, there are close to 100 tutorials in the works. Everything from building a mobile-friendly navigation menu to building a progressive Web app to working with data. Basically, it’s going to be almost everything you need to be an awesome Web designer and/or developer.

I’m already dogfooding rScript right now on the Restive.js website (http://www.restivejs.com). Not only is the website both responsive and mobile-friendly, it aces Google Pagespeed Insights with a perfect 100, and it has a [first-view] Speed Index of less than 1000 on Webpagetest; when measured with cable internet. A large part of this performance enhancement is attributable directly to rScript.

rScript was built to be a designer-friendly toolkit for modern Web design, and should be a great utility for helping Web designers and developers of all skill levels to build mobile-friendly, fast, and intelligent websites.

Finally…

I hate complexity. One of my icons — Bruce Lee — was quoted as saying “Simplicity is the key to brilliance”. I couldn’t agree more. Things should get progressively simpler to do with the passage of time. Web design seems to have bucked that trend and is now so much more complicated than it should be. Restive.js was my small way of making life a little easier for Web designers/developers, and rScript is the evolution of that effort.

So if CSS Media Queries are getting you bogged down, you might want to take a closer look at Restive.js [and rScript too when it does come out]. It’s a toolkit, not a framework, so it’s not going to make you change anything about your workflow; it’ll just make your CSS much more powerful.

It’s a bit sad for me to see Restive.js go [or stop being actively developed as the case may be], but I’m really looking forward to this new chapter with rScript. If you’ve used restive.js, I’d appreciate your feedback on your experience so far. And if not, I’m very happy to hear about the challenges you’re currently facing in Web design so rScript can evolve to solve these problems. Please let us know in the comments.

Thanks a lot for reading. Feel free to recommend and share.

This post originally appeared on the Restive Blog.