JavaScript: The Modern Parts
amontalenti.com
amontalenti.com
What we had actually was tooling fatigue, and not language features fatigue. Today, with CLI tools like the Angular CLI, we have a ready to use optimized bundle via one out of the box CLI command, so no longer do we have to learn how to configure Gulp or Webpack.
I'm very glad that I decided not to learn Webpack and stick to the CLI, now Webpack is going to be replaced by Bazel transparently, and from a user perspective, nothing changes other than getting an even faster build and a smaller bundle transparently, without having to be a build tools expert.
I can now focus on developing the application and not the tooling, which is awesome for me. There are only so many hours in the day and I like to focus my learning budget on what moves the needle most.
Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse.
You just mentioned webpack is going to be replaced?? That's unfortunately very typical for the JS eco system. 7 years ago we had Grunt, then about two years later Gulp, then about a year later Webpack, now apparently Bazel? Interesting, never heard of it, but I still feel fatigue. I spent quite some time to master Webpack, and again I'll have to start all over for the 4th time now learning the next bundler..
I just started with React Hooks some months ago. First we had mixins(about 5 years ago), that was replaced with Higher Order Components, then we had to start writing React in the brand new ES6 classes, then we saw the Render Props, the Pure Functions, etc.. and now ES6 classes and all the rest are deprecated, because Dan Abramov had another idea for again a new design principle that's just less than a year old: Hooks.. Oh, and we don't do that in JS, that is not sane anymore, every job I get nowadays is Typescript.
I mean, think twice before you say the Javascript fatigue is past it's peak.
This is so off the mark it’s not even funny.
- Dan did not develop the hooks api
- he is also on record saying that people don’t need to re-write their components with hooks
- class components have not been deprecated in React
> Dan did not develop the hooks api
I didn't say he developed it
> he is also on record saying that people don’t need to re-write their components with hooks
So? In my daily work I see it all the time. You think I have a say in that when I have a gig at company X?
> class components have not been deprecated in React
You've got a point there, indeed not officially deprecated, but in practice(again) at company X, you cannot do classes anymore.
You’re not wrong. Hooks are being pushed HARD for new code.
John Carmack has an excellent article on static analysis (unrelated to this topic), but there’s this excellent quote:
>It is important to say right up front that quality isn't everything, and acknowledging it isn't some sort of moral failing. Value is what you are trying to produce, and quality is only one aspect of it, intermixed with cost, features, and other factors.
These JS frameworks and build tools provide far more than just code quality, but what all benefits are they providing that outweigh the cost of, “here is XYZ that you must now figure out, and before you can figure out XYZ, you need to learn A, B, and C”. Stated differently, what exactly is the value?
Junior developers make this mistake and unfortunately so many more tenured developers as well. I can understand you want to use the shiny new thing. How often do you replace your toilet or kitchen sink though? Is it worth it?
To me, the JS ecosystem has become to complex. Even if you’re building for Amazon or Google scale, you want to think twice about not only the shelf life of these various frameworks but also what are their dependencies, what are their failure modes, and at the end of the day, how are they giving you an ROI if you use the new X framework of the month or year CS Y.
I think this obsession with functions and the functional paradigm is counterproductive in the React ecosystem.
Sometimes, the best way to represent something is a class. When you have some data and a series of closely related fucntions that modify the data and are highly related to the data, it's better to use a class.
This hooks API thing is anything but functional, way too much magic. Its stateful programming diguised as functional.
Hooks, on the other hand, crash and burn at runtime if you call them outside a React component function, or in a different order or number from how you called them the first time your component was rendered.
We only see the CLI commands on our end, and the Angular CLI internally will use whatever build tool is best for the job at a given time, and will keep evolving over time.
It's such a relief that we don't need to learn build tools in the Angular ecosystem anymore and can focus on application development only.
The command "ng build" takes in typescript and produces optimized lazy-loaded bundles, and there won't be the need to customize that, there aren't a thousand ways to produce bundles after all, there is one optimal way for a given ecosystem, and it does not make sense for each project to reinvent a build system that all it does is transpile, concatenate, minify, compress, etc. like every other project.
Any additional build steps besides bundling are usually very simple can often be done either via npm scripts, or a simple shell script.
Can you give examples of things for which you would absolutely have to customize the build system?
The Angular CLI also supports multiple applications with shared components. You can build a web application that uses shared components, and a separate mobile application that uses the same shared components and has its own separate build.
The React and Vue ecosystems are going in the same direction with their CLIs, but I don't think the Vue CLI or create-react-app are quite as powerful yet.
Once they are, it will be the end of tooling fatigue, and no one will have to create their own custom build anymore (other than a shell script or so).
No comment regarding the "peak" but 3 years ago is when the very influential How It Feels To Learn JavaScript In 2016 post came out. https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
I remember the days I was afraid to do npm update the dependencies, I was copy pasting build script configurations for new projects, I used to use code mods every other month to make huge refactors (and badly), packages disappearing, every project inventing how to manage state (not just react)... All of this is past for me. Yeah of course it's just a data point but there's the fact that you can start a complex web app project with one command these days and not care about core dependencies. I expect it'll go only better. Maybe it's me getting experienced but I certainly wasn't a beginner few years ago, not even close. I'd love to hear what kind of difficulties you are having with your projects though, it's very possible that I'm missing something.
I mean working as a professional, doing my next gig. Do you think I can still use my Grunt or Gulp skills there? The landscape is now again very different than it was a year ago. I cannot even code in ES6 anymore, all the jobs are TS and React Hooks at the moment. When I say I prefer JS over TS my colleagues think I'm not smart and skilled enough to understand the benefits of TS. There is not much choice unfortunately, independent of being supported or unsupported.
Most places using React are expecting me to be familiar with hooks and everyone using Javascript is asking about familiarity with Typescript. But at the same time they genuinely seem impressed/surprised that I have been using async/await for over a year on my latest professional projects.
I want to say this in a nice way but it is difficult. I feel Javascript developers suffer from an inferiority complex. It's like they need to feel what they are doing is "real code" or something. That seems to translate in this crazy pace of replacement of technologies. I think it gives the impression of innovation. To me it feels like an unsteady eco-system still trying to find its footing. The vacillation from OOP to functional and back again feels like uncertainty. From DIY systems like gulp to all-in-one systems like webpack. It's a sector full of people desperate to look like they know what they are doing while they act like they are still trying to figure it all out.
All that being said, working in JS in 2018/2019 is significantly more pleasant than it ever was in the past. I find creating back-end Node.js services to be quick and easy and writing front-end systems using React bearable. Despite high volatility there is definite progress.
I got a friend in Silicon Valley (I'm in Germany and here the attitude is more towards reliability and stability) and even there he got many interviews and a new job without listing many of the newest libraries/languages in professional capacity.
Plus, I'd suggest you try Typescript with an open mind. It's amazing.
Really, they're just functions that have some weirdness/magic about when you call them.
I love them, but that's not really what this thread is about, of course:)
I wouldn't really bother wasting time "mastering" something like Webpack or what replaces it - as the other commenter said we just end up using an abstraction over it anyway.
Also, what’s your goal? To learn new tools over and over again? Or to crate something that that people will use?
You sound like a music “producer” (read - tech hobbiest) who keeps switching tools, synths, and hardware instead of just creating music.
The blogs drive the technology shifts in order to get clicks. And every time the technology shifts, Udemy sells a million tutorial videos at $10 a piece. Everyone gets up to speed on the new thing just in time for the blogs to find new clicks and Udemy to find new videos.
Meanwhile the real world still runs on Laravel, Rails, Flask, and Postgres.
So now the ECMAScript standard is pushing JavaScript towards a "proper" language, but we need additional tools (TS, Babel, etc) to write in an even more "proper" language/syntax that will give us something that the browser still needs to understand (JavaScript).
This isn't a fun process for those of us who have been developing a long time. Look, JavaScript has classes! And modules! Ok, that's good I guess, we're getting there. But that's not learning, that's just getting closer to something we are already familiar with as software engineers.
That’s certainly up for debate. Today you have NPM being treated as an Advertisement delivery tool. See the latest version of StandardJS and a new package called Funding. IMO it’s a pretty massive setback for the ecosystem.
Glad to answer any questions about the post here.
I am hoping to write a second part to this post eventually. It was honestly sitting in my drafts folder for a solid 6-8 months, and then I finally cleaned it up and published it two weeks ago. But I still have more thoughts!
Not sure how Webpack is being attributed as being a part of Javascript here. It's a bundler, with Javascript support being one small piece in a much larger puzzle. It's not even the only bundler out there, JSPM is currently in beta which goes in a different direction than Webpack, then you have Parcel and other options as well.
>Understanding babel, and why it’s important
Eh. I haven't used Babel in years since switching to TypeScript.
This doesn't seem very focused on Javascript, seems like a lot of emphasis being placed on tooling more than the language itself.
Regardless of transpiler tooling, the tooling is how most people are confident in using the most modern variants of JavaScript code. So it’s an important part of the modern js story.
In 2019 JavaScript comes as part of a much more developed (and useful!) ecosystem that is completely tied in with tools such as Babel and Webpack and the alternatives mentioned.
Even if you don't use or want to use any particular one of them, knowledge of all of them, at least what they do, is more or less essential to work in modern JavaScript to understand how the ecosystem fits together and how most projects out there use the language.
I thought Maven Central was pretty much the canonical answer in Java land. Nobody cares what tool you actually use to pull these down (SBT, Gradle, Maven..).
>What this means, however, is that to do JavaScript development “The Modern Way”, while adopting its new features, you simply must use a local transpiler toolchain
Surely this depends on the browsers your application is targeting? And presumably, the sort of feature you're using (can it be polyfilled or is it a syntax feature?).
>In 2018-2019, several things have changed about the JavaScript community. Development tools are no longer fledgling, but are, instead, mature. There are built-in development tools in all of Safari, Firefox, and Chrome browsers
I agree they're decent, but there are still cases where they struggle - particularly after code has been transpiled. I still run into issues these days where the browser is trying to show a source-mapped JS file instead of the actual bundle code which masks a real issue.
>And, for web frontends, it’s your only choice
https://caniuse.com/#search=webassembly
If you don't care about IE11 (or you polyfill), it's hardly your only choice. wasm is still far from perfect but there's no question you can start writing some logic in languages other than JavaScript, and interoperate.
>If you’re the kind of programmer who thinks, “I code in Python/Java/Ruby/C/whatever, and thus I have no use for JavaScript and don’t need to know anything about it”, you’re wrong, and I’ll describe why. Incidentally, you were right in 1998, you could get by without it in 2008, and you are dead wrong in 2018.
>To be a serious programmer, you’ll have to know JavaScript’s Modern and Good Parts — as well as some other server-side language, like Python, Ruby, Go, Elixir, Clojure, Java, and so on
This reads to me as downright patronising to e.g. embedded software engineers who might be writing hardware drivers in C/C++ day to day.
Perhaps this should read "to be a serious web developer with front-end responsibilities" (JavaScript is sufficient, not necessary on the back-end and - of course, subjectively - there are much better choices to use).
It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.
On the other, it had imprecise typing, no multiprocessing, and no access to the file system. Some of that has been fixed, but Javascript was designed by one person in a week to script web browsers and that's still painfully obvious.
Why do closures make a language "serious"? To me languages are just languages. Seriousness is defined the problem you are solving. Are flight controls serious? Probably. Is yet another small scale CRUD app serious? Probably not.
There is a lot of "serious" code written in every major language. There is a huge amount of "serious" code written in C and C++, and all of this without first class functions or lexical closures.
A "serious" language is indeed partially defined by its fitness for the stated job at hand, but also for how well it handles the often unstated requirements of productivity, security, maintainability, and robustness in the face of likely future needs. Languages that have more of the above features tend to do better at these unstated requirements.
What is and isn't a "serious" language can change over time depending on what we learn is important. C was a serious language for a while, but it has not been one for a couple of decades because of its non-support of anything remotely resembling security. C is still used because of its extreme portability, but it probably should be abandoned.
Conversely, languages that support first-class functions, lexical closures, and automatic memory management are now in the serious category because those things present huge improvements in productivity, maintainability, and robustness in the face of future changes. (I'll even go out on a longer limb and say that programmers who learn to think in terms of functional composition become more productive coders in any language.) Pure O-O languages are beginning to move in the non-serious direction because they cannot be readily parallelized in an era when parallel computing is the only way forward now that Moore's law is dead.
Javascript anticipated a couple of these features before other mainstream languages, and now it's moving beyond web browsers. So yeah, with some reservations I'd call it serious.
Nowadays I'd never write major code in a language that doesn't directly support most of the "serious" features I listed above; it would be too much of a hit to my productivity. It would feel like building a house with a hammer and nails when nailguns were readily available.
If I were writing embedded apps like flight controls today, I'd use Lisp for the high-level parts and Rust and maybe a bit of assembler for the low level parts.
The "serious" professional choice for my company (an OS vendor, with a focus on certifiable systems) is currently C. The tooling we use is for C, the expertise within my company is in C, and the industry that we work with understands and expects C.
At some point, the operating systems industry will transition to more modern languages. Rust is promising, but it is a long way from being a serious consideration for FAA certifiable projects.
Same for C++.
Javas functions aren't first class, but only to the extent that there's some syntactic sugar.
I can't tell if you think JS is not a serious programming language.
Considering how often Node projects break our build, I respectfully beg to differ.
i mean can we have a normal javascript that compiles to a x64 binary and calls the OS?
As a primarily Python/C++ developer who dabbled with JS in the early and late 2000s, can anyone recommend an efficient way to get started with modern JS development for hints like interactive frontends with a different-language. I’m comfortable with large language ecosystems, but there seems to be an intimidating number of incompatible paradigms - and there’s both the technology and toolings.
Easiest to start with one track e.g. react/tutorials and branch from there? Good books that approach the problem efficiently and for a decent existing programmer/scientist?
1. Solid recorded talk (on YouTube) on using npm run-script to automate local builds: https://www.youtube.com/watch?v=0RYETb9YVrk
2. Modern JavaScript Explained for Dinosaurs: https://medium.com/the-node-js-collection/modern-javascript-... -- this is a long post that goes into technical depth on the stuff that I covered at a high level in my post
3. Webpack -- The Confusing Parts: https://medium.com/@rajaraodv/webpack-the-confusing-parts-58... -- long post that goes into depth on Webpack, in particular.
Aside from all of these, the book I have found the most helpful if you want to zoom straight ahead to React is "Road to React": https://leanpub.com/the-road-to-learn-react
It's 200 pages, oriented around real code, and straightforward.
My recommendation to people learning specific frameworks such as react is to start with vanilla react (their doc's are quite good). Then, after building a small app that solves a problem for yourself, you'll start realising when you have bugs and other maintainability issues related to state management. At that point, it is worthwhile looking into redux (or another state management library). Otherwise if you go straight to react + redux it can just feel like a lot of boilerplate for no reason.
Same with TypeScript. I think type safety offers a huge reduction in the number of bugs in large systems. But it isn't required when first learning react.
I also highly recommend "Modern JavaScript Explained for Dinosaurs" for a high level overview of why the JS tooling is like it is.
This is also a good overview of the whole ecosystem, together with suggested learning paths:
https://medium.com/@madasamy/javascript-brief-history-and-ec...
Is that possible with the modern JavaScript tools?
You also can't just compile any Javascript to WASM, the closest thing to this is AssemblyScript:
https://github.com/AssemblyScript/assemblyscript
This compiles a subset of Typescript to web assembly. And you have to take "subset" seriously here, web assembly is very limited in how memory is managed, you can't just drop your Javascript in there and get web assembly out.
If you want your process to run on the server, and merely pass the result to the client, you can compile JavaScript to C, and then to a binary, with QuickJs. Most folks will just use Nodejs, however (which also uses V8)
But it isn't a good idea. JS is a language that needs a runtime, the browser _has_ a JS engine, and not using that would just be counterproductive and wasteful.
I don't think that's the case anymore: https://dassur.ma/things/is-postmessage-slow/
Note that there is work to improve this (interface types, anyref, etc), but we're not there yet.
Anyone know what he is talking about here? I searched google but couldn’t find what he was talking about.
I was talking about Parse.ly's analytics engine, where most of the data we provide to our customers on first-party analytics around their audience stems from some lightweight JavaScript code they embed in their websites. It's now installed on thousands of high-traffic sites[1] and provides analytics on over a billion web/mobile browsers per month (as described in this Strata talk[2], for example).
I wrote a little bit about my experience writing that code in this HN comment: https://news.ycombinator.com/item?id=10206956#10207998
It was a fascinating piece of code to work on because not only did it have to be lightweight and fast across all browsers, but it also had to be tiny to embed, and it needed to be x-browser tested all the way back to IE6 and strange mobile browsers. Plus, at the time it was originally written (2010-2012), there were hardly any good JS build tools outside of early versions of uglifyjs.
Over the years, other engineers have improved the performance even further, while retaining the kernel of the code. We even did a change last year which improved client-side performance through a number of clever build/CDN tricks. We've also had to hold our ground firmly on privacy, which it turns out is one of the key areas third-party JavaScript started to take a turn in the wrong direction, especially in the adtech universe. (We are a content analytics company, with a similar SaaS business model to MixPanel for product analytics and NewRelic for performance analytics. So, for us, privacy is paramount.) I wrote about this here: https://blog.parse.ly/post/3394/analytics-privacy-without-co...
[1]: https://trends.builtwith.com/analytics/Parse.ly
[2]: https://conferences.oreilly.com/strata/strata-ny-2018/public...
Maybe TypeScript will turn out to have more staying power, but my current guess is that something will happen that makes another technology -- probably WebAssembly -- very popular in the next few years and that will kill off a lot of the hype around TypeScript. Then that will itself mostly get killed off by some other technology about 3~5 years after it hits peak popularity, and so on...
I could be completely wrong though, of course! Predicting the future is hard. This is just my guess based on handwavey recollection of the last decade and a half of web trends.
It has a powerful type inference system that puts C# to shame in places, and in some places I prefer TS to C#.
I don't feel like Typescript is 'hyped'. It is popular because it's damn good. As a programming language alone it could be seen as not too special, but when you see what it's trying to do, get JS developers to use types and not run a mile, then it does a brilliant job.
Hmm, the biggest problem with JS is types? Are you sure? I rarely had issues with types in JS. With JS I just used my trusty dynamic type checker at specific places in the codebase, and testing coverage of course even more importantly.
But with TS, the codebases I see on a daily base are mostly a terrible mess of wrong ideas, wrong libraries, wrong constructs, wrong design principles, tooling hell, etc, etc.. Which is IMHO the real issue with JS/TS. For some reason TS proponents seem to live in a world where 'TS solves everything'.
For me TS is just writing 20% more code and regularly needing to use the 'any' keyword to avoid spending hours on getting a basic line of code working. Everything I write non-professionally is not TS, I cannot think of 1 single reason to give myself that burden.
The best thing TS has given me is even more jobs. With Agile front-end developers spend at least 1 day a week in the meeting room, now with TS they spend 20% of their time left to hassling with types. It's hilarious. Especially all those managers that have no clue what's going on, why front-end development gets slower and slower.
They are things as different as that you can actually have type problems only in a really typed system (as a static type system). Javascript has a very weak type system, and that's the problem. I think you do not understand that static typing serves to solve other problems in the code, not to solve type problems ... it would be like saying that an hypothetical language needs functions to solve function problems ... and then you say that you never had problems with functions in that hypothetical language (ex: assembler, with very primitives "functions", where you have to save data in register before jumping to code in another memory address).
But so many TypeScript fans act as if having types is the be-all and end-all.
And, unless I’m mistaken and something has changed recently, I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking since the compiler strips away the types after TypeScript gets compiled down to Javascript.
Don’t get me wrong; TypeScript is great. But I don’t see it as the savior that others make it out to be.
Surely the biggest benefit from static typing is for static-analysis tooling. (e.g. strong compile-time checks).
Typescript has chosen to interop nicely with JS, and they took the tradeoff that if you are passed an object (e.g. from an Ajax request) and you assert that it's a Duck, TS will assume that is correct during static typing. Of course this might be wrong at runtime, you may get returned {'foo':1} instead of {'foo':'bar'} and your object.foo.length now returns undefined.
Static typing in general (in other languages) does persist into the lifetime of the application. By persist, I mean the guarantees persist, even if the types are thrown away. Haskell for example throws away the types at runtime (you can't reflect on them) but because it's so strict, you can be sure that X: String->String does indeed return a string. This you cannot be 100% sure of in Typescript.
So why is Typescript useful? Well if you write an entire app in TS (which I am doing now) then all the code you write ... which is the new non-battle-tested code ... is now type checked against itself. Also well written libraries using TS will be well type checked against. People doing stuff like casting to <any> etc. could break things for you. But in general you get Pareto's rule applied and because most of your code is type checked (and it only isn't when getting stuff from the server or using a dodgy library that has exported an incorrect .d.ts or something), then you get almost 100% of the benefit.
Basically am I getting errors due to incorrect types at runtime in Haskell? Never. Am I getting them in Typescript? Not yet but it's possible, maybe 0.1% chance?
Bad types at runtime: with a static type system you make the effort to be sure the code does what it says. With plain ol' JS you can get that confidence from tests. -- different trade-offs made each way.
But another benefit to static types is knowing the structure of the data you're dealing with and how to manipulate it, while you're developing/maintaining the code. -- sure: naming, unit tests, documentation etc. can help, but I find not having the static types handy makes things tricky when there's enough indirection/complexity.
As with the stuff about runtime errors, tastes vary, of course.
What I like most about static typing is tooling support for refactoring and how much easier it can be to change a name or significantly change internal apis and jig stuff around with confidence.
"Because JavaScript is the language of the web browser, and because the web browser has become the dominant application delivery system, and because JavaScript isn't too bad, JavaScript has become the World's Most Popular Programming Language. Its popularity is growing. It is now being embedded in other applications and contexts. JavaScript has become important. It is better to be lucky than smart."
TypeScript is a very smart language, but then, so are Dart, CoffeeScript, ClojureScript. I suspect that if code durability is what matters to you, JS (and the ES evolutions thereof) will have the real staying power. Plus, not everyone is sold on the value of static types, but everyone is sold on the value of JavaScript.
I'm hoping that when WASM matures a bit more, and becomes as universally supported in browsers as a javascript runtime, JS just becomes the default language supported by it, not the only one possible. Maybe one day it'll be common to see Typescript run directly in the browser, who knows?
>but everyone is sold on the value of JavaScript.
Not everyone[0].
Edit: Mea culpa. I got my numbers mixed up, or whatever source I thought I remembered just doesn’t exist. 46% in 2018 (state of js) says nothing about 2019, and is not a majority. That 46% is also backed up by a similar survey that npm ran. It’s worth adding though, I think, that js devs benefit from ts type inferencing and IDE support even if they aren’t using it directly
i like that qualification :)
most likely typescript is still a very small minority given how large the javascript world is
https://medium.com/javascript-scene/the-typescript-tax-132ff...
I use TypeScript. It's not all rosy.
I'm being flippant, but Typescript is quite popular, that's it, most people who write JS write JS.
TS is quite popular, but this cannot possibly be representative of the general population of js devs, not even close.
it's more like ES6 >> JSX >> TS >> Flow.
my assessment isn't what things compile to but what they are authored in.
To be clear there are a gazillion Js projects that don't use react.
to use javascript -- or say python -- in an corporate/enterprise environment, you need to analyze your code base. static analysis is what worked well and still does but you need types. ofc having types has other major benefits but this is the big one for me at least.
Gimme back my plain old browser Javascript. It was primitive, but at least it wasn't actively harmful.
"Modern" javascript runs just fine in your plain old browser.
What about today's javascript lends itself to fingerprinting any more than javascript from twenty years ago?
The "old" javascript was turing complete (as the article points out), as is the current one. It is not like they've added "Object.turnOnNefariousPrivacyInvasions()".
Granted, the browser APIs have evolved (e.g. webcam access, localstorage etc) and are exposed via Javascript, but that is nothing to do with JS the language.
Turing completeness is a property about the computational "power" of a language. It has nothing to do with the environment in which the program runs. For example, it can exist a language that is Turing complete and has no way at all to access the network: it can do no harm, doesn't matter if it has the same computational power as Javascript.
JS of the past was the wild west. You want to add a bookmark? Go for it! You want to trigger a print dialogue? Why not!
Yeah. People forget that in the bad old days you could even do things like redefine the global Array constructor[0].