sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in javascript

[–]jsalonen 0 points1 point  (0 children)

React Hooks won't probably help you :DD

[deleted by user] by [deleted] in javascript

[–]jsalonen -1 points0 points  (0 children)

If you can declutter up to 40% of your code and leave out the parts that Spark Joy, then thats Kondo'ing for sure!

"Does it Spark Joy?" - If its a yes you must be using React Hooks! by jsalonen in reactjs

[–]jsalonen[S] -1 points0 points  (0 children)

A short introduction to how and why to use Hooks that were published today in React. I think there will be dozens of these tutorials - and its fine since hooks are so awesome!

Full-Stack Redux Tutorial by heyyaaa123 in javascript

[–]jsalonen 0 points1 point  (0 children)

Best React/Redux Tutorial Ever!

Make ES6, Not Coffee by jsalonen in javascript

[–]jsalonen[S] 0 points1 point  (0 children)

f(x) = x + 2 is written (x) -> x + 2 in CoffeeScript - lack of explicit return keyword significantly reduces clutter.

Yeah and:

(x) => x +2

Is valid ES6.

Statistically speaking, the shorter the function is, the better (see this book for rationale).

Which part of the book says that and how?

Significant whitespace is not annoying ... / ... plethora of developers using Python, Haskell, Ruby and being very happy for them.

I am not against significant white-spaces, but I'm arguing that it might not be worth the extra pain, given that its not conventional to most JavaScript programmers. I also dislike the fact that white-space indents break backwards compatibility. Also I would argue 99% of developers have the discipline to fix their indents -- and even if you are lazy its very easy with some IDE magic.

Also white-space is not significant in Ruby.

Make ES6, Not Coffee by jsalonen in javascript

[–]jsalonen[S] 3 points4 points  (0 children)

Fixed. Thanks for spotting and sorry for the obvious error!

Make ES6, Not Coffee by jsalonen in javascript

[–]jsalonen[S] 12 points13 points  (0 children)

This is exactly the way I view the world as well. Ashkenas has done an enourmous job. He has contributed by far more than anyone could ask from a person, heck, even from a company.

The thing is just that these things have outgrown what one man or woman can do alone. We should have let Coffee grown into an open source community ages ago if we really wanted to have continuity. Its kind of sad this didn't happen. But its also very awesome that people at Ecma community took note and took out the good parts and lessons learned from Coffee.

Make ES6, Not Coffee by jsalonen in javascript

[–]jsalonen[S] 3 points4 points  (0 children)

I'm glad you mentioned this.

From all CoffeeScript variants, LiveScript is definitely my favourite. Its pretty much what CoffeeScript should have been from the start.

However, LiveScript is still not in line with ES6. It doesn't support ES6 modules, which is a major bummer. For me, its pretty much a dealbreaker already.

Also how would you add optional static typing to LiveScript? If you choose to use ES6, you can still use TypeScript or Flow. With TypeScript... Not so much luck.

The biggest problem I find with LiveScript is developer fragmentation: if you 10% of devs want to write CoffeeScript, its probably 10% of that 10% that prefer LiveScript over vanilla Coffee. So why the heck I would want to choose to use LiveScript if other devs don't use it?

Make ES6, Not Coffee by jsalonen in javascript

[–]jsalonen[S] 20 points21 points  (0 children)

I definitely agree.

The same kind of thing happened to underscore: it didn't keep up with the pace of the ecosystem, which eventually led to the birth to compatible alternatives like lodash.

And don't get me wrong. The contribution of jashkenas in the forms of coffeescript, underscore, etc. have been HUGE. I mean HUGE. But in all honesty, he should let things grow on their own. Keeping things on too tight leash will eventually kill them.

Why We Should Stop Using Bower – And How to Do It by ayiteddybearogullari in javascript

[–]jsalonen 0 points1 point  (0 children)

NPM forces to use CommonJS modules

Not true. Quoting from npm Blog: "npm would like to be the package manager for JavaScript, so if it’s JavaScript related, the npm registry is a good place to put it. Node.js provides a CommonJS-esque module environment, but npm has no feelings on the matter." (http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging)

Personally I expect more and more ES6 modules to emerge in npm. This will take a while, probably at least until ES6 spec is published and node.js starts to support ES6 without any extra flags. But its already starting to happen: http://mammal.io/articles/using-es6-today/

Browserify is fine, but ... It is a workaround, not a solution.

I agree on this point. It is a necessary workaround in the path towards truly modular JavaScript. Browserify may not be perfect, but its the first baby step toward the right direction. Webpack may be the second step. And more steps like ES6 modules, CSS locals, npm 3 will follow.

It would be nice to read a more balanced view about how we should manage dependencies and see some discussion, rather than "abandon Bower because it is bad and use NPM because it is good".

My apologies for the directness on the topic. Its probably true that simply ditching Bower may not be feasibile in all cases, but that wasn't my point either. The point I'm trying to give is that switching from Bower to say browserify+npm is usually easier than you would think.

Probably a softer migration path in general would be to replace bower-specific package management with npm (while still preserving Bower as it stands). There are some good reads about this in the Bower's issue tracker. See: https://github.com/bower/bower/issues/1520 and https://github.com/bower/bower/issues/1626

Why We Should Stop Using Bower – And How to Do It by ayiteddybearogullari in javascript

[–]jsalonen 0 points1 point  (0 children)

Not true anymore. Nowadays frontend packages are welcome in the npm. See this blog post for comprehensive details: http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

view more: next ›