ECMAScript 2015 Approved(ecma-international.org)
ecma-international.org
ECMAScript 2015 Approved
http://www.ecma-international.org/publications/standards/Ecma-262.htm
16 comments
You could write that code to be a little more human readable. That appears to be complicated for the sake of being complicated. Elegance doesn't have to be complexity, or trying to write as few lines as possible.
http://photos3.meetupstatic.com/photos/event/4/b/c/2/600_436...
http://photos3.meetupstatic.com/photos/event/4/b/c/2/600_436...
Looks like idiomatic JS code to me.
For some reason naming your functions in JavaScript often get meet with strange looks. My colleague just love anonymous functions.
I think that at least some like the callback hell, because they think it makes them look clever.
I think that at least some like the callback hell, because they think it makes them look clever.
'Pyramid of Doom'?
Sounds more like something from a certain python web framework to me. ie:
http://docs.pylonsproject.org/en/latest/_downloads/pyramid-a...
Sounds more like something from a certain python web framework to me. ie:
http://docs.pylonsproject.org/en/latest/_downloads/pyramid-a...
I'd question the need for that many nested callbacks when you're already using Promises.
> "a small app built on ec6/7 babel, npm, jspm, system.js, aurelia, gulp, etc"
Part of the problem with the Javascript ecosystem is that you have to use so many different tools/libraries to create a "simple" app.
Part of the problem with the Javascript ecosystem is that you have to use so many different tools/libraries to create a "simple" app.
Eh...
Not a lot of people writing apps in Java, C, Ruby, or Python without using libraries, build tools, test runners, Makefile, frameworks, package managers, etc.
To use ES7 in production today, you need babel. And nothing is stopping you from writing a simple app in ES7, running it through babel, and shipping it. You could think of it as an updated compiler or switching to PyPy.
You probably do want a build step to lint, minify, and concatenate your code, and (if targeting the browser) to turn modules into something the browser can deal with. Which basically means webpack (or gulp+browserify), but much like a traditional Makefile (which is basically all it is), you write the webpack config once and then you're done.
And finally you probably want a framework, and probably a package manager to install it. Not a lot of people writing webapps in any language without frameworks. And downloading tarballs off sourceforge is very 1990s. So, a package manager. Does it matter if it's called gem, or npm? I don't think so.
All OP has done is listed some parts of his development environment that might just be implied with another language and framework. If someone talks about "a small app built on rails", by implication they're using a massive pile of bits. Just because you don't say "a small app built on ruby, gems, rails, rake, etc." doesn't mean they don't exist. (Hell, don't rails apps include coffeescript by default these days?)
If there's a problem, it's that "the browser as a runtime target doesn't lend itself to creating simple apps" (hence why you need all those libraries, frameworks, and elaborate build tools). But that's not really the fault of JS...and it's not like deskop apps or Android apps are any better. The last time I wrote a "simple" app (with no libraries or tooling) was in an intro to programming course in the 90s; I don't think that was a realistic example of how people wrote real applications even then.
Not a lot of people writing apps in Java, C, Ruby, or Python without using libraries, build tools, test runners, Makefile, frameworks, package managers, etc.
To use ES7 in production today, you need babel. And nothing is stopping you from writing a simple app in ES7, running it through babel, and shipping it. You could think of it as an updated compiler or switching to PyPy.
You probably do want a build step to lint, minify, and concatenate your code, and (if targeting the browser) to turn modules into something the browser can deal with. Which basically means webpack (or gulp+browserify), but much like a traditional Makefile (which is basically all it is), you write the webpack config once and then you're done.
And finally you probably want a framework, and probably a package manager to install it. Not a lot of people writing webapps in any language without frameworks. And downloading tarballs off sourceforge is very 1990s. So, a package manager. Does it matter if it's called gem, or npm? I don't think so.
All OP has done is listed some parts of his development environment that might just be implied with another language and framework. If someone talks about "a small app built on rails", by implication they're using a massive pile of bits. Just because you don't say "a small app built on ruby, gems, rails, rake, etc." doesn't mean they don't exist. (Hell, don't rails apps include coffeescript by default these days?)
If there's a problem, it's that "the browser as a runtime target doesn't lend itself to creating simple apps" (hence why you need all those libraries, frameworks, and elaborate build tools). But that's not really the fault of JS...and it's not like deskop apps or Android apps are any better. The last time I wrote a "simple" app (with no libraries or tooling) was in an intro to programming course in the 90s; I don't think that was a realistic example of how people wrote real applications even then.
That's true to an extent, but gulp/babel are something you setup once and forget. npm is a package manager, the others are libraries. It's no different than saying that someone used pip, Flask, Requests, and xlrd for a Python project. They're just libraries.
Once you do it once, its done. Also, tons of scaffolds out there to choose from / tweak. This sort of flexibility is a good thing.
Eh. JS is a very useful language but something has to get us out of this explosion of tools eventually.
For the last couple of projects I've worked on, I've had to choose:
- The scaffold
- The build tool
- The actually-good language variant that compiles to JS that a browser can run
- The tool that makes the build tool work with the scaffold
- The tool that makes the build tool work with the language variant
And by the time I make any progress, one of those has made a compatibility-breaking update, or even been abandoned and replaced by something better.
Great that things keep getting better, but at some point I want to get off the ride.
For the last couple of projects I've worked on, I've had to choose:
- The scaffold
- The build tool
- The actually-good language variant that compiles to JS that a browser can run
- The tool that makes the build tool work with the scaffold
- The tool that makes the build tool work with the language variant
And by the time I make any progress, one of those has made a compatibility-breaking update, or even been abandoned and replaced by something better.
Great that things keep getting better, but at some point I want to get off the ride.
That's an interesting definition of "had to".
If you don't like the complexity all that tooling and boilerplate adds to your project, why not just write your application in vanilla CSS, HTML and JavaScript? It still works fine.
Most of the time I'd much rather work with imperfect but standard tools than waste time learning the "hot new stuff" and constantly fix what flighty other developers break or abandon. Framework churn is a symptom of invented problems that don't need solving.
If you don't like the complexity all that tooling and boilerplate adds to your project, why not just write your application in vanilla CSS, HTML and JavaScript? It still works fine.
Most of the time I'd much rather work with imperfect but standard tools than waste time learning the "hot new stuff" and constantly fix what flighty other developers break or abandon. Framework churn is a symptom of invented problems that don't need solving.
Because vanilla CSS, HTML and JavaScript sucks? Hence all the tools, frameworks and scaffolds...
It would be helpful to quantify "sucks" in there. Otherwise it's simply an opinion. As an exercise, just write your own XMLHttpRequest interface. It will take you about 20 lines or less, even doing it in the most naive way. I'm serious, go do this. It will make anyone a better developer.
Frameworks rarely give you much for all the baggage that comes with it. I say this as an angular user specifically, but I haven't used any others that don't have this problem.
It might, MIGHT, be that these standard setups suck, but if they do, adding a complicated toolchain without a reason doesn't seem like a very pragmatic approach to why the suck or how to fix them.
Frameworks rarely give you much for all the baggage that comes with it. I say this as an angular user specifically, but I haven't used any others that don't have this problem.
It might, MIGHT, be that these standard setups suck, but if they do, adding a complicated toolchain without a reason doesn't seem like a very pragmatic approach to why the suck or how to fix them.
I wrote my own XMLHttp interface several times back before jquery came out thanks. No, it's not useful writing one, I know because I was there back in the IE6 days.
My point was simple, if it didn't suck, there wouldn't be all these workarounds, shims, essential libraries that every website uses, half bastardised coffee/live/closure/whatever scripts, gulps, glubs, and 1500 different templating languages.
My point was simple, if it didn't suck, there wouldn't be all these workarounds, shims, essential libraries that every website uses, half bastardised coffee/live/closure/whatever scripts, gulps, glubs, and 1500 different templating languages.
And last but not least, the benefits that using a compiler provides.
You can get off the ride right now.
Every language these days has its "stack" for development. Sure you could sit down with vim and javac and write a "simple app". But once you use Gradle/Maven to handle dependencies and build process. Once you use a nice unit testing framework... Why on earth would you not just fire it up and tune it for every project? Ruby, C# and every other language I've used has this "development stack" mentality, and now when I try out new languages, I research setting up the stack first!
> javac and write a "simple app". But once you use Gradle/Maven to handle dependencies and build
Using Gradle or Maven to handle builds for Java require you to learn another syntax and vocabulary, i.e. Groovy or XML. In the case of Gradle/Groovy, if you set up the stack first, you'd need to learn another programming language before you even write your "simple app" in your target language Java, which is tedious at best. Perhaps Ruby, C#, and those other languages you've used use the target language for the build which makes more sense.
Using Gradle or Maven to handle builds for Java require you to learn another syntax and vocabulary, i.e. Groovy or XML. In the case of Gradle/Groovy, if you set up the stack first, you'd need to learn another programming language before you even write your "simple app" in your target language Java, which is tedious at best. Perhaps Ruby, C#, and those other languages you've used use the target language for the build which makes more sense.
Compare to go, where you can go a very long way using "go get", "go build", "go run" etc.
Node.js apps can be even easier than that (only two necessary commands): `npm install` for `go get` and `node [script.js]` for `go run`.
If you want to do compilation there are various solutions available to you as well!
If you want to do compilation there are various solutions available to you as well!
Actually you have `npm run named-command` too so you could get a go like thing going.
The start and test scripts are special, and can be called directly.
For an idiomatic node app, you'd clone the repo, then type `npm install` to get the dependencies, `npm test` to make sure the tests pass, and then `npm start` to run it.
For an idiomatic node app, you'd clone the repo, then type `npm install` to get the dependencies, `npm test` to make sure the tests pass, and then `npm start` to run it.
When I made the transition over to JS from another language a few years ago, this was exactly how I did it; I expected to have some kind of system in place that provided the tooling I needed to get the language that I wanted, and immediately landed on Node, preprocessors, etc, easing the transition immensely.
The list of things you're seeing above appears to be a compiler, two package managers, a build runner, a module implementation, and an app framework. Which languages do you work in building apps of any complexity where you don't need any of those?
Saying you "have to use" any of those things (except for the compiler/runtime) is an overstatement at best. As in other languages, if something solves a problem for you, use it. If not, well, you don't have to use it, unless you're stuck on a team who uses things because This Is How We Do Things Now(TM), which is not a JS specific affliction.
I think one could reasonably argue that two package managers is not only overkill it's a problem (in fact, I sometimes do argue that browser-specific package management shouldn't be part of projects I'm on), and that most languages don't have to deal with competing module implementations because they came baked in (fair).
I think one could also possibly argue that the explosion of JS libs/tools seems to be near-cambrian in its proportions and it's hard to keep up with, but from where I sit this looks like a consequence of (a) the expanding reach of the browser as a platform (b) second-order magnifying effects of popularity (c) where npm is involved a tilt towards smaller libraries and lots of dependencies and (d) the fact that making a library is a way to make a name for yourself (incentivizing lots of libraries).
Saying you "have to use" any of those things (except for the compiler/runtime) is an overstatement at best. As in other languages, if something solves a problem for you, use it. If not, well, you don't have to use it, unless you're stuck on a team who uses things because This Is How We Do Things Now(TM), which is not a JS specific affliction.
I think one could reasonably argue that two package managers is not only overkill it's a problem (in fact, I sometimes do argue that browser-specific package management shouldn't be part of projects I'm on), and that most languages don't have to deal with competing module implementations because they came baked in (fair).
I think one could also possibly argue that the explosion of JS libs/tools seems to be near-cambrian in its proportions and it's hard to keep up with, but from where I sit this looks like a consequence of (a) the expanding reach of the browser as a platform (b) second-order magnifying effects of popularity (c) where npm is involved a tilt towards smaller libraries and lots of dependencies and (d) the fact that making a library is a way to make a name for yourself (incentivizing lots of libraries).
it's called don't reinvent the wheel and let you focus on real problems while delegating the rest to 3rd party libraries!
I actually like this feature of Javascript. Much better than being stuck with a small number of monolithic tools or rarely-updated standard libraries, in my experience.
You don't have to do anything. I think there are more people in the world that like to use tools for the sake of using tools that it would give one the impression that all of this tooling is a necessity. It's not.
It's even better if you use `yield` or `async/await`:
activate(params) {
let fabric_response = yield this.http.get(`${ this.url_base }/fabrics`)
return fabric_response.content.map( fabric => {
let cluster_response = yield this.http.get(`${ this.url_base }/fabrics/${ fabric.name }/clusters`)
if(fabric.clusters_exist) {
this.fabrics.push({"name": fabric.name, "clusters": cluster_response.content});
}
});
}
I was at a meetup yesterday where Axel Rauschmayer explained what's new in ES6, and especially the use of generators and yield was to me a mindblowing new way of programming.
Yours is a nice example of using yield to turn asynchronous code synchronous.
Yours is a nice example of using yield to turn asynchronous code synchronous.
Yikes! Don't blame ES6 for this mess :P
I've been away from JS for about 10 months and... cool, but, fuck, that changed quickly. Time to get caught back up to speed. Is ES6 now actually viable, in that it's supported by most users' browsers? If not, are there popular compilers for ES5?
"Everyone" is using Babel now. A lot of ES6 features are making their way into browsers and node, but there's so much variation that a transpile step is needed. Babel is nice but currently quite slow. Babel has a REPL you can play with here: http://babeljs.io/repl/#?experimental=true&evaluate=true&loo...
There's currently a issue for "speed": https://github.com/babel/babel/issues/1486. Looks like it complied ember core from 50s to 18s now.
Yep, saw that. I don't think it's enough of an issue to not use Babel (my team uses it and we all think it's great), but it is suboptimal.
Whoa, thanks for introducing me to Babel. It looks like user plugins could be wildly, astonishingly powerful for doing compile-time code execution.
Correct. One of my favourite at the moment is `babel-plugin-rewire`, which is a neat replacement for `rewire` -- allowing easy unit testing in full isolation by hijacking the `import` statements :)
[0] https://www.npmjs.com/package/babel-plugin-rewire
[1] https://www.npmjs.com/package/rewire
[0] https://www.npmjs.com/package/babel-plugin-rewire
[1] https://www.npmjs.com/package/rewire
Just started using that yesterday, and it's lovely.
In this side of the galaxy still looks like JSF with RichFaces and ASP.NET WebForms.
You can use Typescript as well for an alternative to Babel, it doesn't have all the features Babel has (like async/await) but they are planned. And you get types at the same time.
To answer your browser compatibility question: https://kangax.github.io/compat-table/es6/
[deleted]
[deleted]
Nit: single line lambdas can be written like `a => a + 1` instead of `a => { return a + 1 }`. Cuts the amount of bracket nesting.
After working with es6 for a bit (with babel), I still think I prefer CoffeeScript mostly because it's annoying to ensure brackets/parenthesis are closed properly.
Its funny, I used to really enjoy CoffeeScript but since Babel / ES6 has come out I can't stand it anymore! ES6 has just the right amount of syntax, with lots of optionals too (semicolons, no brackets when writing function expressions, etc).
I compile JS files to CoffeeScript now only for the readability boost when I need to understand the code very quickly without all those parentheses or brackets getting in my way.
>I'm currently working on a small app built on ec6/7 babel, npm, jspm, system.js, aurelia, gulp, etc. It's been a great experience so far.
Oh, the irony...
Oh, the irony...
Actually I do recognize those final six lines. That's what I used to get on my terminal screen decades ago when I was trying to pull the phone out of the accoustic coupler and hang up.
It's funny to me, I used to merely tolerate JavaScript... I came from Ruby (and PHP/Java/C# before that) where you could create these super complex control flow structures and JavaScript felt so verbose and unwieldy and limited.
I mean, no inheritance? No method_missing? How do you write humane, readable DSLs with just functions and prototypes?
I've explored all kinds of tricks since then: OO libraries, promises, fibers, CoffeeScript classes and all its other sugar.
What's interesting is I've swung fully back in the other direction. I find myself increasingly drawn to very simple, very JavaScripty JavaScript. Functions. Variables. Constructors. Prototypes. Closures. Arrays. Objects. I think almost all of the new JavaScript features are more trouble than they're worth.
Take promises for example. Here's some junky callbacky JavaScript:
That's what power is. That's why people love promises, you have power to do all manner of outlandish control flow. Except I really don't want to have to debug your bizarre circus of promises.
Don't get me wrong, I am certainly capable of debugging your circus of promises. I just really would prefer not to.
And anyway there's a way easier solution. Because JavaScript uses function scope, you can just do this:
Of course if this was CoffeeScript, your stacktrace wouldn't have function names because CoffeeScript threw away that feature in exchange for being able to type "->" instead of "function".
I've noticed this pattern over and over: someone gets frustrated because JavaScript doesn't give you insane tools to quickly spin up bafflingly complex flow structures. They find this frustrating, because they're used to baffling flow structures from all of the crappy code they've been forced to get comfortable with, so they write some insane library that lets you do crazy stuff in JavaScript.
The same thing happened to me in Ruby. I was so entranced by the power and magic of DSLs that I was constantly looking for excuses to return chainable objects from functions and all of this stuff. I would build things like that in production code, and feel proud of myself that I made this super powerful thing with a complicated implementation and a simple, prose-like interface.
But almost every time, after living with the interface for a while, I would realize that I could've solved the problem with just functions, literals, and arrays, and structs if I had actually taken the time to figure out the right abstractions.
Less and less do I think I need some fancy new kind of function. More and more I think I need to be more thoughtful about what the function actually does.
I mean, no inheritance? No method_missing? How do you write humane, readable DSLs with just functions and prototypes?
I've explored all kinds of tricks since then: OO libraries, promises, fibers, CoffeeScript classes and all its other sugar.
What's interesting is I've swung fully back in the other direction. I find myself increasingly drawn to very simple, very JavaScripty JavaScript. Functions. Variables. Constructors. Prototypes. Closures. Arrays. Objects. I think almost all of the new JavaScript features are more trouble than they're worth.
Take promises for example. Here's some junky callbacky JavaScript:
libraryStuff(function() {
moreLibraryStuff(function() {
thirdLibraryStuff(function() {
console.log("done!")
})
})
})
libraryStuff()
.then(moreLibraryStuff)
.then(thirdLibraryStuff)
.then(function() {
console.log("done!")
})
That's what power is. That's why people love promises, you have power to do all manner of outlandish control flow. Except I really don't want to have to debug your bizarre circus of promises.
Don't get me wrong, I am certainly capable of debugging your circus of promises. I just really would prefer not to.
And anyway there's a way easier solution. Because JavaScript uses function scope, you can just do this:
libraryStuff(yourResponse)
function yourResponse() {
moreLibraryStuff(yourNextResponse)
}
function yourNextResponse() {
thirdLibraryStuff(finish)
}
function finish() {
console.log("done!")
}
Of course if this was CoffeeScript, your stacktrace wouldn't have function names because CoffeeScript threw away that feature in exchange for being able to type "->" instead of "function".
I've noticed this pattern over and over: someone gets frustrated because JavaScript doesn't give you insane tools to quickly spin up bafflingly complex flow structures. They find this frustrating, because they're used to baffling flow structures from all of the crappy code they've been forced to get comfortable with, so they write some insane library that lets you do crazy stuff in JavaScript.
The same thing happened to me in Ruby. I was so entranced by the power and magic of DSLs that I was constantly looking for excuses to return chainable objects from functions and all of this stuff. I would build things like that in production code, and feel proud of myself that I made this super powerful thing with a complicated implementation and a simple, prose-like interface.
But almost every time, after living with the interface for a while, I would realize that I could've solved the problem with just functions, literals, and arrays, and structs if I had actually taken the time to figure out the right abstractions.
Less and less do I think I need some fancy new kind of function. More and more I think I need to be more thoughtful about what the function actually does.
The only downside seems that if one uses new keywords like "class" one has to use a transpiler back to JS5 to avoid syntax errors in IE11 and other older still supported browsers&devices that will never receive an update (like Android 2x/4, Blackberry, WinPhone7/8, etc).
A fallback solution like JQuery isn't possible for new keywords. Try-catch keywords were previously introduced too, but are rarely used because their implementation is known to be slow. Beside that JS5 code with fallback functions still works fine in very old browsers like IE5.
A fallback solution like JQuery isn't possible for new keywords. Try-catch keywords were previously introduced too, but are rarely used because their implementation is known to be slow. Beside that JS5 code with fallback functions still works fine in very old browsers like IE5.
i dislike the import part. without writing the from part first you can't evaluate the import..
Yeah, the creator of TypeScript was complaining about this in a presentation. I think the existing syntax "import X from Y" reads more naturally than "from Y import X" but obviously the latter is better for tooling and autocomplete/intellisense. Oh well!
For anyone interested in using ES2015/ES6 in production, I'd highly recommend checking out jspm and SystemJS.
It handles all the transpilation work for you (at runtime for development, or during a manual build/bundling for production) using either Babel, Traceur or Typescript, and allows you to seamlessly use ES6 everywhere in your code and even load third party code on Github and NPM as ES6 modules.
https://github.com/jspm/jspm-cli
https://github.com/systemjs/systemjs
EDIT: Some more info copied from another post:
SystemJS (jspm's module loader) has the following main advantages compared to competing module loaders:
- Able to load any type of module as any other type of module (global, CommonJS, AMD, ES6)
- Can handle transpilation and module loading at runtime without requiring a manual build step
However, jspm itself is primarily a package manager. Its main advantages over existing package management solutions include:
- Tight integration with the SystemJS module loader for ES6 usage
- Maintains a flat dependency hierarchy with deduplication
- Ability to override package.json configuration for any dependency
- Allows loading of packages from just about any source (local git repos, Github, NPM) as any module format
It handles all the transpilation work for you (at runtime for development, or during a manual build/bundling for production) using either Babel, Traceur or Typescript, and allows you to seamlessly use ES6 everywhere in your code and even load third party code on Github and NPM as ES6 modules.
https://github.com/jspm/jspm-cli
https://github.com/systemjs/systemjs
EDIT: Some more info copied from another post:
SystemJS (jspm's module loader) has the following main advantages compared to competing module loaders:
- Able to load any type of module as any other type of module (global, CommonJS, AMD, ES6)
- Can handle transpilation and module loading at runtime without requiring a manual build step
However, jspm itself is primarily a package manager. Its main advantages over existing package management solutions include:
- Tight integration with the SystemJS module loader for ES6 usage
- Maintains a flat dependency hierarchy with deduplication
- Ability to override package.json configuration for any dependency
- Allows loading of packages from just about any source (local git repos, Github, NPM) as any module format
I am struggling to find the difference between jspm and npm + webpack or npm + grunt/gulp + browserify. Is it just conventions around ES6?
FYI, ECMAScript 2015 is also known as ES6.
And JavaScript Harmony
Because of their switch to use a year instead of a version number, do they plan on doing these ES enhancements more often?
Yes. Because of how rapidly Javascript is moving, they want it to be more modular in its releases instead of waiting multiple years in between.
Yes, though as I understand, none of the later ones should be as big as ES6/2015. You can't accumulate that many changes in a single year.
It's a bit like WHAT WG's change of HTML5 to HTML (the "living standard"), but less drastic.
They are providing a official HTML version, alongside the PDF version.
http://www.ecma-international.org/ecma-262/6.0/index.html
http://www.ecma-international.org/ecma-262/6.0/index.html
Can someone explain what this means for the browser ecosystem? What are the next steps to integration?
Depending on the browser, lots of things are already implemented, either generally available (e.g. `Promise`) or behind flags (e.g. fat arrows). This announcement just accelerates the adoption pipeline by reducing worry about spec changes.
I think it means we can now pine over EcmaScript 7.
Don't pine, just use Babel ;) http://kangax.github.io/compat-table/es7/
It's underway already. Check out Kangax's amazing work here [0]
[0] ES6 COMPAT TABLE: https://kangax.github.io/compat-table/es6/
[0] ES6 COMPAT TABLE: https://kangax.github.io/compat-table/es6/
This is a good overview in my opinion: https://babeljs.io/docs/learn-es2015/
What does it mean for a spec to be approved? Is it like a peer-review?
Yes - TC39 is responsible for updating the standard (http://www.ecma-international.org/memento/TC39.htm), meaning that they all voted to approve the current draft ES2015. You can see several years of the drafts here http://wiki.ecmascript.org/doku.php?id=harmony:specification...
And TC = Technical Committee.
What approval means here is that it was ratified by the ECMA General Assembly. The move by TC-39 to send ECMAScript 2015 to the GA was voted on at the last TC-39 meeting around a month ago.
Can someone make a resumé ?
I made a very succinct summary here: http://espadrine.github.io/New-In-A-Spec/es2015/
There is also this, slightly more in-depth: git.io/es6features
There is also this, slightly more in-depth: git.io/es6features
How long before we see widespread browser support?
With transpilers like Babel you can fantastic browser support today.
Oddly, it would be silly to transpile to ES5 forever. By the time ES6 support is widespread, we'll be transpiling from ES8, and so on.
yes, but I expect that between feature checking and target platform configuration in the transpilers, virtually all of that will be transparent for the dev.
Today marks an important day for us all :)
oh brother does their (`<table>` based) web layout need an update!
I do a lot of web design and you often have to use table for compatibility reasons or straight up no other way is supported (vertical alignment or same height for example, even if flexbox does it now IE 8 doesn't support it)
These days you can use CSS 'display: table;' if you still need the table layout engine and don't want to use a non-semantic table tag. It's supported in ie 8+. If you're still supporting ie7... well, I feel bad for you :)
ES2016 is proposed to be based on Ecmarkup, a more modern system which will let us collaborate on Github more easily, rather than a canonical MS Word document on the editor's computer.
but...whatever happened to es6? ;)
Sorry, I accidentally downvoted you with a misclick :(
I do this rather frequently by mistake. I, like you, try to point out my error so the OP doesn't wonder why they are being downvoted.
Another problem is that I often upvote articles by scrolling on my phone. In addition to providing false signal, this has the unfortunate side effect of polluting my "saved stories".
I wish there was a mechanic to change votes after submission (even if the ability to change your vote was only momentary).
Do pg, et al. accept PRs?
Another problem is that I often upvote articles by scrolling on my phone. In addition to providing false signal, this has the unfortunate side effect of polluting my "saved stories".
I wish there was a mechanic to change votes after submission (even if the ability to change your vote was only momentary).
Do pg, et al. accept PRs?
I loaned you one of mine.
When will be able to undownvote?
At last JavaScript is enjoyable and doesn't completely suck.
It's about fricken time! Talk about procrastination!
Now I have to wait for browsers to get off their little snowflake asses and update. Oh wait then there is all those paranoids who use WinXP with IE8. Damn it, I'll be dead by the time this stuff is available universally.
Now I have to wait for browsers to get off their little snowflake asses and update. Oh wait then there is all those paranoids who use WinXP with IE8. Damn it, I'll be dead by the time this stuff is available universally.
At some point, you just need to stop caring about those people. I know some of you can't professionally, but personally, there's no need to even pretend to support IE <= 11. If they want to run an old os and old browser, they don't get to use my service. No sweat off my balls.
Finding actual numbers seems to be harder than it should be, but this page:
https://www.netmarketshare.com/browser-market-share.aspx?qpr...
...suggests that IE 8, 9 and 10 combined have about ~28% market share. Of course, I don't know what they're measuring --- somewhere like github is going to see a very different balance of browsers than, say, Amazon --- but that's a hell of a lot, roughly equal to the IE 11 market share. I'd say that's way too much to dismiss out of hand.
Edit: I've since found this: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Su...
That suggestions that netmarketshare are consistently measuring IE high --- other people show IE at about half that, and Chrome at about double what netmarketshare do. Which, of course, makes it even more important to find out who your audience are before giving up support for old browsers.
https://www.netmarketshare.com/browser-market-share.aspx?qpr...
...suggests that IE 8, 9 and 10 combined have about ~28% market share. Of course, I don't know what they're measuring --- somewhere like github is going to see a very different balance of browsers than, say, Amazon --- but that's a hell of a lot, roughly equal to the IE 11 market share. I'd say that's way too much to dismiss out of hand.
Edit: I've since found this: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Su...
That suggestions that netmarketshare are consistently measuring IE high --- other people show IE at about half that, and Chrome at about double what netmarketshare do. Which, of course, makes it even more important to find out who your audience are before giving up support for old browsers.
> That suggestions that netmarketshare are consistently measuring IE high
That's because those tables arae
StatCounter (and the W3Counter/Wikimedia things in the tables you cite) are measuring website visits.
NetApplications/netmarketshare is measuring unique users.
So what that data shows is likely several things going on at once:
1) Chrome (and Firefox, for that matter, if you look at te the tables)) users load more webpages than IE users.
2) Chrome does some webpage prerendering stuff that can get counted as "visits" if you're not very careful; not sure how well StatCounter accounts for this.
3) Likely some differences in the actual base data, though I expect this is really minor compared to item #1.
Of course I couldn't agree more with your general claim that web-wide statistics are a poor replacement for specific statistics for a particular site. But even there the question of "visits" vs "unique users" might be an important one.
That's because those tables arae
StatCounter (and the W3Counter/Wikimedia things in the tables you cite) are measuring website visits.
NetApplications/netmarketshare is measuring unique users.
So what that data shows is likely several things going on at once:
1) Chrome (and Firefox, for that matter, if you look at te the tables)) users load more webpages than IE users.
2) Chrome does some webpage prerendering stuff that can get counted as "visits" if you're not very careful; not sure how well StatCounter accounts for this.
3) Likely some differences in the actual base data, though I expect this is really minor compared to item #1.
Of course I couldn't agree more with your general claim that web-wide statistics are a poor replacement for specific statistics for a particular site. But even there the question of "visits" vs "unique users" might be an important one.
Self-replying, since I have no idea what happened to the comment text I _meant_ to write and I can't edit it now. What I meant to say at the beginning of my comment was:
That's because those tables are comparing apples and oranges. StatCounter (and the W3Counter/Wikimedia things in the tables you cite) are measuring website visits. NetApplications/netmarketshare is measuring unique users.
That's because those tables are comparing apples and oranges. StatCounter (and the W3Counter/Wikimedia things in the tables you cite) are measuring website visits. NetApplications/netmarketshare is measuring unique users.
That changes a lot if your target market is big enterprise customers. Oh you don't support IE9? Well say goodbye to that market share.
You just need to find a tent-pole feature and a reason to use it.
For example: "This browser requires WebGL" -> IE11 and up.
For example: "This browser requires WebGL" -> IE11 and up.
One of the reasons why I'll go with Dart or TypeScript or whatever anyway. ;)
Or just use a transpiler.
Here's an example of what it looks like: http://pastebin.com/raw.php?i=yEB4mrty
As someone who usually works with C, Scala, and Java -- I'm currently working on a small app built on ec6/7 babel, npm, jspm, system.js, aurelia, gulp, etc. It's been a great experience so far.