3 ms·
I like the idea of being able to use my own raw domain objects as the model, which in angular you are supposed to wrap up as a service as i understand it -- a b
by jonahx 13y ago
I like the idea of being able to use my own raw domain objects as the model, which in angular you are supposed to wrap up as a service as i understand it -- a bit of boilerplate i don't love. I'll definitely keep my eye on this project, it sounds like it has a nice architecture.
My last piece of advice is docs, docs, docs. Making a framework easy to learn by example is the key to adoption imo. That was one of the chief complaints you heard about ember, though I think they've started to fix that. It's boring work and hard to make good docs, but it's so so important.
- zpao 13y agoThanks for taking the time to follow this conversation through :) We've spent a lot of time getting the docs to where they are today, but there's always more to do. We have more planned but think we got a pretty good point for our initial public release. When we've showed the site internally at FB & Instagram we got a lot of the same feedback you're giving now, that we need more examples. We have some more in the repo and more we'd like to write. Coming soon!
- grayrest 13y ago> I like the idea of being able to use my own raw domain objects as the model, which in angular you are supposed to wrap up as a service as i understand it -- a bit of boilerplate i don't love. This is only a cultural thing. Angular is, at its root, a dependency injection framework. The upside of doing thinngs the angular way is that you can wire things together differently down the line (and you can actually get a lot of code reuse if you write 1-2 function services) with the downside being the boilerplate wrappers.