31–40 of 122 posts
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?
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.
Earlier quoted context omitted.
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.turnOnNefariousPriv…
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.
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).
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 Webp…
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.
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 Webp…
> 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 quit…
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 Webp…
> 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 quit…
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.
Earlier quoted context omitted.
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 f…
Have you read this article? https://medium.com/javascript-scene/the-typescript-tax-132ff... I use TypeScript. It's not all rosy.
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 Webp…
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.
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 Webp…
> 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 quit…
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
What's the view that TypeScript is the modern Javascript?
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 f…
i like that qualification :)
most likely typescript is still a very small minority given how large the javascript world is