Hacker News new | past | comments | ask | show | jobs | submit login
JavaScript: The Modern Parts (amontalenti.com)
203 points by janvdberg 53 days ago | hide | past | web | favorite | 117 comments



I think today the Javascript ecosystem looks much better than 3 years ago, at the peak of Javascript fatigue.

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.


> at the peak of Javascript fatigue

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.


> 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.

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


It is indeed not funny, and you're off the mark as well:

> 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.


If people won't even listen to the developers of the tools they use, and insist on "out with the old, in with the new" when those developers are pleading with them not to create extra work for themselves... Whose fault is that?


There are even linting rules to ban use of class components, IiRC.

You’re not wrong. Hooks are being pushed HARD for new code.


Annoying, but sometimes a better idea comes along. I think me and many others initial reaction to the hooks presentation was 'yeeaaaassss'. Still in mostly es6 class codebase of course, so haven't had a chance to do too much with them yet, but as long as they're not gonna break backwards compatibility, yes please.


Honest question - what’s the point of all this change? At the end of the day, people are building web pages with these frameworks?

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.


Nothing like that has happened in the Angular ecosystem, the API is stable for 3 years, and a pleasure to work with.

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.


Indeed, hooks are pretty much the furthest thing from functional programming there is. In functional programming, functions can safely be called any number of times from anywhere in the program, and they'll always return the same result for the same arguments.

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.


TypeScript was and still is a very necessary addition over plain JS, but everything else you said is spot on. This ecosystem is very much a Red Queen's race, you have to learn all sorts of tooling that will be deprecated and forgotten in two years or less.


The thing is, we don't need to learn Bazel either. We will just keep running the command "ng build", and internally the CLI will be using Bazel instead of Webpack, but that is transparent for us users.

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.


Sure... I have never heard of Bazel, but it sounds very black boxish (JS goes in bundles come out!). That is basically the same thing webpack promised in comparison to gulp/grunt. A lower config JS build tool, which is always great until it isn’t. At a certain maturity you will need to dig into your projects build tool.


Bazel is the open source version of googles interns build tooling. It’s not new, but using it outside of google is. It’s also not JavaScript specific, it’s completely language agnostic. You define the rules for building, and bazel will execute it. You can run your entire companies build system off of it.


Sounds like Make


It covers a lot of the same ground, but IMO is much easier to use all around.


> At a certain maturity you will need to dig into your projects build tool

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?


Code splitting, live reload, things that come up like: we have some components that are using react native web, they will be imported into both web and native mobile applications, how do we prevent native sub dependencies of that component from being imported? What if you have multiple bundles but only want angular in one?


The Angular CLI has support for both code splitting and live reload out of the box. ng build creates the main bundle plus the lazy-loaded bundles, and ng serve spins up a development server with live reload ready to go.

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).


Until you want something that’s a liiitke bit different than what the dev’s usecase was


> Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse.

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...


None of the tools you mentioned are unsupported as of now, though. I recently updated a browserify based project from years ago to 16.3 in an afternoon and it just worked.

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.


> None of the tools you mentioned are unsupported as of now, though.

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.


I happen to be in the interview gauntlet at the moment for full-stack JS type jobs so I hear what you are saying but it seems to cut both ways.

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.


It's not like you've been coding with Javascript and now you need to learn Haskell though. Companies love to sprinkle newest trends in their job ads with the technologies they used in their last 100 LOC pilot project and you discover in your first day that there are many big projects which use gulp, grunt and others with ES3, some without async support etc.

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.


React Hooks doesn't preclude ES6 though?

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:)


While the JavaScript ecosystem is on the volatile side, learning new tools and frameworks every few years is just part of our job. Only in very boring tech jobs would you only have to learn new things maybe once every 5 years.

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.


The problem with changing tools to fend off boredom is that it has a very short lifespan. Pretty quickly your brain realizes that it's not learning anything fundamentally new and it protests. Hence fatigue. If possible, it's better to focus on the problem domain and try to make the best of that for entertainment. If not then maybe just accept that it's better to be a bit bored than fatigued.


It’s not learning a new frameworks and tools. It’s the fact that these tools are usually fragile, and quite frankly not very much new is in there.

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.


Yes, I don't even think the most important issue is that we as developers have js fatigue. The biggest issue is that we are developing web applications that are outdated before they are even released. Our software relies on thousands of dependencies that are constantly changing or even dying off. Updating an application that was built two or even just one year ago is often not a trivial task. So while the frameworks and tooling have thankfully improved, in general the cost of developing and maintaining an application seems to be much greater than in the past (e.g. PHP MVC app with some jQuery sprinkled in).


It's blogs and sites like Udemy. Their business model depends on people needing to learn new technologies constantly. So when they tell you "MVC is dead" or "Rails is dead", there is a direct profit motive in it for them. They tell you everyone is using Backbone.js, so you move. Then the next year it's Angular. Backbone is outdated, no one uses it anymore. Then the next year it's React.

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.


The reality of the situation is that JavaScript was designed at a time when there was NO CLUE that it would become the de-facto client-side language for decades.

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.


> I think today the Javascript ecosystem looks much better than 3 years ago

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.

1: https://github.com/standard/standard/issues/1381

2: https://github.com/feross/funding


I'm the original author of this post. Was surprised to see this here this morning -- as I expressed in this tweet: https://twitter.com/amontalenti/status/1165252347909607424

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!


it was a really enjoyable article, I bookmarked your functional js paper for later too. Thanks for sharing it. </delurk>


>Understanding webpack, and why it’s important

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.


I agree with your assessment, but the “major” web framework ecosystem (React, Angular, Vue) all use webpack as a de facto part of their toolchain. And webpack, in turn, relies on babel. Other bundlers are commonly used as part of plugin system.

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.


I agree, JavaScript the Good Parts was written in a time when there essentially was no ecosystem in Javascript to speak of, so it was by definition focused on nothing but the language.

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.


>Whereas Java and C users may still have debates about where, exactly, open source projects should publish their releases, that issue is settled in the JavaScript community

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).


There's a bizarre, naive belief that all programming is web programming.

It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.


Not sure who those people are. But I've programmed precessionally in C, C++, Java, and PHP; and I'd say JavaScript is the most seriously intense. Doing anything useful with it requires knowing so much more than just the language part: libraries, platform (browser, server, Electron, etc.), and the company's preferred tooling/frameworks.


Even with just vanilla JS it can get a bit confusing sometimes. I usually spend a lot of time reading MDN when working with JS just to see if I am missing anything obvious.


Javascript is a frustrating language. On the one hand it's more "serious" than [legacy] C, C++, Java, and Python because it had first-class functions and real lexical closures from day one.

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.


> On the one hand it's more "serious" than [legacy] C, C++, Java, and Python because it had first-class functions and real lexical closures from day one.

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.


Good question. I'll try to give my answer, but others will have their own opinions. Computer languages move in the direction of supporting "good ideas" as those ideas become generally recognized as being good. Usually those ideas start in academia and gradually find their way to industry. Some examples: Structured ("goto-less") programming, object-oriented programming, automatic memory management, strong typing, lexical closures, first-class functions, functional programming, automatic bounds checking, and prevention of memory ownership violations.

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.


I find the idea of viewing a language as "serious" to be fundamentally flawed. Every project has a set of requirements and constraints. Usually the pragmatic language choice is dictated by external factors. Things like library support, developer expertise, and tool maturity are much bigger factors for most businesses.

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.


It is such a "serious" language that it has only floating point numbers. I think you will find it is not fit for serious work.


Java has closures and has had since node was released.

Same for C++.

Javas functions aren't first class, but only to the extent that there's some syntactic sugar.


It's the same kind of people that describe themselves as "full stack" because they made JavaScript in the browser talk to JavaScript on the server, the latter running in some kind of heroku auto-container magic.


"It's common among people who think Javascript is a serious language".

I can't tell if you think JS is not a serious programming language.


Thanks for bringing attention to WebAssembly, far from perfect but with time it could rise to become the default for front ends. Javascript's popularity was purely accidental and doesn't have to be the only option for in-built browser applications.


I tell people WASM is great but still not quite ready just yet. I think we will start to see amazing things. Even Microsofts Blazor is impresive. I cant wait to see what Python and other projects come up with in regards to WASM.


> Yes, it has taken 20 years, but JavaScript is now just as viable a choice for your backend and CLI tooling projects as Python was in the past.

Considering how often Node projects break our build, I respectfully beg to differ.


It's not like Python projects are the perfect examples of reliability either.


i agree with the sentiment. i was just thinking about it yesterday. what if there was a pure javascript based system programming language? with none of the event loop thingies?

i mean can we have a normal javascript that compiles to a x64 binary and calls the OS?


JScript.Net compiles to .NET bytecode and has for the past 20 years or so.


To be clear, this has no association with the original "Javascript: The Good Parts" by Douglas Crockford book.


It looks like an interesting light summary of the state of things. The technical articles might be more useful, for me.

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?


I'm the original author of the post. A friend who reviewed a draft of it asked me the same question. I had the following recommendations:

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.


A good high level overview of the moving parts involved in front end dev is https://roadmap.sh/frontend. Not all of it is used all the time, but if you can talk intelligently about many of the parts you are doing fine.

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 had the same problem as you.

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://frontendmasters.com/books/front-end-handbook/2019/


Javascript is not the only answer to frontends ever since WebAssembly arrived. Microsoft is releasing Blazor for C# in a month (server-side first then client-side) [1] and there are similar projects being worked on for Rust, Java, etc.

1. http://blazor.net


JavaScript brief history and ECMAScript(ES6,ES7,ES8,ES9) features

https://medium.com/@madasamy/javascript-brief-history-and-ec...


I have some ES6 compliant JavaScript to run on the browser. Now I would like to compile it into web-assembly and serve that from a server to the browser, to make it faster to run and download.

Is that possible with the modern JavaScript tools?


Web assembly isn't inherently faster than well-optimized Javascript. You save the parsing and compilation overhead of JS, but right now the focus with web assembly isn't on speed yet.

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.


Depends on the specifics of your needs. Web-assembly is still slower than the V8 JIT compiler for use cases where you want to interact with the DOM. Interaction with the DOM, of course, is one of the main reasons to deliver code to a browser. But if you need to, say, create a cryptominer in the browser, then a TypeScript variant of JavaScript can target WebAssembly. You are trading out a superb JIT compiler with look-ahead and runtime optimizations for a relatively immature compiler, however.

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)


It is, if you include a JS interpreter in your wasm bundle.

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.


From what I've heard WASM isn't a viable alternative in the first place. It's good for compute-heavy tasks, but the overhead involved in going from browser to native to browser is too much to make WASM an alternative to what JavaScript is usually used for -- rendering interfaces and making pages interactive.


> From what I've heard WASM isn't a viable alternative in the first place. It's good for compute-heavy tasks, but the overhead involved in going from browser to native to browser is too much to make WASM an alternative to what JavaScript is usually used for -- rendering interfaces and making pages interactive.

I don't think that's the case anymore: https://dassur.ma/things/is-postmessage-slow/


Article is unrelated. The overhead for Wasm is from copying structs into and out of the Wasm's linear memory. Wasm only has ints and floats at the boundary, so you have to copy everything into structures it can understand.

Note that there is work to improve this (interface types, anyref, etc), but we're not there yet.


Considering awsm still doesn't have a gc last I heard, I don't see what you have to gain from compiling JavaScript to it.


>In that era, I wrote one of the most widely deployed pieces of JavaScript on the web, and maintained a system powered by it.

Anyone know what he is talking about here? I searched google but couldn’t find what he was talking about.


I'm the original author of the post.

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...


Very cool and interesting stuff. Many thanks for the reply and info.


Why "ES2017", specifically? ES6 is ES2015, and ES2019 was published a few months ago and is well-supported in node.


I'm the original author. This is just an oversight -- the original draft I wrote here was at a time when ES2019 wasn't yet published. Agree that you can safely use any ratified (recent) standard with Babel.


JavaScript is fun, but I wish they had chosen Scheme - both for scripting and instead of HTML.


What's the view that TypeScript is the modern Javascript?


Given how fashion-driven the web industry seems to be, my guess is that some new hotness will steal the stage from it in the next few years. I seem to recall seeing tons of posts about CoffeeScript maybe around 6~7 years ago, but it doesn't seem to be very popular any more...

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.


Typescript solves the biggest issue I have with using JS which is a lack of a static type system. It however does it in a very pragmatic way, giving the closest experience to Vanilla JS you could hope for. You are not learning a new language like you would be with Elm or Reason etc.

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.


> Typescript solves the biggest issue I have with using JS which is a lack of a static type system.

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.


The biggest problem the parent comment have with JS is not types, as you say, but __a lack of a static type system__.

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).


Having a static type system is great but it’s just another tool in the toolbox. I’ve been writing Javascript for 23 years without types and didn’t miss them. They’re great when I have them in other languages but not a deal killer in languages that I don’t.

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.


"I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking"

Surely the biggest benefit from static typing is for static-analysis tooling. (e.g. strong compile-time checks).


I don’t disagree but the way people speak about static typing is as if it’s present during the life of the application.


Different languages have different types of behaviour under the "static typing" umbrella.

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?


While it's fair to say that a static type system adds friction which isn't suitable for some development mindsets, I think it's worth expanding on problems people run into with types.

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.


Tell me more as I want to grok the dynamic typists viewpoint as I’m sure I’ll learn something. So are you doing type check assertions at runtime and throwing errors? Or are we talking about something else?

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.


CoffeeScript never solved any issues tho. It was just syntactic sugar.


I'm the original author of this post. I'd say that it's very unlikely that TypeScript will supplant JavaScript. To quote Crockford in 2008:

"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 feel more sold on the ubiquity of JavaScript more than the value of it. I feel sold on the value of TypeScript.


The web (or specifically HTML) was originally intended to support multiple scripting languages (which is why the <script> tag had a type attribute, which is now deprecated in HTML5.) Unfortunately, things didn't work out that way.

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].

[0]https://news.ycombinator.com/item?id=11447851


TypeScript adoption has been swift and decisive. In 2019, the majority of js developers that take surveys use TypeScript.

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


> majority of js developers that take surveys

i like that qualification :)

most likely typescript is still a very small minority given how large the javascript world is


Source on your claim? It was about 50% on last year’s State of JS: https://2018.stateofjs.com/javascript-flavors/overview/


Have you read this article?

https://medium.com/javascript-scene/the-typescript-tax-132ff...

I use TypeScript. It's not all rosy.


There author of that article is speaking out of both sides of their mouth. How can they claim type safety has minimal value and simultaneously knock it for missing higher kinded types?


I think a correction is needed here, it's "the majority of typescript developers that take surveys said they used typescript".

I'm being flippant, but Typescript is quite popular, that's it, most people who write JS write JS.


I agree. Correction added.


> In 2019, the majority of js developers that take surveys use TypeScript.

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.


46% was the survey number, so I definitely misremembered the facts. But your comparison here is inevitably necessary, since TS compiles to ES6/JSX, (as does Flow)


what was the survey sample size and how was the sample selected? (46% of 0.001% is still 0%).

my assessment isn't what things compile to but what they are authored in.


Good question. The state of js survey was self-selected, with 20.2k responses. The data is available if you’re interested. The npm survey, on the other hand, was sent to 800k registered npm users and received 33.4k responses, and also found 46% TypeScript usage. I imagine there is significant selection bias in a number of ways. And, while the state of js survey found 46% “have used ts and want to use it again”, the npm survey did not ask about preference. Still, a decent number of responses that I think is pretty interesting, regardless of your own preferences!


I don't understand why jsx is in your comparison, although I agree with your assessment.

To be clear there are a gazillion Js projects that don't use react.


it's a bit anecdotal but React /JSX is still more common than TypeScript (if for no other reason than time on this earth). and both are dwarfed by ES5/6


We are writing our React components in TypeScript, so I’m not sure what React/JSX have to do with TypeScript adoption?


not sure Anders/microsoft wanted to replace javascript with typescript. the problem is this imo.

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.


[flagged]


because a well written article around one of the worlds most popular programming languages is clearly against the spirit of hn right...


No you dont need a transpiler. The new language features are exiting, but its really just old concepts from other languages. And IMHO these old conceps are not better and some of them are worse. JavaScript was lucky and got some things right, like first class functions, prototype instead of classes, function scope, no need for getter/setters. Node.js also got lucky with its module system. JavaScript was lucky because it was async. Javascript got adopted in more then just browsers because it was lightweight. Etc.


The "modern" Javascript parts make me almost physically sick.

Gimme back my plain old browser Javascript. It was primitive, but at least it wasn't actively harmful.


Care to elaborate?

"Modern" javascript runs just fine in your plain old browser.


Parent is talking about all the vulnerabilities and slowness that can come with it. Fair enough, it runs, but it can also open the door to fingerprinting and other weird nasties. Particularly anything reliant on the `npm install` way of managing dependencies is a potential risk from both server and client point of view.


Where is parent talking about any of that?

What about today's javascript lends itself to fingerprinting any more than javascript from twenty years ago?


Agreed - I don't see how adding things like "let" instead of "var" or the spread operator (e.g "[...x]" instead of "[].concat(x)") makes fingerprinting or anything nefarious any more likely, apart from making it more pleasant to program so maybe more people will use it?

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.


While I fully agree with you, being Turing complete has nothing to do with it. I think the article is slightly wrong too on this point.

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.


Those APIs also have a much stronger security model behind them today. Browsers require things like TLS and user confirmation before sharing geo information. Other actions like the clipboard API require user interaction (eg. button clicks).

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!


>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].

[0]https://johnresig.com/blog/re-securing-json/




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: