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

When there was no React.js, I had in mind something like that and implemented a very simple concept like this with ghcjs. Functional languages tend to let you write this kind of code.

It felt very organized and just worked, then I looked at Elm and said: "that's exactly what I thought I'd do with ghcjs". Then with react.js: "finally somebody implemented the concept in plain javascript". Which is after all a kind of stricter mvc model for the single-page web applications. The fact is that with an haskell-like language, the kind of mvc concept is much more structured, you do less design mistakes because the language itself constraints the effects. So what react.js did is adding these constraints on top of plain js in an elegant way.

In other words: I think the addition of elm is the language itself, for those acquainted with haskell and where type checking matters a lot, compared to plain js.

On the same path, there are other libs similar to react.js that are even faster because they have stricter requirements on how data is mutated.



Thanks a lot for the response. Your comment about constraints improving design makes a lot of sense.

As to libs similar to React, I assume you're talking about Mercury and Mithrill. But I'm quite happy with React's performance and escape latches (shouldComponentUpdate). I'll however switch in a heartbeat if a better design comes along.

The problem is that unlike when I was mutating DOM with spaghetti JS or wrangling with Angular, I am yet to say "why is this thing so darn difficult" with React for almost all use cases I've thrown at it (yet to figure out animations). And the last React.js Conf has taken care of most things that I could imagine improving in web development with Relay and CSS in JS.




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

Search: