chowes

People jumped the Angular / Ember ship for React because those frameworks were too complex. Then they realized they needed additional features. Now there's a push to unify these features into a framework...

You have to put your complexity somewhere.

I highly recommend devs (especially JS devs) try out a Clojure/script project. The tooling has improved immensely, and Cursive is one hell of an IDE. JS devs will really appreciate how clearly you can express these seemingly new frontend paradigms (immutability, one way data flow, single source of state) in Clojure.

Not to mention that REPL-driven development and hot-reloading are so pleasant to work in, leading to development environments like this: https://github.com/danielsz/holygrail

I'm curious if any Clojure veterans would weigh in on the state of Boot.. is it gaining traction, or is the consensus to stick with Leiningen?

Interesting article and approach, but I don't think this is really an argument against using something like Angular or React (which alone isn't even a true "MVC"). It's more of "for my particular use case, this worked well"... Angular and React most definitely have their use.

(In fact, you could probably leverage React's server side rendering and JSX to clean up that long chain of function calls in your page function.)

Well, that's assuming that both a) the best idea is worth something on the free market, and b) the person submitting would possess the know how to take their PoC and capitalize on it themselves.

Hopefully, anyone that fits in A&B would agree with you and wouldn't submit. For everyone else, this seems like a fun way to add to their resume.

Those interested in serverless "backends" should check out JAWS (https://github.com/jaws-framework/JAWS), as they've done a great job building out a framework around this very idea.

Apparently they've got a big update coming Monday, so keep an eye out.

EDIT: Not sure where to put the quotes... "serverless" backends, serverless "backends", both, or none? :P

What's the advantage of this over using JSX? You can already go JSX->virtual-dom https://www.npmjs.com/package/virtual-dom-jsx, and the fact that it's "vanilla" JS doesn't mean much as it's ES6 which needs Babel.

http://stackoverflow.com/a/28032438 gives a great overview to the pros and cons of both approaches.

Check out http://jlongster.com/A-Study-on-Solving-Callbacks-with-JavaS... and the follow up post. It's easy enough to start using generators alongside your existing async solution (callbacks or promises).

Proxies can be used for data-binding, similar to Object.observe.

I've also yet to find a case where I need WeakMaps instead of an Object or Map. All the benefits seem to be a bit too theoretical, but I likely haven't dug into it hard enough.

100% agree.. and just as important as ease of starting: ease of finishing. make all of your tests / linters / etc. runnable via a simple npm run.

there's overhead in setting this up, but i can remember several times where i have pulled the code down, made my changes, and gave up when trying to figure out how the maintainer wants my code formatted / tested.

Webpack's chunking (https://github.com/webpack/docs/wiki/optimization#multi-page...) will help you get the "hybrid" approach easily. It lets you separate out common modules into JS files for you to load when needed.

I don't think the author's goal is to recreate Haskell in Javascript. There's appeal for JS devs like myself to learn / use Haskell paradigms like those you've mentioned in their codebases without having to learn a whole new language.

In your current state, clustering is probably not be the best advice for your use case.

That being said, if you are planning on scaling, you'll likely be moving your map object into it's own process, or a more traditional database, etc. Then whatever node application you have that facilitates the communication between that db/process and your users (via websockets or http) will be the place where clustering will come in handy.

Ironically, right after the author mentions "The leading edge of developers are simplifying their builds" w/ vanilla JS, he suggests using Babel to get bleeding edge JS features...

I've learned that if I can't find the answer to a programming problem that I'm wrestling within 3 Google searches, I'm thinking about the problem completely wrong and need to step back and re-evaluate.

I'm just starting to blog - thanks for the tips!

http://neuralnetworksanddeeplearning.com/ is a great read to get started

The 'vanilla' implementation of Flux is very verbose, due to its declarative nature

The Relay system they're talking about is in reference to http://facebook.github.io/react/blog/2015/02/20/introducing-..., which is how Facebook manages data fetching at the component level.

Anyone have a sense of how well this setup would do w/ an Oculus Rift?

Have you looked into Mozilla's SweetJS? I haven't had enough Clojure experience to get into something where macros would prove useful, so I'm wondering if utilizing macros in Javascript (which I'm much more comfortable in) would be worthwhile.

I've come to appreciate some of the new ES6 features (anonymous functions, lets) much more after using their equivalents in ClojureScript.

Also, The interactive REPL based workflow that a lot of the LISP languages utilize is extremely appealing. I've been thinking a lot about how to bring this back into the JS world. I have yet to find any good literature on it, but I will be exploring this area more.

For those curious, here are some blogs that convinced me to finally give Clojure a spin:

- http://rigsomelight.com/2014/05/01/interactive-programming-f... (seems like this is the stereotypical "you should try ClojureScript because... " post)

- http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-r... (a bit code-heavy, but an admirable workflow)

- http://swannodette.github.io/2013/11/07/clojurescript-101/ (dealing with asynchronous code)

I'm curious HN, anyone out there making strides in interactive JS development, akin to the 2nd blog post I referenced above?

Scratch - Cambridge, MA - Software Engineer

Job description: http://grnh.se/dy8wb3

Summary: 2nd FTE hire. "Full stack", Angular front end, NodeJS / Firebase backend. Mobile in near future.

Apply and mention HN or email me personally (chris[at]tryscratch.com)