6 ms·
It's not a silver bullet, it's a method to keep your sanity. What often happens is you start with a traditional server rendered web application. Maybe you have
by akoumjian 14y ago
It's not a silver bullet, it's a method to keep your sanity. What often happens is you start with a traditional server rendered web application. Maybe you have a couple ajax-y interactions for speed or UI responsiveness and everything is happy-go-lucky for a while.
Over time, you find that you start wanting more data in more views, or large collections of items that you want to manipulate visually on the client side, with no need to bother on the server side. One by one, each view starts accumulating async, non-event based cruft. The callbacks become nightmarish.
The JSON Api makes it easier to build those data heavy, complex views become more responsive. And they can change on the fly! The javascript MVC is a way to manage the the complexity and hopefully pairs well with a good event driven system.
The point is, if you know your application is going to be sufficiently complex, it makes sense to build it as client side rendered to begin with. Other great benefits can include:
- JSON API leaves you primed and ready to build native mobile apps or 3rd party integration
- Your js developers don't have to wait for backend devs to modify half-complete ajax views if you have a good api
- Your template rendering happens in once place instead of two, making it easier to isolate logic
Obviously it's not worth the trouble if you only have a few models/resources and you are dealing with a very read heavy application. It is also a lot more work to implement two MVC layers instead of one, but you may sleep better at night.
- swah 14y agoAnother advantadge of client side is that you can work offline for some time, if needed, acting as if CRUD operations as working, say. OTOH: is any of the big complex successful websites, the ones that would most benefit from being written as SPAs, written that way?
- ahoyhere 14y agoWe DID build Charm with client-side MVC from the get-go. That's exactly the experience Thomas wrote about as being a problem. Note that Charm was not "read heavy" -- it was totally interactive and doing a lot of real work; we did live (email) thread locking and all kinds of crazy stuff. If we were to start from scratch, you can bet your ass we would keep the client-side as dumb as possible.
- shousper 14y agoIt sounds like you really just learnt that client-side MVC (in this case) wasn't the right tool for the job after all? I'm sure it still has its place in the world, just maybe not for an app with the complexities built into Charm? .. perhaps.
- ahoyhere 14y agoYes, I believe you just summed up the blog post in question, only without the supportive details. :)
- rxcfc 14y ago"we did live (email) thread locking and all kinds of crazy stuff" - Can you say more about what this entails?
- iamstef 14y agoplease don't leave us hanging. I need to know what this is.
- ahoyhere 14y agoOK, Charm was a live interface for handling support threads. New messages would show up when we swept them in from your inbox via POP/IMAP (max lag: 5 min). You'd leave Charm open, messages would appear. If you work in a team, and say your team member Bob opened the message to respond, it would show as locked on your screen, to prevent duplication of effort. If Bob canceled his reply, it'd unlock. If Bob sent his reply, the message would disappear from the queue.
- rxcfc 14y agoI understand how that would add a bit of overhead, but it doesn't seem all that crazy. Certainly a well architected client app wouldn't have any issue with this. Maybe I'm missing something?
- 14y ago