5 ms·

We 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 hea

We 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 ago
It 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 ago
  Yes, 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 ago
  please don't leave us hanging. I need to know what this is.
  - ahoyhere 14y ago
    OK, 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 ago
      I 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?
akoumjian 14y ago
The main premise of the post seemed to be: >client-side processing and decoupling is detrimental to both the speed of development, and application performance I can only guess then that it was a bad design choice for this particular application and for the developers working on the project. My own experience has been the opposite. Client side mvc has resulted in speed of development INcreasing and made various parts of application performance better. I described some of the reasons above. For example, if you have dedicated back and front end developers, you can develop very quickly, indeed! Another point that seems particular to this project: > Especially when you’re starting out and need to stay flexible you don’t want to have too much code around—and Rails is great for that, but… adding a JSON API layer and basically a second application that runs on the client is annihilating this advantage for you. If building a JSON API layer and a client MVC adds significant complexity, rather than decreasing it, then it was likely a poor choice. For other products, building those decoupled pieces can reduce the complexity quite a bit. One example would be when you are creating a platform, of which a web application is only a single piece.

shousper 14y ago

It 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 ago
Yes, 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 ago
please don't leave us hanging. I need to know what this is.
- ahoyhere 14y ago
  OK, 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 ago
    I 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?

akoumjian 14y ago

The main premise of the post seemed to be: >client-side processing and decoupling is detrimental to both the speed of development, and application performance I can only guess then that it was a bad design choice for this particular application and for the developers working on the project. My own experience has been the opposite. Client side mvc has resulted in speed of development INcreasing and made various parts of application performance better. I described some of the reasons above. For example, if you have dedicated back and front end developers, you can develop very quickly, indeed! Another point that seems particular to this project: > Especially when you’re starting out and need to stay flexible you don’t want to have too much code around—and Rails is great for that, but… adding a JSON API layer and basically a second application that runs on the client is annihilating this advantage for you. If building a JSON API layer and a client MVC adds significant complexity, rather than decreasing it, then it was likely a poor choice. For other products, building those decoupled pieces can reduce the complexity quite a bit. One example would be when you are creating a platform, of which a web application is only a single piece.