Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reactify the client? #58

Open
krazyjakee opened this issue Oct 3, 2017 · 5 comments
Open

Reactify the client? #58

krazyjakee opened this issue Oct 3, 2017 · 5 comments

Comments

@krazyjakee
Copy link
Contributor

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?

@bradvogel
Copy link
Contributor

bradvogel commented Oct 3, 2017

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.

@wearhere
Copy link
Contributor

wearhere commented Oct 3, 2017

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.

@krazyjakee
Copy link
Contributor Author

krazyjakee commented Oct 3, 2017

@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 krazyjakee mentioned this issue Oct 3, 2017
@wearhere
Copy link
Contributor

wearhere commented Oct 3, 2017

@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

@skeggse
Copy link
Member

skeggse commented May 22, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants