mixmaxhq
Reactify the client?
So I am biased as I know react and love jsx templating. I'd like to get your opinions on this as I feel we could dumb down the back-end to a simple json api while the front-end could be snappier and implementing live updates would be a sinch.
I understand this is my code but I wanted a quick solution to getting some page-specific javascript going. The dependency code is also hideous and we can do better.
So what are your thoughts on getting React and some proper front-end dependency management going?
Yes, go for it! We switched our product's frontend from Backbone to React shortly after we wrote this module (and blogged about it here https://mixmax.com/blog/backbone-to-react-without-rewriting). So moving this to React would be very welcome.
Nice!
we could dumb down the back-end to a simple json api
Note that even at Mixmax we server-side render some initial HTML for optimum time-to-render (user isn't stuck looking at a totally blank page while the client loads). (For example, load https://compose.mixmax.com/message?user= + YOUR_EMAIL with JavaScript disabled.) We then render the React app into that container. Hopefully you can keep that approach, e.g. SSR the table header and sidebar since those parts don't really change.
@wearhere I would argue that it's a dev-facing webapp and time-to-render might not necessarily matter but Steve Jobs made the point of cleaning the parts of his car nobody would ever see and he did ok for himself.
@krazyjakee haha! yeah it's partly about time-to-render and partly about not trying to force everything to client-side rendering if the server is already rendering some initial HTML alright. Less work to refactor
in some ways I'd be in favor of sticking with a statically-rendered site - there aren't any data inconsistencies to worry about as a user of the interface, and you can thus trust that the state of the page you're looking at is correct if/when it loads.
