DEV Community: Bytegasm!

15 CSS Relative units, how many do you know? em, rem, ex, cap, ch, ic...

Bytegasm! — Sat, 18 Aug 2018 13:05:47 +0000

If you are reading this, I'm pretty sure you know at least 5 ways of centring HTML elements using CSS. So, 15 options for relative sizing shouldn't come as a surprise to you. Let me tell you, some of them are bizarre.

The story

I saw this tweet by JavaScript Teacher, I only knew 5–7 of these properties and it gave me a massive FOMO attack. So, I decided to write this article and save your from the FOMO.

// Detect dark theme var iframe = document.getElementById('tweet-1029722982774697985-289'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1029722982774697985&theme=dark" }

What are relative units & why do we need 'em?

Have you ever wondered that none of the screens you own have the same sizes & dimensions? But they all do display webpages. So the webpages need to be styled in a way that adapts in relative proportions to the display (or any other HTML element).

In short, making such responsive, adaptive layouts gracefully possible.

1. the unpredicatble em

Relative to the font-size of the current element (2em means twice the current font-size). A length property dependent on font-size, yep how magical.

.post {   
   font-size: 24px;
   border-left: 0.25em solid #4a90e2;
}

/* The border-left-width will compute to 6px. */

Working with em can get tricky as it gets it's value relatively from its parent element. In case of nested elements, it gets messy when the parent has em value too.

2. the savior rem (root em)

Just like em but relative to the font size of the root element of the document.

p {
    margin-left: 1rem;
}

h4 {
    font-size: 2rem;
}

/* Unlike the em, which may be different for each element, the rem is constant throughout the document */

For this technique, it is fundamental to set your base font-size, by browser default usually this is 16px.

3,4. vh and vw

Unlike em and rem which are dependent on font size vh & vw are dependent on the size of the viewport.

1vh = 1% or 1/100th of viewport height
1vw = 1% or 1/100th of viewport width

You may have seen some sites with typography that scales beautifully as you resize your browser window, vw & vh make it happen.

5,6. vmax & vmin

Viewport max and viewport min: 1vw or 1vh, whichever is bigger or smaller respectively.

1vmax = 1% or 1/100th of the bigger value between 1vw or 1vh
1vmin = 1% or 1/100th of the smaller value between 1vw or 1vh

7. Good'ol %

Quite popular, everyone's friend & fairly obvious % is relative to it's parent element.

.post {
  font-size: 24px;
}
.post-category {   
  font-size: 85%; 
} 
.post-title {   
  font-size: 135%; 
}
/*      
Child elements with % font sizes...      

  85%     
  0.85 * 24 = 20.4 px        
  135%     
  1.35 * 24 = 32.4 px
*/

Now let's dig into some obscure and relatively unknown ones.

8,9. Experimental vi & vb

The are experimental APIs not meant to be used in production as there .isn't any browser support.

1vb = 1% of the size of the initial containing block, in the direction of root element's block axis.
1vh = 1% of the size of the initial containing block, in the direction of root element's inline axis.

They aren't very popular or supported as they are quite new, you can dig more about them in CSS Value and Units Module Level 4.

10,11. lh & rlh

They're like em & rem but instead of font-size they depend on line-height.

lh = Equal to the computed value of the line-height property of the element on which it is used.
rlh = Equal to the computed value of the line-height property on the root element.

12. ex

The **ex** unit is rarely used. Its purpose is to express sizes that must be related to the x-height of a font. The x-height is, roughly, the height of lowercase letters such as a, c, m, or o.

13. cap

It's the measure of the so called cap-height. The spec defines cap-height as approximately equal to the **height of a capital Latin letter.

14. ch

Represents the **width of character 0, or more precisely the advance measure of the glyph "0" (zero, the Unicode character U+0030) in the element's font.

15. 'ic' ideograph count

ic is the Eastern equivalent of ch mentioned above. It is the size of the CJK (Chinese/Japanese/Korean) ideograph *水* ("water", U+6C34), so it can be roughly interpreted as "ideograph count".

Some of these are pretty strange and uncommon but I'm pretty sure each one of them have their own use-cases and reasons to exist. What are your favourite ones?

Fusion.js Universal Web Framework by UBER opensourced

Bytegasm! — Thu, 02 Aug 2018 12:12:23 +0000

If you are reading this, you already know that there is a new 'framework' in town. This may sound like everyday news in the Javascript world, but before you roll your eyes and go on a twitter rant, let's see what all the FUSSion is about.

React, Angular, Vue and now Fusion?

NO! Fusion.js is not a replacement for React. To be precise Fusion.js is feature-rich-boilerplate built on top of react & redux which tries to ease major pain points of modern Single Page Web Appications.

It's been few hours since the launch of fusion.js so this is not a deep dive but a brief summary & first impressions on Fusion.js.

Server Side Rendering out of the box

SSR-ing your SPA has always been a bit tricky. There are various boilerplates that provide you setups to render your app on the server and hydrate it on the client. But these setups are quite opinionated and are deserted after some time, leaving you on your own. Fusion.js supports server-side-rendering right out of the box. Which means, isomorphic universal webapps which render on server and hydrate in the browser and SEO friendly pages which load faster.

Code Splitting & HMR right away

Bundle splitting on an SSRed react-redux SPA has always been a front-end developer's wet dream. But configuring webpack for it and getting it to work as intended in all major browsers has been a nightmare. Also, Hot Module reloading is a blessing for devs, right? Both supported out of the box in Fusion.js.

Plugin Based Architecture

A single entry point architecture enables Fusion.js to run it's code universally on the client as well as on the server. Thus also enabling plugins to be universal too. It allows plugin developers to co-locate snippets of code based on the library the code pertains to, as opposed to the environment the code runs in.

This can be better understood by this graphic:

plugins logic based on their logical grouping rather than based on where the code needs to be added.

Typed dependency injection

Plugins can expose well-defined APIs as services to other plugins, and a plugin's dependencies can easily be mocked during tests. This is especially important when dependencies are responsible for communicating with data storage infrastructure or when they relate to observability (e.g., logging, analytics, and metrics).

No more Express, welcome Koa

Most of the SSR, code-splitting solutions out there are based on Express. Express has an API that encourages side effects which made complex response transformations difficult to encapsulate and test. Fusion.js however is based on Koa, which provides a more unit-test friendly context-based API, and an elegant and lightweight abstraction for request lifetime management based on the concept of downstreams and upstreams. Fusion.js core segregates network side effects from application state and leverages Koa and DI to achieve loose coupling between subsystems.

Test by your Taste

Fusion.js support modern test tooling such as Jest, Enzyme & Puppeteer. Apart from these, it also provides tools to test plugins. The fusion-test-utils package allows mocking the server itself, making it possible to quickly run integration tests between any permutation of plugins and mocks.

What about styling?

It's possible to use any CSS framework or library with Fusion.js. By default Fusion comes with support of Styletron, a high performance atomic CSS library that is maintained by the Fusion.js team.

Component based routing

Fusion apps can use the fusion-plugin-react-router to integrate routing features into the component tree. The plugin uses react-router under the hood, and exposes a similar API which allows you to add routing behavior anywhere in your component tree.

Other Goodies

Security: automatically setup CSRF protection on endpoints.
Data fetching: supports RPC-driven composable data fetching and GraphQL/Apollo
Quality metrics: easily consume server performance and browser performance logging, error logging and generic event streams
I18N: Automatically set up efficient bundle-splitting-aware translation loading

My 2 cents:

Open source projects from big companies always warm my heart. Being a front-end developer setting up SSRed, code-splitting setup on react, redux & express was one of the hardest challenges I've faced. So, seeing such setup open sourced which is also used on a large scale by Uber is really nice.

Talking about Open Source, dev.to is going Open Source on 8/8/18. Yay!

We already have amazing modern web setups like Next.js, Gatsby, Electrode , the more the merrier. I can't wait to use Fusion's in my next project and find out how it plays out. What do you think about Fusion.js?

Exciting year to be a web developer

Bytegasm! — Fri, 19 Jan 2018 17:21:09 +0000

Exciting year to be a web developer.

Welcome to 2018, where websites are the new rage. Mind you, we call them webapps and not websites anymore. Every developer is in the race to deliver the fastest first byte. Forbes new mobile site renders in 2.5 seconds, BookMyShow’s web conversion rates up by 80% and OLX has seen 250% more re-engagement on their website. What’s going on in this world wide web? With scary Javascript-CPU-profiler graphs that look like cardiograms of the lochness monster, all is being done to optimize every little bit we send down the wire. With google leading the bandwagon, all devs are set on the path to make the web great again. Oh, did I tell you websites can send notifications? And yes, offline websites are a thing now.

App craze of 201X

Let’s go back to 2010, the rise of the smartphone pandemic. Thanks to iPhones & cheap android phones, you could find every second person using a smartphone. Every second guy was shooting angry birds or being a fruit ninja, whatsapp was becoming the goto communication channel and people were actually paying to download an app. All of a sudden every company wanted to have an app. But why?

Offline access: Since apps are download-once-use-forever, once downloaded a user can access them just on tap.
Re-targeting by notifications: You can make your users come back to the app by sending them notifications, relevant product information to capture their attention.
Native features: A native app has compatibility with a devices’ hardware and features like camera, location, sensors, file system etc.
Better performance: Since apps have access to device hardware and they have freedom of design, apps are supposed have a better performance and speed.

The problem with mobile apps

Low new app downloads: Majority of smartphone users do not download new apps. Consumers spend 80% of their time on these 5 apps. Top 10 heavily used apps are owned by facebook & google.

Barrier to entry: Getting a user to download an app, spend time and data for the download and then getting to use it is a big barrier in app acquisition.
Apps are storage intensive: With most iphones users running out of space frequently and cheap android phones with low storage capabilities, downloading and keeping an app is a tough choice for a lot of users in developing countries.

Where web wins:

The world wide web has been the go-to source for our information consumption since the advent of internet. Let us check out why web still exists and wins:

Discoverability: You search something on google and bam! you’ve a list of websites you never knew existed. Its easy for you to discover new content on web and the websites to be discovered.
Broader Reach And Instant Access: From low-end feature phones to shiny iphones, each one of them has a browser in it. Hit a URL and voila, you’ve the content to you in a matter of seconds irrespective of the device config.
Shareability: Even when native apps need to share something over the web they need a web URL. URLs are the best way to point someone to a source.
Development: A website doesn’t need to be developed differently for every other OS or device. Its awrite-once-run-everywhere thing.
Updates & maintenance: You can update your webapp multiple times a day but updating an app frequently? Boy your users are going to be so pissed.

// Detect dark theme var iframe = document.getElementById('tweet-784795446472544256-289'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=784795446472544256&theme=dark" }
--Relatable?

The Solution? Progressive Web Apps :

What if you marry all the goodness of the web with features that native apps provide? You get progressive web apps. Let’s see what all Progressive Webapps can do.

Installable: With just a tap, your website gets installed in the phone and added to the homescreen just like a native app.
Notification goodness: You can send push notifications, just like native apps can.
Offline: Using offline cache APIs your installed webapp can function offline as well.
Updates are a bliss: You just update the website on your server and the app cache will gracefully update itself without the user noticing. As many updates as you want without the user noticing it.
Progressive: Though the support for PWA is increasing rapidly, there may be some browser not supporting all the APIs. In such cases your PWA will function just like any other website. So, no more support issues. Support everything.

What the future holds:

It is clear that the next generation of webapps a.k.a Progressive Webapps are going to be an obvious standard in a few years. With growing browser support and user education users will expect websites to be PWAs. These are the exciting things coming up in PWAs :

Install PWAs on your computer from windows store. Microsoft has promised to bring PWAs to edge and then PWAs can be added to the windows store which users can download on their computers. Isn’t that terrific?
Firefox for android, adds support for progressive web apps.
Apple added support for service workers in Safari Tech preview. ( Good things coming )
Tinder launched its PWA. So did Twitter, Uber, Pinterest, Google Maps and many other big players. Also, you are reading this on a blazing fast PWA right now, try adding it to the homescreen. ;)