3 ms·

I still code JS like it's 1999 :P Most new updates are syntax sugar. ES5 added a ton of stuff that are useful, for example binary buffers which is useful for op

by z3t4 8y ago

I still code JS like it's 1999 :P Most new updates are syntax sugar. ES5 added a ton of stuff that are useful, for example binary buffers which is useful for optimization. When people say "modern" JS though, they mean the syntax sugar from ES6 and ES7. I actually prefer the "old school" style. I hate how the language has become more complex, but I guess it's an evil necessary in order to please everyone. If you for example are into functional programming you will love arrow functions. If you never liked async or functional programming you will like async/await. If you like meta programming you can use new tools like Babel to come up with your own syntax sugar. The tooling and ecosystem for JS has really exploded. If you haven't already, take a look at Node.JS.

kls 8y ago
While I agree some of that sugar does a lot to clean up a lot of boilerplate code that we used to have to write, such as arrow functions retaining this in scope without having to do binds or "self = this" stuff we used to have to do. as well as adding let which allows you to properly scope variables. It is sugar and the language was perfectly usable without them but they sure do tidy up the code we write.
commandlinefan 8y ago
For me, it's not really so much the JS syntax - I agree it's mostly syntactic sugar and if I really want to use something like, say, "map", I can always do something like: Array.prototype.map = Array.prototype.map || function(f) { var a = []; for (var i = 0; i < this.length; i++) {a[i] = f(this[i]);} return a;} What I'm still trying to get my head around is this whole new ecosystem of bower, webpack, babel, eslint, npm, node, grunt, jQuery, angular, react, vue, yarn, parcel, browserify, gulp, etc... and apparently Javascript has modules now?
- z3t4 8y ago
  Around year 2000 "AJAX" started to get popular which allows you to make HTTP requests from JavaScript (JS). "AJAX" makes it possible to have upload progress bars, or have "new messages" badges without reloading the page. "AJAX" made it possible to move back-end code into front-end JavaScript. To make the transition easier, front-end JavaScript frameworks was invented. AJAX was initially implemented differently between browsers, and jQuery became popular, as it added abstractions that work on all major browsers. In 2011 Websockets was made into a standard, which set the new direction on how you create web apps. Instead of having a back-end in Perl, PHP, CGI, etc, which renders the HTML on the server, the DOM is now rendered on the client, and the client communicate to the server via REST/HTTP or Websockets. This accelerated the growth of front-end frameworks as more and more started to port their back-end rendering to the front-end. In 2008 Google's Chrome browser was released which had a very fast JS engine called v8. And about that time a mathematician named Ryan thought that in order to have a performant web server, it need to be async ... While JS on the server was already a thing, it was not async. Ryan took the v8 JS engine from Chrome. and made a fully async library/API for IO on the server. He called it Node.JS. And it become popular. The "CommonJS" module system became the standard module system in Node.JS. NPM was created to host modules/packages. Webpack makes it possible to convert Node.js modules to run in the browser. Grunt was picked as the "make" system for Node.JS modules, and I think Gulp is a competitor to Grunt. Bower and Yarn sprung up as competitors to NPM. Then in 2015 the EcmaScript (ES) committee standardized JS modules, but incompatible with Node.JS module system, missing features such as lexical scoping, dynamic import and lazy loading available in the NodeJS module system. As a result Node.JS has still not implemented ES modules. But you can use Babel to transpile the code. Personally I try to avoid transpilation and front-end framworks, and only use vanilla JS. Node.JS is a really good back-end JS framework. There's a module for everything you need. And all of them are free and open source!

by z3t4 8y ago

kls 8y ago

While I agree some of that sugar does a lot to clean up a lot of boilerplate code that we used to have to write, such as arrow functions retaining this in scope without having to do binds or "self = this" stuff we used to have to do. as well as adding let which allows you to properly scope variables. It is sugar and the language was perfectly usable without them but they sure do tidy up the code we write.

commandlinefan 8y ago

For me, it's not really so much the JS syntax - I agree it's mostly syntactic sugar and if I really want to use something like, say, "map", I can always do something like: Array.prototype.map = Array.prototype.map || function(f) { var a = []; for (var i = 0; i < this.length; i++) {a[i] = f(this[i]);} return a;} What I'm still trying to get my head around is this whole new ecosystem of bower, webpack, babel, eslint, npm, node, grunt, jQuery, angular, react, vue, yarn, parcel, browserify, gulp, etc... and apparently Javascript has modules now?

z3t4 8y ago
Around year 2000 "AJAX" started to get popular which allows you to make HTTP requests from JavaScript (JS). "AJAX" makes it possible to have upload progress bars, or have "new messages" badges without reloading the page. "AJAX" made it possible to move back-end code into front-end JavaScript. To make the transition easier, front-end JavaScript frameworks was invented. AJAX was initially implemented differently between browsers, and jQuery became popular, as it added abstractions that work on all major browsers. In 2011 Websockets was made into a standard, which set the new direction on how you create web apps. Instead of having a back-end in Perl, PHP, CGI, etc, which renders the HTML on the server, the DOM is now rendered on the client, and the client communicate to the server via REST/HTTP or Websockets. This accelerated the growth of front-end frameworks as more and more started to port their back-end rendering to the front-end. In 2008 Google's Chrome browser was released which had a very fast JS engine called v8. And about that time a mathematician named Ryan thought that in order to have a performant web server, it need to be async ... While JS on the server was already a thing, it was not async. Ryan took the v8 JS engine from Chrome. and made a fully async library/API for IO on the server. He called it Node.JS. And it become popular. The "CommonJS" module system became the standard module system in Node.JS. NPM was created to host modules/packages. Webpack makes it possible to convert Node.js modules to run in the browser. Grunt was picked as the "make" system for Node.JS modules, and I think Gulp is a competitor to Grunt. Bower and Yarn sprung up as competitors to NPM. Then in 2015 the EcmaScript (ES) committee standardized JS modules, but incompatible with Node.JS module system, missing features such as lexical scoping, dynamic import and lazy loading available in the NodeJS module system. As a result Node.JS has still not implemented ES modules. But you can use Babel to transpile the code. Personally I try to avoid transpilation and front-end framworks, and only use vanilla JS. Node.JS is a really good back-end JS framework. There's a module for everything you need. And all of them are free and open source!