61–70 of 122 posts
Why "ES2017", specifically? ES6 is ES2015, and ES2019 was published a few months ago and is well-supported in node.
To be clear, this has no association with the original "Javascript: The Good Parts" by Douglas Crockford book.
What's the view that TypeScript is the modern Javascript?
"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.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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/
Note that there is work to improve this (interface types, anyref, etc), but we're not there yet.
Earlier quoted context omitted.
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.turnOnNefariousPriv…
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!
Yeah. People forget that in the bad old days you could even do things like redefine the global Array constructor[0].
>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 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...
>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 a…
It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.
What's the view that TypeScript is the modern Javascript?
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…
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].
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…