"Yo, why are #JavaScript and its ecosystem so messy?!" π‘
Well, I am glad you asked... Let me tell you a story! π€
π§΅π
For starting... #JavaScript was not designed to be the language that it is today!
JS was created in 1995 by @BrendanEich for Netscape, a web browser that was trying to come up with a language to make the web more interactive
@BrendanEich#JS wasn't related w/ #Java, so why did they call it Java-Script?! Duh! π³
Java was trendy! it was possible to build interactive sites by embedding Java apps in pages (applets). So it was mostly a #mktg move: "JS: the lightweight Java alternative" or something like that I guess
@BrendanEich I was 8 at the time, so my first encounter with #JavaScript was probably about 6-7 years later when I started to play around with #Frontpage and #DreamWeaver... I remember being confused by JS & its evil twin brother #JScript!
They looked almost identical, but not really π’
@BrendanEich JScript was an attempt by #Microsoft to reverse engineer and re-implement #JavaScript and make it available for Internet Explorer (which also supported #VBScript, a scripting language based on #Basic) π΅
My first prog language was #qBasic, so VBS was actually easier for me! π
@BrendanEich I remember hopping into some #web development forums and no one really liked JS & JScript. Devs were like: "It's a toy, it's slow and insecure" or "this will never be something mainstream!"
- EcmaScript is a blueprint for a language
- JavaScript is an implementation of that blueprint (btw, another one was #ActionScript for Flash)
@BrendanEich@pelger Lots of stuff happened in the following 10 years.
While JavaScript was getting a more and more standard implementation, browsers still didn't really have uniform APIs to interact with the DOM and other browser capabilities. So JS development was still quite tedious! π€¨
@BrendanEich@pelger Also, web development was server-driven, very little still happened on the frontend.
That started to change in 2005 when the "AJAX paper" was published proposing a new approach where the frontend could dynamically fetch data and re-render dynamically
@BrendanEich@pelger One of the biggest innovations at the time was definitely #jQuery, published in 2006 by @jeresig
It became a universal API to interact with browser capabilities (handling all the browser-specific differences).
It was also one of the first JS #OSS projects with great docs & DX!
@BrendanEich@pelger@jeresig I remember using jQuery was pure joy! β€οΈ You could easily find tons of examples in the docs. There was even a search feature! Soon there was even a booming ecosystem of jQuery plugins for all sorts of needs.
For the first time, using #JavaScript was feeling fun & productive! π€
This was another attempt at making the JS experience more pleasant and it definitely influenced the future of the language!
@BrendanEich@pelger@jeresig@jashkenas At this point, a new revolution: in 2008 #Google enters into the browser business with #Chrome! Why does this matter? Because it ships with @v8js an entirely new #JavaScript engine that can run JS faster than anything else thanks to black magic and compiler tricks! β‘οΈ
@BrendanEich@pelger@jeresig@jashkenas@v8js Now, this is an important detail about #JavaScript... There isn't a standard way of interpreting and executing it! There are different engines with different characteristics and tradeoffs (and sometimes subtle bugs π)!
More on this later...
@BrendanEich@pelger@jeresig@jashkenas@v8js All this investment into engines had an interesting effect: developers started to realize that now the game was getting quite serious! Hardware was improving, the web was everywhere (even on multiple devices), #JAVASCRIPT WAS EVERYWHERE and it was getting faster and faster!
@BrendanEich@pelger@jeresig@jashkenas@v8js I remember discovering #NodeJs (probably around 2011) and thinking "WOW, I can finally use one language to build full stack web applications! I'll be saving tons of time and avoid code duplication everywhere!" π€―
@BrendanEich@pelger@jeresig@jashkenas@v8js At that point, it was clear to me I would end up spending a lot of time building projects w/ #Nodejs! Little did I know that a few years later I would end up co-authoring one of the most appreciated books on the topic thanks to @mariocasciaro! π»
@BrendanEich@pelger@jeresig@jashkenas@v8js@mariocasciaro#NodeJs changed everything, not just for me but for the industry! It was proof that #JavaScript could be an excellent tool even outside the boundaries of the browser and that increased the adoption even more! At this point, everyone was optimistic about JavaScript's future!
@BrendanEich@pelger@jeresig@jashkenas@v8js@mariocasciaro In 2015, ECMA-262 got a major improvement: with the release of #ES2015, the language got new features and capabilities. The race for new features has never stopped; since then we get a new major edition with new features every year (#ES2016, β¦ #ES2022).
This is easy and it works! But the implementation is very specific to our struct.
The rest of the codebase doesn't really know that this type can be converted to a String and therefore you cannot build abstractions on top of this... π€¨
1οΈβ£Β You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
2οΈβ£ Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
Software engineering #anxiety, let's talk about it. Specifically, let me try to deconstruct my personal anxiety
π§΅π
1οΈβ£ classic impostor syndrome: it doesn't matter how good I actually am with some technology/tool/technique. Even if I can get the job done, it still feels far from adequate and I feel like I have to rush to get better to defend my job title & credibility...
2οΈβ£ future tech gamble: tech is always changing and I need to be ready for the next big thing if I want to stay relevant in the market. But what is the next big thing? I don't know, of course, so I try to check out as many things as I can and often end up feeling overwhelmed! π€―
I spoke about how #JavaScript module bundlers (those things like #Webpack) work under the hood yesterday at @coderful!
πHere's a short-ish summary:
1/
TLDR: Module bundlers like Webpack are not "complicated" or "magic" per se, the practice of module bundling is a complicated matter and you need to understand it before you can fully understand what a module bundler does and how to configure it correctly! π¦
2/
Why do we need module bundlers? Several reasons:
- Today we rely a lot on third-party software (e.g. modules from #npm)
- There are many different standards for JavaScript modules
- We want to write code in a way that is convenient and just "compile" it for the browser
3/