On frameworks and libraries in Software Development

I woke up this morning with a link to something interesting trending on HackerNews. One of my mentors, Karthik Nandyal, had forwarded it to me.

I also happened to log on to Scaler, a platform where I mentor software developers and saw a bunch of questions from mentees around how to choose the best framework, which one should they be learning etc.

Both of the above got my thoughts racing. We’re in an information overload era and new developers are assuming that they need to master the frameworks to excel at their jobs. (software development)

Let’s look at the triggers in depth:

A lot of the above resonates with my long-term thinking of focusing on underlying languages over fancy new frameworks.

For those who don’t know: Hey.com is a brand new privacy conscious email provider with slick UI and an interesting take on emails and SPAMs. They have gained a lot of traction because of the founder’s previous successes. These guys built the RoR stack. The same framework that eventually powers the backend of platforms like Scaler and InterviewBit. They also built BaseCamp – a really popular Project Management tool.

New developers put too much thought in choosing a framework and comparing apples to oranges. It is worthwhile to “build something”. Most modern frameworks and libraries will let you achieve that goal.

React was miles ahead in architectural thought process when it launched. But today, you could build anything using either Angular or React, or as is in the case of Hey, simpler frameworks like Turbolinks & StimulusJS.

Hey.com stepped aside from the fancy architectures and ended up creating their entire app as a Majestic Monolith – another great read.

If you are a new developer looking to decide on a framework or library then depending upon your aim, you could:

  1. Looking for a job: Identify popular frameworks – build a side project using that. Try and read up on advanced concepts in that framework. Hit StackOverflow questions for the topic and try to see if you understand the day-to-day problems most developers face.
  2. Just want to explore: Pick a framework, any framework/library. Build something. Publish on your GitHub. Pick another, repeat… at the end of it, you’d have learned how to build various things using multiple tools/platforms. This is what a true polyglot developer feels like. They might have hands on knowledge of multiple tools and be experts in only a few.
  3. If the aim is theoretical knowledge by discussion only – you’re doing something terribly wrong. Either do “1” or “2” above and you’d have a good chance at getting yourself a seat at the table.

Remember, the table is large enough to accommodate everyone. Just that, only a few developers actually put in the hard work. No amount of reading about frameworks will teach you anything about the practical aspects of actually building real things.

Knowing a framework in depth, will allow you to talk to other framework folks and work upon your opinion. Having wide knowledge about many frameworks will let you have meaningful conversations with those who have in-depth understanding. It is never a black and white world. There are shades of grey associated with every framework. Work upon your opinions, be malleable at certain temperatures.

If you do not build, you’re just a blank canvas – anyone can throw some paint and change the colour. I’d call that technological-brainwashing.

Thoughts?

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!

2wh52w

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)
//or
add2(3,4)(5) //Same result
//or
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.

Origins of JavaScript, or ECMAscript.

ECMAScript (or JavaScript), legend has it, was built in 10 days flat. In the year 1995 when I was 5 years old, Brendan Eich had been tasked with developing a scripting language for the Netscape browser.

Eich took parts of Scheme (first-class functions) and Self (prototypal inheritance) and made the syntax “look-like” that of Java. (of course he did a lot more than just that.)

The language was made for amateur scripters who wrote simple code for client-side execution. Not many had predicted that the language would become a popular choice for building dynamic websites, server side frameworks, databases and even powering drones.

Today, JavaScript is a single-threaded, non-blocking, asynchronous, concurrent language. It features a call-stack, an event-loop, a callback queue and some other APIs. Node has a call-stack and a heap.

JavaScript programmers like to use words like, “event-loop”, “non-blocking”, “callback”, “asynchronous”, “single-threaded” and “concurrency”.

Let us go back in time and see the timeline for JavaScript:

After the initial release in 1997, the first major release came in 1999 called ECMAScript 3. Post which the language was stagnant for a long time. While there was a draft for ECMAScript 4, it was never released due to lack of consensus on the featureset.

During this time, libraries like jQuery helped JS stay sane by handling browser quirks and kinks. Creative users were trying to make beautiful animations and innovative hacks for various tricks. But performance was an issue. Then began the browser performance wars. In a bid to get a bigger market share, browser vendors started optimizing Javascript execution to make run faster.

This led to a dream-run for JavaScript performance. With the launch of V8 in 2008, JavaScript was 10 -1800 times faster than previous generation compilers. This gave the language a resurgence amongst web developers. Latest browsers like Google Chrome, could run client-side scripts at blazing fast speeds. Other vendors soon caught up with their own compilers which optimised code for execution. (JIT)

Developers started handing off non-business critical calculations like template rendering to the client, thereby improving server response times and reducing loads on backend servers. Websites were suddenly faster than ever.

Mr. Douglas Crockford evangelised the language to a big extent, his book “JavaScript – The Good Parts” has eventually become a must read for most beginners.

Crockford also contributed directly to the language, most notably his specification and implementation of JSON. Today, it is the most common data format used for asynchronous browser/server communication, largely replacing XML, and is used by AJAX. AJAX made it possible for single page applications to gain popularity.

In 2009 ES5 was launched with JSON support baked into the language itself. This version also added a ‘strict mode’ aimed at capturing silent errors. According to John Resig – “This strict context prevents certain actions from being taken and throws more exceptions.”

Eventually, Ryan Dahl, a talented developer picked the event-based, non-blocking, single threaded V8 engine, developed by Google, and made Node.js® which is a JavaScript runtime for server side programming. It is inherently lightweight and efficient for non-compute heavy tasks.

As Node started getting popular, a huge ecosystem of contributors started creating and maintaining libraries to host servers, manipulate images or even stream data. Thus npm was born, which today is the largest repository of open-sourced packages in the world.

But all this while, the language itself remained almost the same. ES5 (the most widely supported version of JavaScript currently in use) was standardised in 2009. Since then the “Ecma International, Technical Committee 39” has been working on introducing new features to the subsequent releases.

The committee has since 2015 decided to launch a version of the language every year in the format ES2015, ES2016, ES2017 and so on. Those features which cannot make to the current release get added to the next draft.

So today, JavaScript has a wide array of new features available, which cannot be used in production code since few browsers might not support them.

But, as is always the case, another bunch of geeks have come up with Babel which is a transpiler which can take in any version of JavaScript and emit ES5 which all modern browsers support.

I know we have covered a lot in this post. We would eventually dig deep into the basic fundamentals of the language and then eventually work our way till we know how to read new drafts and know what to expect from future versions of the language. We will also explore various libraries written for client-side (Backbone, Ember, React, Redux etc) as well as back-end execution (Express, Meteor, Kraken etc) and learn how to use a few of them to create modern fast applications which solve real-world problems.

Edits, Tips, Suggestions, Feedback? Please let me know in the comments below.