4 ms·

Another plus to this "ramping up" of tools as necessary is when you get to a certain point where your entire UI is sophisticated enough you can cut the views ou

Another plus to this "ramping up" of tools as necessary is when you get to a certain point where your entire UI is sophisticated enough you can cut the views out of your rails app and basically transform it just a REST API with another service responsible for serving the UI layer. Rails makes a fantastic REST framework, especially if you build your app that way right from the start.

wjossey 8y ago
Good point, and this is exactly what I did. I actually was running the SPA + the rails app side by side. Took me about 6 months, but I cut over every page / app one by one till I was done. And, to the parent commenter, good point. I do think the gist of the author is to use the right tool for the job, and they are not dogmatic about "never write an SPA". Thanks for keeping me honest.
- andrei_says_ 8y ago
  I’m curious, what was the change in the UI which required the move away from Rails? What are you accomplishing with Vue which was impossible before? Would love to get a glimpse of the app.
  - debaserab2 8y ago
    I'm not the OP, but here's how my Rails app is growing after several years: The first "complex" UI design that we came up with was creating a list view that came with all the trinkets you'd want from a sophisticated list view (pagination, sorting, filters, searching). This view needed to be able to apply easily to all the key data structures our app uses (list of users, list of things user has, list of things users do, etc) which meant due to the scale of some of the data sets most of the operation work needed to be on the backend. Originally, it was built as a completely normal Rails view requiring a full page refresh (form submit) to perform any given operation. This certainly was "doable" but not a great experience as someone administrating lists of things in our app. We then wrote a React component that manages all the visual state itself based on the data returned from the backend and replaced the existing Rails view with this React component. By pushing responsibility of view state to the client our Rails codebase get simplified. React fully manages visual state, but where we really benefit is the fact that it forces you to design components in such a simple way that UI abstractions become more naturally fitting. The conventions are easy to understand and result in a codebase that can have a lot of cooks in the kitchen without too many problems. Could this be written in jQuery? Sure. If it's like most large jQuery projects I've seen with multiple hands on it, it will be hard to keep it from being too brittle. The implementation is really part of a longer term plan to begin building out new user interfaces in React. We find that react delivers on the promise of UI reusability much better than any backend MVC frameworks view or partial system. A front-end codebase is starting to emerge with it's own developer conventions and processes that are more geared towards frontend requirements. Meanwhile, our backend is simplified to only deal with tasks related directly to data management. The split feels very natural as the codebase grows larger. There is no obvious downside to writing in React besides the minified library code payload. As a summary: our users expect interactions with complex interfaces to respond quickly. React is designed to build interfaces that fulfill that expectation, and the implementation of React in our codebase allows to slide into a more microservices looking architecture in an organic way as the scale and complexity of our app increases.
  - wjossey 8y ago
    Our core product offering is a fully white glove 360 review process for small to medium business (mostly startups between 10 and 300 employees). The objective of our process is to deliver highly actionable feedback for each and every participant, so the “review” you fill out for yourself, your manager, and your peers, feels different than a normal form based review. We ask a series of questions, adjust what we ask on the fly, and try to help encourage writing high quality feedback along the way. We do a part of this process during a workshop we run on site, and that tends to mean a bunch of people packed on a single WiFi node. Having the app as an SPA allows the user to fill out their 360s, even on a dreadfully slow network, and not notice. This could have been achieved with jQuery, but given how complex I know this code is under the hood, I shiver at the thought. To the questioner, my email is in my profile. Shoot me an email and I’ll point you towards our demo.

wjossey 8y ago

Good point, and this is exactly what I did. I actually was running the SPA + the rails app side by side. Took me about 6 months, but I cut over every page / app one by one till I was done. And, to the parent commenter, good point. I do think the gist of the author is to use the right tool for the job, and they are not dogmatic about "never write an SPA". Thanks for keeping me honest.

andrei_says_ 8y ago
I’m curious, what was the change in the UI which required the move away from Rails? What are you accomplishing with Vue which was impossible before? Would love to get a glimpse of the app.
- debaserab2 8y ago
  I'm not the OP, but here's how my Rails app is growing after several years: The first "complex" UI design that we came up with was creating a list view that came with all the trinkets you'd want from a sophisticated list view (pagination, sorting, filters, searching). This view needed to be able to apply easily to all the key data structures our app uses (list of users, list of things user has, list of things users do, etc) which meant due to the scale of some of the data sets most of the operation work needed to be on the backend. Originally, it was built as a completely normal Rails view requiring a full page refresh (form submit) to perform any given operation. This certainly was "doable" but not a great experience as someone administrating lists of things in our app. We then wrote a React component that manages all the visual state itself based on the data returned from the backend and replaced the existing Rails view with this React component. By pushing responsibility of view state to the client our Rails codebase get simplified. React fully manages visual state, but where we really benefit is the fact that it forces you to design components in such a simple way that UI abstractions become more naturally fitting. The conventions are easy to understand and result in a codebase that can have a lot of cooks in the kitchen without too many problems. Could this be written in jQuery? Sure. If it's like most large jQuery projects I've seen with multiple hands on it, it will be hard to keep it from being too brittle. The implementation is really part of a longer term plan to begin building out new user interfaces in React. We find that react delivers on the promise of UI reusability much better than any backend MVC frameworks view or partial system. A front-end codebase is starting to emerge with it's own developer conventions and processes that are more geared towards frontend requirements. Meanwhile, our backend is simplified to only deal with tasks related directly to data management. The split feels very natural as the codebase grows larger. There is no obvious downside to writing in React besides the minified library code payload. As a summary: our users expect interactions with complex interfaces to respond quickly. React is designed to build interfaces that fulfill that expectation, and the implementation of React in our codebase allows to slide into a more microservices looking architecture in an organic way as the scale and complexity of our app increases.
- wjossey 8y ago
  Our core product offering is a fully white glove 360 review process for small to medium business (mostly startups between 10 and 300 employees). The objective of our process is to deliver highly actionable feedback for each and every participant, so the “review” you fill out for yourself, your manager, and your peers, feels different than a normal form based review. We ask a series of questions, adjust what we ask on the fly, and try to help encourage writing high quality feedback along the way. We do a part of this process during a workshop we run on site, and that tends to mean a bunch of people packed on a single WiFi node. Having the app as an SPA allows the user to fill out their 360s, even on a dreadfully slow network, and not notice. This could have been achieved with jQuery, but given how complex I know this code is under the hood, I shiver at the thought. To the questioner, my email is in my profile. Shoot me an email and I’ll point you towards our demo.