Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Personally I use JS extensively for these kind of things. I hate JS the way most people use it, but JS is actually a crazy powerful functional programming language in disguise. And you can use it on server or client almost transparently. I mostly use only a subset of JS myself: I write const fat arrows that either return functions or immutable objects. No or very little state. I don't use "this". I use react + redux on the front-end. I maybe use 4 different language constructs total, both on the server and on the client, and my life as a programmer has become very peaceful, I can focus on delivering features. The nice thing about JS is, like the language or not, the tooling and ecosystem are awesome. For one man projects you can really make the language your own and achieve crazy productivity. YMMV.

Here's an example of what I mean, a Promises/A+ implementation in less than 100 LOC - just for the fun of it: https://github.com/djfm/promesse/blob/master/lib/promise.js

I think it kinda feels like Haskell, yet browsers understand it :)



> JS is actually a crazy powerful functional programming language in disguise.

I feel the same way. And since you can write a cruddy jQuery mess that fetches data and spits out to backend-as-a-service providers, Javascript is hands down the easiest way to go from nothing -> project others can use.

The ecosystem is in a bunch of growing pains right now, but if you don't care about maintainability and scaling up to a large project, just throw up an HTML page with some styling and javascript that makes it interactive.


I have a feeling the ecosystem is becoming, err, slightly less worse :) My react redux babel boilerplate has not changed in about a year and I strive to stay up to date. Once you can write a webpack.config.js without looking at the doc you're all set :)


100% agreed. Webpack 2 is going to be a fairly sizable change, but for the better. I've been following the webpack meeting notes, pretty excited to see where it's all headed.


I have worked with Redux as well, and write functional JS pretty much exclusively, and agree that it's actually very pleasant to work with these days, especially if you're also in an environment where you can take advantage newer language features like async/await.

My #1 pain point with functional JS though, is that using a persistent data structure library like ImmutableJS or Mori removes the ability to use some of the awesome new syntactic sugar introduced in ES6 like the spread operator, destructuring, etc, for making code less verbose. So you have to make that tradeoff between being able to use a succinct syntax for common operations vs having the optimal performance in terms of memory efficiency and garbage collection pressure.

I'd really love to see native persistent data structures as a first class citizen in JS so they can make use of all new language features. Until then, I'll probably continue to choose ClojureScript for my own projects.


It's hard to compare JS to Haskell without mentioning the JS's complete lack of a type system...

That said, if you want something more ML-like in your JS, Flow is an increasingly-viable option: https://flowtype.org/


Yeah, I've been experimenting with it for a few days and I find it very promising. But the lack of types in JS is not such a pain point IMHO. In JS you can define a monad that works only with numbers, which is sometimes useful, and which you cannot do in Haskell without black magic. I think Flow's idea is that most JS programs are actually naturally well typed, and it often verifies in practice. Just because you don't have a compiler yelling at you doesn't mean your program is not well typed :)


> In JS you can define a monad that works only with numbers, which is sometimes useful, and which you cannot do in Haskell without black magic.

What does this mysterious assertion mean?


That being said I cannot wait for the time when Haskell becomes truly mainstream in web development.


I think as a beginner, I need to start w/ "standards" first. I mean, shouldn't I first know JS to understand Flow? Wouldn't learning FlowType put me in a corner where I don't have all the support of JS community?


Starting with standards is probably good yes. Something I found very helpful in JS is doing hard-core TDD at least at first (again, the tooling is awesome, see mocha, chai) - then after having done the same thing a hundred times you can become more relaxed. Good unit tests make up for a lot of missing types.


I don't know a lot o javascript, using clojurescript instead, but you've piqued my interest, is there any learning resource for that kind of javascript use?


If you really know cljs then you are already doing it in a less kludgy and more elegant/sane way ;)


Have a look at redux's doc for instance, http://redux.js.org/docs/introduction/, and do read the code (it's about 300 lines total), they're both masterpieces of modern JS.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: