Let the App… Materialize!

materializecsslogoAfter I got the Google sign-in working well enough for my Rails practice web app, the first order of business was to build the basic skeleton. This was a great practice exercise to take the pieces I learned in the Ruby on Rails Tutorial sample app and build something of my own design.

The initial pass implemented basic functionality but it didn’t look very appealing. I had focused on the Rails server-side code and left the client-side code simple plain HTML that would have been state-of-the-art in… maybe 1992?

Let’s make it look like something that belongs in 2017.

The Rails tutorial sample app used Bootstrap to improve the appearance and functionality of the client-side interface. I decided to take this opportunity to learn something new instead of doing the same thing. Since I’m using Google Sign-In in this app, I decided to adopt Google’s design concepts to my client-side appearance as well.

Web being the web, I knew I wouldn’t have to start from scratch. I knew about Google’s own Material Lite and thought that would be a good candidate before I learned it had been retired in favor of its successor, Material Components for the web. One of the touted advantages was improved integration with different web platforms. Sadly Rails was not among the platforms with examples ready-to-go.

I looked around for an existing project to help Rails projects adapt Google’s design language, and that’s when I found Materialize: A library that shares many usage patterns with Bootstrap. The style sheets are even written using SASS, native to default Rails apps, making for easy integration. Somebody has done that work and published it as Ruby gem materialize-sass, so all I had to do was add a single line to use Materialize in my app.

Of course I still had to put in the effort to revise all the view files in my web app to pick up Materialize styling and features. That took a few days, and the reward for this effort is a practice web app which no longer look so amateurish.

Peek under the hood of Bootstrap

After completing Codecademy’s “Make a Website” lesson, I decided to go explore a side track to look under the hood of the Bootstrap framework used in the lesson. I’m not going to dive deep (yet), but I wanted to break it down into a short list of names I expect to encounter again as I explore.

The actual run-time components of Bootstrap appears to be two Cascading Style Sheet (CSS) files and one JavaScript (JS) file. One of the two CSS files is an optional theme. This confirms that Bootstrap has no client-side requirements, just a web browser that can understand standard CSS & JS files.

On the developer side, things get more interesting.

Grunt is the build system used by the Bootstrap project to build the project code, the documentation files, and run the unit tests.

It’s not clear if the JavaScript files are worked on directly, but the CSS is definitely not. It is done with Less and compiled to CSS. Some parts in the documentation listed “Less/Sass” implying Sass is a similar thing. Maybe look into this later.

Once the product is rebuilt, the JavaScript code is automatically reviewed by JSHint. Then tests are executed in the PhantomJS headless JavaScript runtime orchestrated by QUnit testing framework for JavaScript.

The product documentation pages were generated by Jekyall. Don’t know what the input for Jekyall would look like, but the output is static HTML pages. It claims to be the engine behind GitHub pages, so I know I’ll run into this again when I explore GitHub.

Several package managers were listed. Looks like NPM is required for actually working on Bootstrap itself, though it can also be used for projects consuming Bootstrap. Bower and Composer are two other package managers that seem to apply only to Bootstrap consumers.

That’s the first cut. Some things are still fuzzy, and some things I thought were clear may actually be wrong. We’ll see!

Codecademy “Make a Website” notes

I’ve just completed the “Make a Website” lesson on Codecademy, because it made sense to start at the beginning and (re)learn the fundamentals. I knew some simple HTML going in so I had expected part of it to be review and part of it to be new material.

The review part was expected: the lesson went over basic concepts of HTML tags and their hierarchical structure, then went into fine-tuning appearance via CSS.

But the new material was a surprise. After the CSS unit completed teaching about backgrounds and borders and spacing, it promised the next unit is about content and page layout. I thought “OK, good, now we’re getting into stuff I don’t know.”

The next unit began by introducing the Bootstrap framework to manage page layout. It was still an informative and fun interactive lesson, but I was left disappointed by the departure from HTML fundamentals.

It felt incomplete, like a math class that skipped doing addition with pencil and paper and instead going straight to using a calculator. Yeah, I’m probably not going to do it by hand ever again, but I wanted a lesson to teach me how to do it at least once. I would have preferred the lesson to go a bit into doing HTML layout the hard way, then say “Now that you know how to do it the hard way, let’s do it the easy way with Bootstrap.” Doing it both ways would give me a better feel of how HTML layout works and how Bootstrap makes it easier.

The Codecademy lesson worked as advertised, I’ll just have to fill this hole in my knowledge with something else.