Day 56 – Menu effects!

After creating a pretty static blog page, I wanted to learn how to create a slide in menu. I found this great demo of different menu transitions on codrops. What do you do when you have no clue where to start? You start by imitating. Don’t reinvent the wheel.

Initially I had a single menu div and applied a “starting position” class to it on effect button click. The trouble was, I had to set a small delay so that the starting and final position classes would not be applied at the same time by JavaScript. There would have to be a delay and transition when the classes were removed as well. (Or else the menu would just vanish instead of sliding back out). This was the first time I really used the transition property and I definitely struggled with setting up the code!

The more simple way was to just have a menu set up for every effect. Apply a css class to move that menu into the correct starting position (for example: for Slide in, you push the menu 100% of its width to the left). Then when the button is clicked, you add a class for the final position. The final position of the menu was always the same for my effects, right on the left of the screen. By adding transition timing to the classes, the menu would slide in from the left and then slide back out.


Once I had the setup figured out, creating different effects was much easier. I just had to create different classes for each of the effects: one menu closed class and one menu open position class for the main div if needed (for example if the menu pushes the main div to the right).

In this effect (Forward and back), the main div is scaled down when the menu is open.

I used JavaScript to open the effect button clicked, and then close the menu upon another click anywhere on the page. This ensures that two different effect menus are never shown at the same time.

This page was another one of those “this seems easy, why is it so frustrating” pages in the beginning but now I know how to create a slide in menu!

Day 56 – Menu Effects

Client-side Rendering Pros and Cons

This discussion came up at Trippeo about whether we should rewrite the web dashboard to use a modern framework. A few of the developers held differing opinions about whether switching to client-side rendering would be beneficial. I did not even understand what client-side rendering meant. I spent two days reading up on the topic. At one point I had over 15 tabs open in my browser! It can be a little overwhelming when one article leads to another and then every article has new terms you need to google. Although a lot of the information went over my head, I feel I have a better understanding of client-side rendering now.

Here is a summary of my notes:

Client-side rendering is when the client-side environment is used to run scripting. The source code is transferred from the web server to the user’s device and then run, typically in a browser.

Server-side rendering is when the web server runs the scripting language. The web server runs the script to create dynamic HTML pages which are then sent to the client’s browser.

PROS of Client-side Rendering (1, 2, 3, 4, 5, 6)

  • Faster navigation If data does not need to be loaded, clicks and interactions are much faster since the entire payload is loaded up front. “Last paint time” is much shorter.
  • Server performance Traffic and server load can be decreased. The server only needs to deliver static files and answer API calls with JSON. Server performance can be improved with good use of JSON and client-side caching.
  • Architecture The front end is almost completely decoupled from the backend. The framework needs knowledge of the REST API. The server needs to deliver static files (html,css, javascript) and pre-render screens when crawlers are present (less of an issue with Google starting to crawl JavaScript files). But, they do not need internal knowledge of the other and can be done on the same or completely different server. The browser becomes a consumer of the API, just like a iOS or android application. The backend and the frontend can be developed separately from one another.
  • Improved development speed No matter which approach (server side or client side rendering), html/css/JavaScript are required. With client side rendering, knowledge of server-side programming languages is not required. This makes the work of front-end developers(who don’t have backend skills) easier. The amount of code can be reduced and the need to recompile the backend code is eliminated. (Changes to the front end can be seen almost immediately)
  • Testability You can build out the entire view layer of your app without firing up a server. (Put your mock data in a JSON file.) This mock JSON can also be used for testing.

CONS of Client-side Rendering (1, 2, 3, 4, 5, 6)

  • Slower Initial Load The browser needs to do the extra work of manipulating the DOM elements, binding data and watch for changes, do additional REST requests to the server … etc. All the JavaScript files need to be loaded the first time the application is opened. This may be a problem for more complex applications. Initial experience can suffer. “First paint time” is much longer.
  • Unpredictable Performance The performance of your server is much more predictable than all the different user devices. Are your users going to be using your application on mobile devices? Slower connections? Old computers? It takes time to download, evaluate, and run the JavaScript before the user will see anything (Initial load time). This is not optimal for users who do not have the latest and newest and can cause a frustrating initial user experience. (This concern depends on your user demographic.)
  • Compatibility with older browsers If you care about legacy browsers, with the biggest concern being Internet Explorer(<IE8), alternative pages will need to be served. This takes additional development time. What about environments where JavaScript is disabled? (Some screen readers, users who have JavaScript turned off.. etc.)
  • Search Engine Optimization Pages have to be pre-rendered on the server for crawlers and indexing. The good news it that Google has started to crawl and index sites in JavaScript so this is becoming less of a concern.
  • Maintainability While the ideal scenario leads to a clean separation of concerns, application logic and view logic may end up duplicated between client and server in different languages. Examples of this could be date formatting, currency formatting and form validations. This makes maintenance of complex apps difficult.

Question: Does there have to be a tradeoff?

Why not render the initial state of the page on the server, and then re-render the parts that need to be updated on the client? Biggest reason: server-side rendering and client-side rendering typically isn’t mixed because they are written in different languages.

! important (which is actually important)

Today I spent some time removing inline css styles for the Trippeo dashboard. It was the first time I had really looked at the !important declaration. I had glimpsed it here and there and naively thought it was similar to a comment, as in “important color, do not edit without careful consideration”… but it is actually like a magic veto power! And…”narcissistic” according to CSS-tricks. To “respect the devs to come” per the article, I set about getting rid of these !important declarations.

I had thought the id selector was the most specific but moving these styles into the css files did not work. The default style was not being overwritten. Hmm. Why were these default styles with class attributes overriding the id attributes? (And apparently selecting by id is not good practice either, oh no!) Time to look at css specificity. Different selectors have varying weights that are calculated? Whoa.

I won the specificity wars by adding more selectors and successfully removed the !important declarations. My new question was, how do you avoid specificity wars as you add more elements to an increasingly large project? Google told me css specificity should be irrelevant if you are following object oriented css principles. Looking up css best practices brought me to Sass and Less. And then I saw lines of code like “@rowstyle” that brought in css styles from I’m not sure where and if {} else {} statements in the html…

Sometimes I feel like….
redpillHow deep does the rabbit hole go?