No matter whether you are a decision-maker, a junior dev, a recruiter or a project manager, our industry has created a plethora of buzzwords and deemed them industry standards on different levels.
This article will tackle some of the more prominent Marketing/CV Buzzwords in an attempt to explain them just deep enough to grasp the core idea for more educated decisions in the future.
At the end of the article, I will also include a link list for the different topics of this article.
JavaScript Versions
ECMAScript, JavaScript, ES5, ES6, ES2015, ES.Next…
Sounds weird, right?
The naming convention for JavaScript versions leaves room for improvement, I grant you that. JavaScript was released in 1995 as part of Netscape Navigator, labelled as LiveScript. A year later, it was renamed JavaScript in a (not so) clever marketing attempt, despite having nothing to do with Java in any way. Later that year, JavaScript was submitted to ECMA International and re-labelled again.
Today, JavaScript is the accepted name of the programming language while ECMA versions are mostly used to differentiate between versions. Well, after being nearly stagnant for 15 years…
JavaScript runs in (almost) every browser which means that browser vendors need to update their own implementation to match new ECMA versions, leading devs to track support for new features and to wait for browser vendors to follow new developments.
Tools like the pre-compiler Babel allows developers to use newer features by transpiling new code features into older and cross-browser compatible alternatives.
Here's a quick rundown of the most important versions:
- ECMAScript 3 (ES3) | This version is what most people had accepted as plain or vanilla JavaScript for many years and was released in 1999.
- ECMAScript 5 (ES5) | The 5th edition of ECMAScript, standardised in 2009, was the first big step for developers and the beginning of the separation of JavaScript developers into those that know the new features and those who don't. This was a top interview question for a long time.
- ECMAScript 6 (ES6)/ ECMAScript 2015 (ES2015)
- ECMAScript 7 (ES7)/ ECMAScript 2016 (ES2016)
- ECMAScript 8 (ES8)/ ECMAScript 2017 (ES2017)
- ECMAScript 9 (ES9)/ ECMAScript 2018 (ES2018)
- …
As you can see, starting with 2015 a more regular and streamlined pace was established. By far the biggest and most popular step was going to ES5 and while more recent versions also come with increasingly modern and amazing features, they pale in terms of popularity impact compared to ES5.
The whole process is rounded up by a proposal stage for new features not yet standardised and officially released. This is nice for playing around and all that but it is not.
Where is this relevant?
Basically everywhere: frontend, backend, web, mobile, maybe even your next office coffee maker… To say it with the famous words of Jeff Atwood:
"Any app that can be written in JavaScript, will eventually be written in JavaScript."
Typescript (TS)
Javascript has long been criticised by many for its many quirks, lazy (loose) typing and other shortcomings. There have been famous (and funny) talks and presentations about this (search for Gary Bernhardt's "Wat" talk, if you want to get an idea). Long story short, JavaScript runs almost everywhere and by now you can build almost anything in JavaScript. Wouldn't it be great to fix that?
Well, as JavaScript already runs everywhere, you can not simply update it to remove these quirks and issues. So this is where Typescript comes in.
Typescript is basically an abstraction layer, a superset of JavaScript, that comes with its own pre-compiler and allows the programmer to write cleaner and strongly typed typescript code that will be compiled into regular but better JavaScript code.
And to make things easier to migrate old code, all JavaScript is basically valid typescript, just without the new tools and advantages so transitioning old applications into a new typescript form can happen line by line or file by file.
So what are the advantages of Typescript?
- We can define types and interfaces for our variables, objects and functions.
- We gain inheritance and composition for types and interfaces.
- We receive instant feedback (in supporting IDEs) about type conflicts when calling a function, using a variable or receiving an output.
- Typescript helps your IDE to give you more information and assistance with your code.
- We get some basic assistance during refactoring, as types and interfaces give us more confidence in our code.
- Typed code (with readable variable names) already offers a basic form of in-code documentation without a single line of comments.
- A certain amount of bugs can be caught earlier.
What will Typescript not solve/offer?
- Typescript will not catch all bugs in your code, especially when working with 3rd party APIs.
- I often hear that Typescript will reduce bugs by 60% but to get this high of an improvement, the code must have been pretty bad even for regular JavaScript levels.
- Typescript is an extra abstraction for your code. While some programmers swear by it, a new hire might not be able to work on your codebase if they lack Typescript Know-How.
- Depending on your code-base, some edge cases might be hard to map with correct types/interfaces, leading to longer development time.
Before we move on, I'd like to quickly point out that from my experience, the last point on that "CON" list is often (not always) a sign of code smell, something that hints at "magic code" or stuff that is written either too complex or too clever to be good, stable and maintainable code.
This also brings us to one of my personal favourites about Typescript: it nudges us towards thinking more about the code we write, before we write it, not unlike TDD. When working with separate teams for Backend/API and Frontend code, predefining API contracts with Typescript allows us to mock data and work independently based on the formed API contract between both teams.
Where is this relevant?
Anywhere where JavaScript runs: In a browser, on Node.js or Deno and in your apps. Especially for DevOps and Backend developers writing Node.js code and coming from more object-oriented languages, Typescript can be an extra layer of comfort when writing JavaScript code.
Functional Programming (FP)
Keeping it very basic, Functional Programming is a programming paradigm that does not allow any mutations of data or uses any shared state. The main premise is that a function, run with identical input, will always return the same output and will not change any of the input values. It is declarative rather than procedural or imperative.
This paradigm makes functional code easily testable and predictable and often results in cleaner code, shorter functions and overall code that's easier to read and argue about on a human level.
Very similar to Typescript, Functional Programming does not have to be an all-in way to do things. Lending concepts from the functional paradigm can greatly increase the quality and even reusability of your code without forcing you to completely rewrite your existing codebase and even ties in greatly with stronger typing. JavaScript is a multi-paradigm programming language and allows us to take the best from multiple words to use where we gain the most of it.
Where is this relevant?
There are fully functional programming languages with a different level of support for this paradigm but basically, the concept of Functional Programming can be used anywhere you run your JavaScript code, so again, this is relevant for both Frontend and Backend (node) as well as native apps.
Test Driven Design (TDD)
Test-driven development is the software development practice of writing tests that match your expectations or requirements before you write the code to fulfil these.
RED -> GREEN -> BLUE (test, code, refactor).
TDD can fit in well with your existing agile workflow and has its roots in the Agile Manifesto.
RED | Test
A new feature should have a full description of the expected outcome. The team or developer can now transform these specifications into one or multiple simple (unit) tests based on their initial understanding and either check them manually or preferably integrate them with your automated testing. This will bring us to our first state: "RED" because these tests will now fail.
GREEN | Code
The second step is to write the most simple version of code to pass these tests. The idea is to make the most minimal change needed to pass these tests and reach the second state: "GREEN"
BLUE | Refactor
The third step is basically checking the existing code and tests for edge cases, performance issues and possible code optimisations and whether or not the initial feature requirements are fulfilled.
If you learned about unexpected issues during development, requirements changed or your new understanding of the task tells you that your tests need to be adjusted, you go back to the first step and adjust or add to your tests so that you will again get red test failures, iterating over these 3 steps until the task is feature-complete.
Existing tests from previous tasks will help you confirm that other code should not be affected by your changes.
Where is this relevant?
Again, basically, anywhere you write code. There is a small reality check in this case though. The practice of TDD will create a larger up-front workload before you can finish a task and many programmers muse that TDD is something they would like to do but their day-to-day business does not allow them to follow these principles.
Depending on how much code coverage with unit tests your team is trying to reach and how much time you have available, TDD might be a lot of overhead at first and there is a strong bias against it. From my experience though, teams that adapted this practice, apply a good measure of common sense and strike a good balance between code coverage and team performance (GTD or getting things done), during the later development phases of such projects, the existing tests help greatly track new bugs early and before deploying to a client's server.
React, Angular & Vue
React, Angular and Vue are three common tools to use when building websites. Angular and Vue are considered Javascript Frameworks that come with a bigger package of paradigms and restrictions while at the same time also bringing more functionality to the table. React, on the other hand, can be seen more as a library than a framework. It gives the developer more freedom in how to set up the website, at the same time resulting in more responsibility for the developer as well as a larger footprint.
At the end of the day, this article will not try to pick the best of the 3 solutions but I will try to give my personal experience without going too much into detail.
Both my current and my previous team decided to use React, not because it was better but because it felt more natural for us and had a good learning curve to get started. Angular is a fully-fledged framework with all the bells and whistles, but it can also be a bit overwhelming for new developers. Vue on the other hand never felt "right" for us. It is not good or bad, just different and between these three, working with React seemed to most closely resemble working with regular JavaScript. Additionally, switching over to React + Typescript is really simple and by now we migrated all major projects to Typescript.
Where is this relevant?
All three are primarily solutions to build web frontends and interfaces but can be combined with many different CMS backends when needed.
Redux
Redux is a predictable state container for JavaScript apps.
Redux is an open-source JavaScript library for managing and centralising the application state. The Redux store serves as a single point of truth and the simple one-directional messaging system at the core of Redux can help developers to build a scalable and robust client-side application data solution.
While often used in concert with Angular or React, Redux can be used in other constellations too and resembles Facebook's Flux Architecture in many ways.
With only 2kb for the basic install, Redux is tiny but it can easily be extended with custom middleware and there are existing solutions for integrations of data fetching, and other asynchronous tasks. With the Redux Toolkit (RTK), developers are also freed from the burden of writing boilerplate code.
Where is this relevant?
Again, this is a frontend library so no server-side to this either.
Wrapping Up
I hope this article helped you get some basic knowledge about some of the bigger buzzwords thrown around by recruiters, managers and some techies. I will follow up with two in-depth articles about typescript and functional programming, their PROs and CONs as well as some integration examples with other things from today's list such as React and Redux.
Link List
About Das Büro am Draht
Das Büro am Draht is a Berlin-based consultancy helping our clients to build resilient and adaptable digital platforms to support today's business requirements and even launch tomorrow's business models we might not yet foresee. Hence, we work closely together at every stage of the digital transformation process - from digital strategy to solution design & development to operational support. Our agile approach to developing versatile and scalable solutions ensures that our clients consistently deliver engaging and personalized customer experiences. To learn more about how we help companies across industries, follow us on LinkedIn.
Illustrations: kai_sinzinger
Top comments (0)