11 ms·

JavaScript: The Modern Parts

203 points by janvdberg 7y ago

tus88 7y ago
What's the view that TypeScript is the modern Javascript?
- IggleSniggle 7y ago
  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
  - leeoniya 7y ago
    > 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.
    - mping 7y ago
      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.
      - leeoniya 7y ago
        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
        IggleSniggle 7y ago
        We are writing our React components in TypeScript, so I’m not sure what React/JSX have to do with TypeScript adoption?
    - IggleSniggle 7y ago
      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)
      - leeoniya 7y ago
        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.
        deleted 7y ago
        [deleted]
        IggleSniggle 7y ago
        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!
  - growtofill 7y ago
    Source on your claim? It was about 50% on last year’s State of JS: https://2018.stateofjs.com/javascript-flavors/overview/ https://2018.stateofjs.com/javascript-flavors/overview/
  - macando 7y ago
    Have you read this article? https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b https://medium.com/javascript-scene/the-typescript-tax-132ff... I use TypeScript. It's not all rosy.
    - tengbretson 7y ago
      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?
  - RobertKerans 7y ago
    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.
    - IggleSniggle 7y ago
      I agree. Correction added.
  - trias 7y ago
    > 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
- Figs 7y ago
  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.
  - quickthrower2 7y ago
    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.
    - siempreb 7y ago
      > 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.
- pixelmonkey 7y ago
  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.
  - krapp 7y ago
    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 https://news.ycombinator.com/item?id=11447851
  - james_s_tayler 7y ago
    I feel more sold on the ubiquity of JavaScript more than the value of it. I feel sold on the value of TypeScript.
- blondin 7y ago
  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.
otabdeveloper2 7y ago
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.
- debaserab2 7y ago
  Care to elaborate? "Modern" javascript runs just fine in your plain old browser.
  - s_Hogg 7y ago
    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.
    - debaserab2 7y ago
      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?
      - mattlondon 7y 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.
        SquareWheel 7y ago
shusson 7y ago
To be clear, this has no association with the original "Javascript: The Good Parts" by Douglas Crockford book.
- draw_down 7y ago
  Come on
galaxyLogic 7y ago
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?
- ben-schaaf 7y ago
  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.
- IggleSniggle 7y ago
  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)
- shepherdjerred 7y ago
  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.
  - fold_left 7y ago
    > 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/ https://dassur.ma/things/is-postmessage-slow/
phragg 7y ago
This doesn’t belong on HN.
- nullandvoid 7y ago
  because a well written article around one of the worlds most popular programming languages is clearly against the spirit of hn right...
DigitalSea 7y ago
>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.
- IggleSniggle 7y ago
  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.
  - davnicwil 7y ago
    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.
vfc1 7y ago
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.
- siempreb 7y ago
  > 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.
  - DCoder 7y ago
    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.
lol768 7y ago
>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 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).
- WilliamEdward 7y ago
  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.
obituary_latte 7y ago
>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.
- pixelmonkey 7y ago
  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 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-compromise/ https://blog.parse.ly/post/3394/analytics-privacy-without-co... [1]: https://trends.builtwith.com/analytics/Parse.ly https://trends.builtwith.com/analytics/Parse.ly [2]: https://conferences.oreilly.com/strata/strata-ny-2018/public/schedule/detail/69132 https://conferences.oreilly.com/strata/strata-ny-2018/public...
  - obituary_latte 7y ago
    Very cool and interesting stuff. Many thanks for the reply and info.
randallsquared 7y ago
Why "ES2017", specifically? ES6 is ES2015, and ES2019 was published a few months ago and is well-supported in node.
- pixelmonkey 7y ago
  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.
misnome 7y ago
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?
- pserwylo 7y ago
  A good high level overview of the moving parts involved in front end dev is https://roadmap.sh/frontend 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.
- pixelmonkey 7y ago
  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 https://www.youtube.com/watch?v=0RYETb9YVrk 2. Modern JavaScript Explained for Dinosaurs: https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70 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-58712f8fcad9 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 https://leanpub.com/the-road-to-learn-react It's 200 pages, oriented around real code, and straightforward.
pixelmonkey 7y ago
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 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!
- CraigJPerry 7y ago
  it was a really enjoyable article, I bookmarked your functional js paper for later too. Thanks for sharing it. </delurk>
z3t4 7y ago
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.
EdwardDiego 7y ago
> 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.
- blondin 7y ago
  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?
  - ksherlock 7y ago
    JScript.Net compiles to .NET bytecode and has for the past 20 years or so.
- ggregoire 7y ago
  It's not like Python projects are the perfect examples of reliability either.
manigandham 7y ago
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 http://blazor.net
truth_seeker 7y ago
JavaScript brief history and ECMAScript(ES6,ES7,ES8,ES9) features https://medium.com/@madasamy/javascript-brief-history-and-ecmascript-es6-es7-es8-features-673973394df4 https://medium.com/@madasamy/javascript-brief-history-and-ec...
Koshkin 7y ago
JavaScript is fun, but I wish they had chosen Scheme - both for scripting and instead of HTML.

203 points by janvdberg 7y ago

tus88 7y ago

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

IggleSniggle 7y ago
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
- leeoniya 7y ago
  > 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.
  - mping 7y ago
    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.
    - leeoniya 7y ago
      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
      - IggleSniggle 7y ago
        We are writing our React components in TypeScript, so I’m not sure what React/JSX have to do with TypeScript adoption?
  - IggleSniggle 7y ago
    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)
    - leeoniya 7y ago
      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.
      - deleted 7y ago
        [deleted]
      - IggleSniggle 7y ago
        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!
- growtofill 7y ago
  Source on your claim? It was about 50% on last year’s State of JS: https://2018.stateofjs.com/javascript-flavors/overview/ https://2018.stateofjs.com/javascript-flavors/overview/
- macando 7y ago
  Have you read this article? https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b https://medium.com/javascript-scene/the-typescript-tax-132ff... I use TypeScript. It's not all rosy.
  - tengbretson 7y ago
    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?
- RobertKerans 7y ago
  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.
  - IggleSniggle 7y ago
    I agree. Correction added.
- trias 7y ago
  > 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
Figs 7y ago
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.
- quickthrower2 7y ago
  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.
  - siempreb 7y ago
    > 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.
pixelmonkey 7y ago
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.
- krapp 7y ago
  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 https://news.ycombinator.com/item?id=11447851
- james_s_tayler 7y ago
  I feel more sold on the ubiquity of JavaScript more than the value of it. I feel sold on the value of TypeScript.
blondin 7y ago
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.

otabdeveloper2 7y ago

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.

debaserab2 7y ago
Care to elaborate? "Modern" javascript runs just fine in your plain old browser.
- s_Hogg 7y ago
  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.
  - debaserab2 7y ago
    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?
    - mattlondon 7y 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.
      - SquareWheel 7y ago

shusson 7y ago

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

draw_down 7y ago
Come on

galaxyLogic 7y ago

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?

ben-schaaf 7y ago
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.
IggleSniggle 7y ago
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)
shepherdjerred 7y ago
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.
- fold_left 7y ago
  > 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/ https://dassur.ma/things/is-postmessage-slow/

phragg 7y ago

This doesn’t belong on HN.

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

DigitalSea 7y ago

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

IggleSniggle 7y ago
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.
- davnicwil 7y ago
  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.

vfc1 7y ago

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.

siempreb 7y ago
> 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.
- DCoder 7y ago
  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.

lol768 7y ago

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

WilliamEdward 7y ago
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.

obituary_latte 7y ago

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

pixelmonkey 7y ago
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 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-compromise/ https://blog.parse.ly/post/3394/analytics-privacy-without-co... [1]: https://trends.builtwith.com/analytics/Parse.ly https://trends.builtwith.com/analytics/Parse.ly [2]: https://conferences.oreilly.com/strata/strata-ny-2018/public/schedule/detail/69132 https://conferences.oreilly.com/strata/strata-ny-2018/public...
- obituary_latte 7y ago
  Very cool and interesting stuff. Many thanks for the reply and info.

randallsquared 7y ago

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

pixelmonkey 7y ago
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.

misnome 7y ago

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?

pserwylo 7y ago
A good high level overview of the moving parts involved in front end dev is https://roadmap.sh/frontend 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.
pixelmonkey 7y ago
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 https://www.youtube.com/watch?v=0RYETb9YVrk 2. Modern JavaScript Explained for Dinosaurs: https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70 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-58712f8fcad9 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 https://leanpub.com/the-road-to-learn-react It's 200 pages, oriented around real code, and straightforward.

pixelmonkey 7y ago

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

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

z3t4 7y ago

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.

EdwardDiego 7y ago

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

blondin 7y ago
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?
- ksherlock 7y ago
  JScript.Net compiles to .NET bytecode and has for the past 20 years or so.
ggregoire 7y ago
It's not like Python projects are the perfect examples of reliability either.

manigandham 7y ago

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 http://blazor.net

truth_seeker 7y ago

JavaScript brief history and ECMAScript(ES6,ES7,ES8,ES9) features https://medium.com/@madasamy/javascript-brief-history-and-ecmascript-es6-es7-es8-features-673973394df4 https://medium.com/@madasamy/javascript-brief-history-and-ec...

Koshkin 7y ago

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