Echo JS 0.11.0

<~> comments 10 days ago. link 2 points
It may make things appear more concise and even simpler in the short term, but over a long term it impairs readability of your code. It also increases the cognitive load, in bigger `with` block you would need to constantly keep in mind what object is being used, without it you explicitly reference the object so it's clear.

It can also lead to confusing commits e.g. if you change the body of a `with` expression to access new child properties of the object you pass, it won't be very clear in the commit where those values are coming from because the `with` statement will likely not be visible in the diff.

If you don't want to explicitly refer to a long named variable or a long property chain, I would recommend assigning it to a concisely named variable rather than using `with` 618 days ago. link 6 points
This article completely misses the biggest advantage of NodeJS - being able to run the same code both back and front end.

Sure, most features you're using Babel for are also available via enabling some v8 flags, but you can't do that on the client side.

With Babel + Webpack you can have largely the same codebase on both frontend and backend, saving huge amounts of time and effort otherwise wasted writing separate logic for the browser, and allows you to manage your front-end dependencies with good ol' npm, instead of doing so manually by hand. 623 days ago. link 0 point
Can confirm. I'm a web developer with 7 years commercial experience now. I don't have a single formal qualification or certificate.

I got into the industry by freelancing for small local businesses to build up a portfolio which I then used to get my foot in the door at a web agency as a full time developer, then just took it from there with that experience. 674 days ago. link 1 point
I like this, would make a good minimal alternative for building DOMs when using something like cycle.js 1045 days ago. link 2 points
Yuck, it's running on WordPress?

I'd expect a site named to be running JS itself. Why no nodejs, iojs or meteor? 1106 days ago. link 3 points
Everyone seems to be exaggerating the likelihood of incompatibility, as far as I'm aware io.js is simply supposed to be a bleeding-edge version of node. There is no need for community library authors to test on or support io.js, because in theory io.js should be fully backwards-compatible with node.js other than the incredibly unlikely circumstance that io.js adopts a version of V8 which deprecates features used in node's version of V8 or changes it's API in a non-backwards compatible way, which would be no different from the incompatibilities you'd encounter by using a version of node to run an app written for an older version of node.

Forking node allows people to use new/experimental V8 features/improvements while still tapping in to the already massive node ecosystem and alleviates those users from having to compile their own node/V8 binaries. This way those working on personal/dev status projects can use the latest io.js to have the new features they might want, and those working on public/production projects can use the latest node.js without having to worry about instabilities.

To me node.js or io.js is analogous to choosing between an LTS/stable release or bleeding-edge/unstable release release of your OS. There's no universally correct choice, it depends on your specific requirements. Having both projects doesn't fragment the community, for example most Linux distro packages are compatible with both stable/unstable releases of the OS, the only exceptions being different versioned dependencies which is generally resolved automatically by your package manager anyway.