Front-end development and Javascript have completely changed
Front-end development is becoming more and more complex. When I started coding on the front end years ago, Jquery was the most complex library we used. Most logic for sorting, listing, and randomization was all done on the backend.
The idea of someone who just did the front-end development with javascript was unheard of, they would need to be a designer/developer or backend/front-end.
Codebases would rarely exceed the 20k lines.
Fast forward to 2019, front-end development and javascript have become a very complex game.
In 2010 I could onboard a front-end dev in one day. Today, it might take me up to a week, getting all the tooling and access to all the systems set up to perform javascript dev at a small-to-medium sized company.
It’s commonplace now to walk into a company and find a 100,000+ line front-end javascript codebase.
Let me repeat that….. 100,000+ lines of front-end code.
With that much javascript, there’s more potential for bugs and uncertainty.
So in most languages (Java, C++, C, Golang), you have type safety, you have models, you have an agreed contract of data flowing through the application. THEN ENTER JAVASCRIPT.
No types, no agreed format to data, just objects, strings and arrays floating around. Is this array empty, or null, or undefined.?. WHO KNOWS.
You see tutorials all the time have code that looks like this.
fetch(‘someUrl’)
.then((data)=> setState(data));What is data? What does the state look like? What do I need to do to get a value my boss told me to change?
Furthermore, without type-safe or static-typed features that come with Typescript or flow-type, you’re going to find yourself spending your first couple of weeks on a job doing one of the following:
- Asking your senior dev what data looks like after it went through 8 different functions and classes.
- Or, adding console.log(unkownVariable) throughout your application
Let’s say backend wants to change a single string to an array to allow multiple entries, modifying that model could break multiple components in your application and many times you wouldn’t even know where to start.
const payload = {
selection: ‘selection1’
};
const newPayload = {
selection: [‘selection1’, ‘selection2’]
};
When should you use Typescript of flow-type?
My rule of thumb is if you aren’t going to have a data-intensive front end application, or the codebase will be under 10k lines of code, then don’t even look at Typescript or flow-type as it will just slow you down.
If you’re going to have more than 10k lines of code for a data-intensive front-end application, then you should consider using Typescript or flow-type.
For many senior engineers who have worked with javascript for years, it might seem redundant and unnecessary. Senior developers probably have an easier time remembering data structures and the strange quirks of javascript.
But that’s not the case for most devs. For most devs, javascript looks like a mess of parts lying around on the floor.
I hope this helped a bit to understand the rising popularity of tools like typescript and flow.
Happy Trails
If you liked reading this article, or it helped you, let me know in the comments. Also, if you have any questions about development, let me know and I’ll get you an answer ASAP.
Thanks for reading!
