I used Rivets on a decent-sized SPA and I have to say, it worked out really well.
The rendering was a bit slow, and in more than a few places I had to force a refresh to get it to pick up data changes. Those are really my only complaints though: the templates were a breeze to write, and with the ability to write custom formatters, Rivets is pretty expressive and extensible. I wound up with a codebase that was quite straightforward and easy to reason about, with minimal cruft. Overall I'd say it was a win.
Nowadays I use React.js and am very happy with the switch, but I definitely recommend Rivets to anyone who just wants to add a smidgeon of data-binding without pulling in a heavy framework. If I were doing that medium-sized SPA project again though, I'd definitely use React.
That's interesting to me - I posted this up because I'm doing a small app right now and was getting frustrated with the amount of code I had to write to get React to do what I wanted (basically, editing a large, fairly complicated data structure via a big form). Rivets cut my codebase by about 2/3 and made it easier to understand, but I have to say that given everyone else's positive experience with React I feel like I must have been doing something wrong.
I'll have to revisit it again later I guess. One thing that was particularly annoying with what I was doing was that the whole form would fail to render on any error, and I'd often be left without even a console message to tell me what React didn't like. How has your experience been with debugging React apps?
Debugging React has been pretty painless. Errors show up in the console, step through with Devtools if things get weird... One of the great things about React is It's Just Javascript (technically CoffeeScript in my case).
It gives you a Devtools tab that looks like the DOM Inspector, but it's the React component tree. I've mostly found it helpful when dealing with abstract components (components that render other top-level components rather than DOM components).
I can't see your code so unfortunately I can't give you more specific advice, but in general, I've found that if you feel like you have too much code, you're probably overcomplicating things. This holds true in React, and (in my experience) programming in general. Then again, if it's just a big form, that could be the problem. Big forms aren't usually a great UX anyways, so maybe consider breaking that up into more discrete pieces - but I'm basically talking out of my ass at this point since I don't know your situation.
Hope this helps though! Also happy to answer any questions over email (in my profile). I'm far from a React expert but always glad to lend a hand.
Thanks for the tips! I haven't tried the developer tools, which sound like a crucial piece of the puzzle. Without them, the debugging experience had a lot of "Why is there nothing on the screen and nothing in the console?" moments. I did a lot of old-school printf debugging with it because of that.
As far as the big form, I agree it's typically not what you want. I'm working with a pharmacist on a workflow specific to her particular location though, and this is what we think will meet her needs the best. It's one of those tools that you'll use 500 times a day, where taking advantage of rapid input via muscle memory trumps any kind of new-user friendliness. The over-complication mostly seemed to come from the need to have the form auto-save to an alternate backup location periodically.
I've actually just about got her convinced to try some vim-inspired keybindings with it (speaking of strange, but efficient, UX), but we'll take it a step at a time on that front.
What has your experience with reflux (and other flux libraries) been like? I haven't tried any of them yet, currently using a home-rolled solution with PouchDB. They all look a bit overly ceremonious for my liking (same thing that drove me away from Backbone early on).
In my experience, React isn't worth the hassle without Reflux.
I was a bit apprehensive at first since it's the only flux implementation I've come across that gets rid of the dispatcher altogether, but after building a couple of internal apps I think it's the cleanest, simplest implementation.
I really wish projects like this wouldn't register their own domain names.
The likelihood that vanity domains for new JavaScript libraries will still be renewed in 10 years time is pretty low - if they used rivetsjs.github.io instead there would be a much higher chance of links continuing to work far into the future.
Does it really matter if [project].github.io is used when github.com/username/[project] will exist just as long if not longer?
Also, I've been noticing a handful of project sites hosted at github.io that apparently once used to work have been returning a "site has been disabled due to a misconfigured custom domain" message. I realize its a configuration issue but this is just as annoying as a custom domain like rivetsjs.com potentially disappearing.
The rendering was a bit slow, and in more than a few places I had to force a refresh to get it to pick up data changes. Those are really my only complaints though: the templates were a breeze to write, and with the ability to write custom formatters, Rivets is pretty expressive and extensible. I wound up with a codebase that was quite straightforward and easy to reason about, with minimal cruft. Overall I'd say it was a win.
Nowadays I use React.js and am very happy with the switch, but I definitely recommend Rivets to anyone who just wants to add a smidgeon of data-binding without pulling in a heavy framework. If I were doing that medium-sized SPA project again though, I'd definitely use React.