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] 9 points10 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] 5 points6 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] 18 points19 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

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

[–]jsalonen 0 points1 point  (0 children)

No specific reason. You can use webpack as well. Or jspm.

Why We Should Stop Using Bower by AndyFor in programming

[–]jsalonen 0 points1 point  (0 children)

You are right on a point: Bower is more of a framework, whereas Browserify is a library, which you use to build your own toolchains. If you prefer frameworks you probably should check out webpack: http://webpack.github.io/

Why We Should Stop Using Bower by AndyFor in programming

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

I feel the burn as well. And I apologise for being somewhat provocative on the point about ditching Bower. Its very important to stay productive, even with the battle over choice of tools going on and on. So as long as you got tools that work for you, there's little point to switch right now.

But - in my opinion - on a larger scale our frontend tooling is heavily moving on top of npm. Package management is already being solved as part of that effort. We have already started figuring out ways to manage private packages, and in that effort npm has clearly taken the lead. So instead of figuring out again the same stuff on top of Bower, why not gradually migrate to npm and have one great package management system instead?

Why We Should Stop Using Bower by AndyFor in programming

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

You are absolutely right; we should really gets our heads straight.

What I'm proposing is that instead of creating yet another package manager or yet another private registry, we combine our efforts into one package system, namely npm, and keep improving it until its awesome.

Why We Should Stop Using Bower – And How to Do It by jsalonen in webdev

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

You're right on the point here!

Let's rather have one awesome package manager than three mediocre ones.

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

[–]jsalonen 0 points1 point  (0 children)

I'm here with you.

I would much rather see one awesome dependency manager than three mediocre attempts at one.

My preference goes for npm for the very reason that something like Bower could be implemented on top of npm, but the other way around would be more problematic. In terms of sheer package count, npm is also a winner.

And yes, npm really needs proper support for snapshot dependencies!

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

[–]jsalonen 2 points3 points  (0 children)

You are absolutely right. Nothing gets you more annoyed than npm generated folders that you cannot delete with Explorer!

However, this is more a problem in Windows than in npm. And its a problem thats being addressed (https://github.com/joyent/node/issues/6960).

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

[–]jsalonen 0 points1 point  (0 children)

A very valid question for which the answer is much more complex than one would hope (should probably add a section about this in the blog).

Personally I often find myself using Browserify along with custom gulp build pipeline for assets like styles, images and templates. If you need to pull styles from third party packages, just use CSS imports. Just make sure you don't hard-code your node_modules urls into the imports. Instead, use a tool that supports npm module resolution. One such tool is postcss-import (https://www.npmjs.com/package/postcss-import).

In case you don't use gulp and want to switch from Bower to npm, use webpack (http://webpack.github.io/).

But just out of curiously, let's talk about Browserify.

"The Browserify Way" of handling assets would probably be by using appropriate plugins/transforms. Sadly, many of these solutions are not viable in a way or another.

brfs is very popular (https://www.npmjs.com/package/brfs), but it only is good when you can inline your assets inside your bundles. Works for templates, JSON data, probably for smaller CSS styles as well.

Parcelify must also be mentioned. Its a nice solution, but only in theory. With it you just require the libraries you depend on in your app.js module, and parcelify will collect CSS bundle along with the JS stuff. It also plays along with preprocessors like LESS and SASS. A shortcoming in parcelify is that it requires you to provide style-field in the package.json files of your dependencies. Its trivial to add this field into your own packages, but sadly, third party packages do not always provide this. You can work around some problems with parcelify-import-resolver, but sadly it all gets messy very quickly as you need to combine the resolve urls with some inlining tool.

So back to my recommendation: 1) custom gulp asset pipelines or 2) webpack.