search

dgmcguire / texas

You don't really need all that javascript to make dynamic web apps. Keep your code in elixir and on the backend where it belongs!
51 stars 3 forks source link

Let's talk about the transport layer. #3

Open dgmcguire opened 8 years ago

dgmcguire commented 8 years ago

So I've been speaking with @zharinov on slack and he suggested that [react-lite] might be a suitable replacement for what texas currently uses which is [virtual-dom].

He also brought up the fact that we don't even necessarily need vDom to make this work and I agree so I thought I'd start a discussion here and see if anyone wanted to contribute.

Long term goals I see texas as having many optional ways to transport data that would express view transformations - here are a few options I think could work.

  1. shelling out to node and creating vDom changesets on the backend. This would require keeping a cache of what the client DOM looks like in order to compare updates and create a changeset
    • pros: less data over the wire than full html / could be serialized into an efficient format like protobuf
    • cons: seems complex enough to have some weird edge cases, like what if the client is mid-editting a field and we send a changeset up that manipulates that field? The changeset likely would just replace it entirely, but would the client be okay with that?
  2. porting ratchet to javascript and keeping duplicate implementations on the back and front-end
    • pros: again, less data over the wire and could probably also be serialized into a more efficient format - this would lbe much simpler to implement
    • cons: there would be significanlty more client operatiosn happening here...the client would render out the template - use vDom to compute a changeset and then apply the changeset. If you have very weak/slow clients this could impose seriously bottlenecks for them

thoughts? comments? concerns?

jeffutter commented 7 years ago

I find 2 mildly interesting. In that case, only the data structure that ratchet consumes would need to be transferred.

I'm not sure how much the client load is a concern. Any frontend framework is doing this today, no? We could probably implement some kind of caching similar to whatever react does to determine if props update or not.

dgmcguire commented 7 years ago

2 is essentially why I've hard coupled this library to ratchet even though with the current impl it's not really necessary. With ratchet you can keep every piece of view data accessible by a single function call without bringing over any templating concerns - meaning you could send it to any kind of client that could make native templates and have an identical or functionally equivalent view to display.

As for client speed concerns, no it's probably not really that big of a deal, but it's worth trying to think through the tradeoffs before tackling any of these impl's as relative to how simple the library is in its current form - they would take a lot more time/effort.