A Brief History of the Modern Web

So glad I decided to take up this opportunity of talking to some really amazing folks from the Coimbatore Frontend Meetup group.

In an attempt to take a completely informal session, I ended up delivering the entire talk without any slides/presentation.

The talk was a narrative around the start of the “internet” covering ARPAnet, CERN, the first website’s launch and growth to hundreds of websites & 14+ million users within 3 years of its launch – spawning the launch of a nerdy-looking portal – Yahoo!

Thankful to everyone who attended the talk and submitted their valuable feedback. It helps me grow as a speaker and learn something new every time.
I was anxious on my overall delivery of the talk, here is the feedback I received from the group: 100% attendees said they found it either "relevant" or "very relevant". Overall rating for the session was at 4.5/5.

Adding a few excerpts from the talk here – most of this is from memory, so please take with a pinch of salt…

We discussed the launch of the first web browser and the spin-offs it triggered including Netscape Navigator & IE 1.

Microsoft’s tryst with JScript and the internet’s demand for interactivity on the client side.

The history turned out to be magnificent and no less than a thriller unto itself. I learned a lot about the origins and evolution of a lot of tech giants – including Amazon, Netflix, Wikipedia, PayPal & more.

Two of the lead characters in my view, were:

  1. Tim Berners Lee – who created HTML, HTTP and pushed for the launch of the first website ever. He also worked on the first web browser – “WorldWideWeb”. This doubled as the first WYSIWYG style HTML editor as well.
  2. Marc Andreessen – A developer who had worked on Mosiac, another browser which was trying to build a better and faster browsing experience. Marc had worked in a part time role on the development of Mosiac but decided to setup his own company and created Mosaic Communications Corporation which had to then rename itself to Netscape Communications Corporation.
    They created the browser Netscape Navigator which helped millions of users navigate the internet for the first time. It was also the first browser to work across all popular operating systems including Unix, Classic MacOS & Windows.
    P.S. the internal codename for their browser was Mozilla, which stood for Mosiac Killer.

This talk deserves to be put out as a blog-post series in itself, look forward to more posts detailing some amazing facts from the history of the modern web. 🙂

It’s time we applied “separations of concerns” to frontend engineering!

Is it okay to require pixel perfect, accessible, high-performance frontend developers, with a progressive enhancement-oriented mindset and a knack for code modularity? YES.

Should every FE developer be doing all of the above every day in parallel? Probably not.

I’d use the analogy of “jack of all trades, king of none” for those who do all the above every day. I know because I did that in my early frontend years. Instead, now, I try solving one problem at a time.

e.g., pixel perfection has to be solved by a UI Framework, not unlike Bootstrap or Grids. Having such a framework ensures your UI widgets are in order and work cohesively across devices, form factors and are pixel aligned to your vision. UI Frameworks have been proven to increase frontend team productivity by a lot.

Not having to eventually worry about the above while developing features means you’re focussing on the business logic and not “if/when/how/why” your info component will work with your accordion.

Here are ways to ensure you’re focussing on one problem at a time:

  1. Pixel Perfection: Let the UI Component library layer ensure pixel perfection for design. Sometimes this means saying “NO” to design asks which violate the already defined design system for your org. If there must be an exception, get your design guidelines updated and build support for these requirements into the framework layer. Over time, Design will consistently adhere to the guidelines.
  2. Accessibility – is an interesting area. Mostly neglected, but more often, not implemented properly. While most developers take the web for granted, we often miss out on people with disabilities. Disabilities do not only entail physical deformities, but it could also be something as minor as colour blindness which requires Design to choose accessible contrast ratios. One would go deeper to ensure screen readers are able to properly identify and read associated metadata, in the correct order. Not many web development teams focus on this aspect in-depth, but those who do, are often blessed by search engines over the competition.
    This layer is handled by the UI component library development too, but ideally done a stage after the initial set of UI widgets are available.
  3. Performance: One would argue that every piece of code we write should be performant, so how would one separate this concern. I’d like to point out that the basic responsibility of ensuring common best practices are ensured is on the developer at all times, but advanced performance techniques like debouncing where applicable, memoising, caching etc needs to be thought through two times – once before any coding begins, laying out the approach, and later when the code goes to review. Pull Request driven git workflows allow teams to critically evaluate every piece of code that gets shipped eventually. This layer has to ensure that the code is performant.
  4. Progressive Enhancement: occasionally thought through at the end, this technique lets end users get a pleasant experience of using your web/mobile applications by reducing waiting times, download sizes and reducing overall internet congestion. Everybody loves a quick time-to-render timeline, most just never devote enough development cycles to ensure it is ensured regularly.
  5. Code Modularity: My recommendation to frontend development teams in almost every industry is to take a couple of dev-days dedicated to revisiting code written over the past few sprints across platforms (web/mobile) – try and figure out what can be reused, move it around to shared states. This is a hat we wear while writing any new code, to ensure code repetition is kept to the minimum.

Think about the above. If you’re asked to continuously write new features back to back. Could you do enough justice to every aspect listed above while ensuring timely delivery?

As a Web Engineering Team Leader at various companies – small and large, I’ve had to dedicate enough time for the above cycles to ensure new Frontend developers understand the importance of the various activities.

Depending upon the size of your org you might want to try one of the following:

  1. Have rotating responsibilities between the various FE devs in the team on a regular basis.
  2. Have dedicated sprints for the above when everyone focuses on one of the above topics for a week or two.
  3. For micro teams, let the developers focus on one thing at a time, it is okay to be building UI components for a sprint and not deliver a feature during that time – especially if it means future deliveries are going to be more dependable.

Do you agree? How does your team currently handle all of the above?

Weekends are for learning!

Every once in a while I share a weekend post of me at a cafe with my MacBook.

More often than not, people message me asking how come I’m working over the weekend, how am I happy living a life which makes me code/study/work over weekends.

Well, let me answer that question today: I love to explore.

Exploration, for me, is not just about “wanderlust-ing” around the world trying to see different places. For me, it includes being able to understand and digest the amazing nature of things. It means I take pleasure in reading stories by/of people from various fields of trade — aeronautical, mechanical, civil, aviation, photography, writing, acting and many more.

I cannot fathom being able to do all of what they do every day in my single lifetime. Reading up on these stories lets me see the world with a new pair of eyes, lets me understand how others see the things around us.

All that is cool, you say. Who does not like to stay updated or increase their knowledge you say. But why does Sunny code over weekends? Does he not have a life?

Well, when you see me code over a weekend — wait for a moment before you assume that I’m living the life of slavery tied to a computer. I choose to code/study/write/explore over the weekends because it helps me get up to speed with technology. Stuff that I “should” know, stuff that I could otherwise have learnt on the job eventually, albeit a couple of years down the line.

More importantly, it helps me get closer to the truth that there is more than enough on this planet than I can even imagine, let alone understand.

This inquisitive nature was what helped me get started with programming in the first place (back in my early teens). It is this mindset that helped me become a better version of myself than I had envisioned myself to be 5 years ago.

It is surprising how most of us are whiling away our lives trying to impress that one person, trying to forget that one individual, trying to curse ourselves for not having done A instead of B. And I will not say that I’ve not had to experience these feelings in my life, but I’ve made it a priority to be able to focus on myself once in a while.

This post is not about me, it is about you. Remember, you are free to explore your weekends too. Sure, catch a movie or TV show once in a while. Go fall in love, cry over a heart-break, relish your family time. I myself spend crazy hours binge-watching Amazon Prime or driving the outskirts of my city late nights. But that should not detract the value of dedicating sufficient growth hours per week for oneself!

Assuming the average human life span to be 75 years you get approximately 28,000 days. Not sure about you, but this translates to 3900 weekends of which I’ve run out of almost 40%.

I’m sure many of you might understand the value of what we just discussed, but don’t stow it away just yet. Give it a try. Be a part of this movement, take a step closer to being a better version of yourself. Towards being an individual who is better than who she was yesterday.

Take a step closer to #investyourweekends.

If you enjoyed this article, please help out your friends with a 👏 or a share.💥BOOM! It fuels my focus to write more of it, thanks!

I am a Frontend Specialist / Product Guy in tech. I believe in building intelligent products, focusing on my end-users and creating memorable user experiences. Connect with me on LinkedIn or say hi on Twitter.

This blog was originally posted on My Medium account: https://medium.com/@sunnykgupta/weekends-are-for-learning-6bb7a61832ca


Approaching a Hackathon

Are you prepping up to participate in a hackathon?
Looking for tips to optimise your time and energy over the duration?

Here are a few things to keep in mind before you go in on day 1.

Hackathons these days (nights) are high packed with energy and enthusiasm. While the focus on fun is certainly great, don’t assume it to be just a picnic.

Most of the hackathons I’ve won involved working on a problem statement that the company had for a long time, but never a P0 issue. Your idea does not necessarily have to be a tech feature for the product. Think about the problems in the HR dept, an improvement to the hiring process, reducing overall carbon footprint? Bring out the engineer/designer in you – forget about the box.

If you do end up choosing a tech product – try breaking it into the set of features you need to implement. Prioritise your sub-features. It’s better to be able to demonstrate the end to end idea rather than have only the first part working.

Prepare for the hackathon early on. Think about the problems you can anticipate, this leaves room for unanticipated problems (trust me, there will be many).

Work on the presentation from the 0th hour.

Most teams which have done brilliant projects fail to showcase them owing to an improper presentation or lack of rehearsal.

The presentation/demo is one of the most (if not the most) important factors in deciding the winning teams. Tailor your MVP/Development around the narrative of the demo.

You might want to skip/abstract out the parts of the project which are not a focus area in the demo.

Lastly, remember that the real success of your project will be when you take it to fruition. Follow up with the org to try and create a plan around taking this idea to production. (albeit behind a flag). Keeping this in mind will help you write sane code.

P.S – do not rm -rf the project folder after you win *wink* *wink*

Go ahead hack on!


Currying in JS.

I would define currying as invoking a function with fewer arguments than the function expects. This returns a new function that can be called with the remaining arguments. You could also invoke it with lower than remaining arguments and it would return yet another function.

Sounds confusing? Let’s look at the expected behaviour of our curry function:

const add = (a,b,c,d)=>{return a+b+c+d}

let add2 = curry(add,2);
//Here add2 is the curried function. We can use it like:

add2(3,4,5) //results in 14 (2+3+4+5)
add2(3,4)(5) //Same result
add2(3)(4)(5) //Same result

//This works too -
const add2_3 = add2(3)
//The above will now accept two more arguments.

add2_3(4,5) //results in 14 too.

How would you go about implementing this?

Thoughts on scalable UI in the world of JSX, SASS, React, Styled Components and the likes.

Those of you who read my blogs regularly, already know that I have been coding for the better part of the past decade.

A fair bit of that time has gone into building beautiful and usable UI components for projects built for scale. (e.g. Fab, Hem, Tavisca)

So it was not a surprise for me when I saw that RoR community came up with SASS a preprocessor for CSS which allowed you to dynamically create your style-sheets. Eventually, developers could use functions (mixins, extend, import), variables, nesting and create UI components in a much elegant fashion.

All was well, the UI developers were still writing their styles in a separate file which would compile down to CSS and be included into the HTML as required.

But eventually, with Angular and React, users started writing their styles in the HTML directly. It felt natural to new developers who liked keeping their HTML/JS for a component in a single JSX file. They had no qualms about using CSS in the style attributes of their DOM nodes.

Even though in my opinion (please note the term ‘Opinion’) inline-styles pollute the DOM and get in the way of development.

Also, keeping styles for each component in its own JSX makes it difficult to use the power of SASS and visualize the entire hierarchy that we get by looking at a SASS file (if done properly.)

Enter, styled-components which lets you write CSS as JSON objects and auto assigns a unique class name to every component. It also auto links the class to every instance of the component.

What I dislike about this approach is the fact that we are adding inline-style nodes and the browser has to generate the same class during every execution of the app/page. This does not play well with the fact that browsers can easily create the class, pre-process its properties and cache it for future use across reloads.

What are your takes?

Atlassian’s HipChat user data breached.

This morning I received an e-mail on my HipChat linked account.

According to Atlassian, they have detected an incident that may have resulted in unauthorized access to my user account information which very well includes the username, email address and hashed password.

They go ahead to mention that there is no evidence for other Atlassian products having been breached. They also claim that they did not detect any unauthorized access to financial data.

While Atlassian may have already deleted your password to force a reset, my recommendation is to change your password across other websites if you happen to re-use your password.

I invest with Goalwise. Here is why.

Last week I was discussing with my bunch of close connections about a new investment platform Goalwise. The most common question was what does Goalwise do and how could it help them. (questions like Why Goalwise or Why not a competitor)

In this post I try to explain in brief what Goalwise does and how it does it better than it’s competitors. Continue reading I invest with Goalwise. Here is why.

JavaScript and “First-class functions”.

js-minJavaScript is one of the languages which claim to feature “First Class Functions”. So, what does it mean to be first class function? Let’s explore.

I like to compare it to being a first class citizen. Basically the right to freely move across boundaries in the country without being questioned of your purpose.

In the programming context, being first-class, gives JavaScript functions the ability to be saved in variables, passed around as arguments or even returned from other functions. Taking this a step further, functions can reside inside objects as one of the properties. Continue reading JavaScript and “First-class functions”.