I once started with DOS, moved to windows, linux (various distro's), now already for a few years on osx.

Windows doesn't even come close to the reliability and comfort of my macbook-pro. I was always reluctant to move to osx, but I have to admit, this is simply the very best and most reliable machine I've ever had! It never crashed once, while I push it to it's limits every day!

I think the drop in revenue is because the market is really saturated. All those millions of guitars produced are not destroyed, it's not the kind of product that you can apply 'planned obsolescence' to. Instead, the vintage one's are often better sounding and therefore more popular. Also, if you find a good vintage guitar you are almost assured it will remain good as the wood has proven to be stable.

If there is a slow death to guitar than it is because it's almost impossible to earn any money with it, except for the lucky few. Learning an instrument like guitar takes many, many years, which is quite a hobby.. If you would spend the same amount of time in learning software development you are almost assured to have a solid income as result.

You mean only ES2016 from that list?

> Producing readable code is certainly the intent!

This is hilarious! Transpiling from the most readable JS alternative to ES6? Then you need to clean up some things, making it ready for yet another transpiler called Babel? And then everything is OK?

Show me how you are going to make this pretty:

  if does.that?.prop?.exist then console.log 'yes, no crash!'

> You mean only ES2016 from that list?

No, I was intentional about my description. People tend to be informal when talking about JS versions, and all five of those terms might be used to describe decaffeinate's output. IMO it's best to just say that decaffeinate produces JavaScript, and not any particular old version of JavaScript.

> Show me how you are going to make this pretty

Soak operations (anything with a question mark) are probably the hardest to convert to JavaScript, especially when they're chained. Here's what decaffeinate gives today:

http://decaffeinate-project.org/repl/#?evaluate=true&stage=f...

And here's an open bug with thoughts on making those look better: https://github.com/decaffeinate/decaffeinate/issues/336

But many people have still found decaffeinate useful since the vast majority of real-world CoffeeScript (at least from what I've seen) tends to convert pretty well, and even in difficult cases, it's better to safely get it in JavaScript first and then clean it up than to rewrite everything by hand.

  if (__guard__(does.that != null ? does.that.prop : undefined, x => x.exist)) { console.log('yes, no crash!'); }
  function __guard__(value, transform) {
    return (typeof value !== 'undefined' && value !== null) ? transform(value) : undefined;
  }

oh my..

This was 1 line of CS, how to clean this up without a chance of creating bugs?

How on earth is ESxxx an improvement on CS anyways? It's just not true, it's a leap back.

Instead of wanting projects to move to a language you know, you can better first learn the language they are written in, and try to understand their decision in the first place. If you know CS very well you would not be so eager to move to Babel transpiler imao.

There is also a nice comment in here about a large project that became a misery because of TS. Think twice before you hope!

> it has all of Coffeescript features and more

No! It seems you've never learned Coffeescript well enough to know the differences, just like too many other ES6 proponents.

I learned Coffeescript well enough to not care for the differences.

There's nothing especially interesting Coffeescript has over ES6/7.

I miss the existential operator like the deserts miss the rain

foo?.bar?().baz?.boo

Truly. That operator has most of the gravity that pulls me towards coffeescript.

Lodash things, like _.isNil staunch the bleeding, but it's just.. not the same.

I wrote coffeescript for 3 years, and the first 2 or 3 months was a frustrating learning curve. By the end of that job I really drank the koolaid. Coffeescript can be blissful. The complaints about invisible delimiters and stuff resonated with me for the first 2 weeks, but then I just learned it like you learn anything. If you are unsure what's going to happen, add extra parenthesis. I kept a window with js2.coffee on it so I could paste uncanny snippets while I was getting up to speed. After I got over the curve I stopped needing it.

I think it was more frustrating in the beginning than learning most things because I knew JS pretty well prior and it felt like I was throwing my experience out the window. I'm glad I did it though. Writing coffeescript was really quite pleasant. Now regular javascript has jumped forward a bit and has somethings coffeescript doesn't, I still feel like the one true web language exists somewhere between them.

I'm leading a project right now and every couple of days I get that coffeescript itch. Caffeine is hard to put down once you're addicted.

! https://github.com/babel/babel/pull/5813

Just found this. https://github.com/rongierlach/babel-plugin-syntax-exists not the worst workaround in the short term. Better than lodash's _.get but worse than coffeescript. :P

> $70 is nothing compared with the performance that you get.

Maybe on a slow pc, but with Atom on my macbook pro I have no performance issues at all period. I code 8+ hours a day (for many years), and no my fan is not spinning all the time because of Atom. I have 16Gb ram, have multiple apps open at the same time, Chrome with 30+ tabs, listen music via youtube, etc..

I was a long time Sublime user, but the $70 they're asking is really way too much with so many great open source alternatives today. Would they at least divide the $70 to all the package writers that actually make Sublime a great editor I might be willing to spend it, but unfortunately they want all the money for themselves..

Switched to Atom a while ago, I gained (some really great) features and finally got rid of the trial pop-up.

Top of the line MacBook Pro, freshly installed with only Sublime Text and Atom side by side shows a very, very clear performance difference. I have a fetish for clean machines, so it's an "experiment" that repeats itself quite often for me.

Don't get me wrong - I use Atom quite often. However, stating that it does not jave performance issues is just wrong. Period.

Atom needs to do a metric fuckton more work (webengine, remember?) to move the cursor than Sublime, and thus it has severe keystroke lag. Whether you're okay with it or even notice is something entirely different.

This is a true loss for the world. Although his revolutionary ideas were IMHO by times a little over the edge, he envisioned and fought for a world without poverty and war, where earth's resources are not being depleted by hunger for money and power; A resource based economy.

Thank you Jaques Fresco for opening my eyes to this and RIP.

For some reason the focus is always on preventing re-rendering if it comes to optimising a React app. I understand that it can be really effective and is often the easy way out, but re-rendering in itself is not costly and I don't really care about it the most of the time.

I am more concerned that the code that runs during a re-render is not rebuilding huge static lists that never change and so. I see that over and over again in React apps. I tend to build a lot of the static stuff in the ComponentWillMount stage to prevent that. Only when already optimised code is getting to slow I start thinking about preventing re-rendering if possible.

My reason for not starting with ShouldComponentUpdate is that you have to be very careful not creating nasty bugs with that like I did some times. If a year later you write some code and it doesn't work for some reason it is painful if you find out after a long search that a stupid child component did not update for some prevention rule you forgot about. I really try hard to avoid premature optimisations.

That's a great point, and being aware of the dangers of shouldComponentUpdate is what this post is all about. There are a lot of gotchas when using PureComponents, and can lead to bugs if you're not careful.

Also, recalculating derived data (building static lists) in render() is very wasteful, and is also another gotcha when using PureComponents (object copying). Removing object copying from render() speeds up the actual render() call and allows you to take full advantage of PureComponents.

We are experimenting with ways to make all of this a bit easier, and hopefully will have some good news to share in Part 2 :)

You should have learned to be very happy they disabled your account! Facebook is for idiots and for companies that milk those idiots. This event likely saved you for wasting even more of your precious life time. Be happy and do some great things with your life without feeling the need to constantly show off.

I partly agree with you, as I quit Facebook years ago, and have never wanted to go back. That said, I don't think people who use it are idiots. In fact, I can see that they get a lot of value from it. A lot of genuinely valuable content is siloed in Facebook - you're not an idiot just because you can't get it from somewhere else.

I didn't say all people who use it are idiots. But willingly sharing your private data for free while waiving all your rights? If you realise that facebook runs AI on that data and knows much more about you then you could ever imagine, and if you realise they are selling that data to companies you might not like so much, or what else more, that's pretty stupid imao.

The man runs a business that depends in considerable part on his ability to maintain Facebook pages. This ban could've put that business under. A dicey model, to be sure, but in contracting you have to go where the clients are - I think this is a fair bit beyond "play stupid games, win stupid prizes".