7 ms·

To the author of the article- Kudos! Well written, well reasoned, with minimal hyperbole or unnecessary “X is dead” style declarations. Hope we see more writing

To the author of the article- Kudos! Well written, well reasoned, with minimal hyperbole or unnecessary “X is dead” style declarations. Hope we see more writing like this bubble up to the top on HN. I’m not swayed by the argument, but that’s personal bias. I’m the technical cofounder / solo coder of a venture backed startup, and I built our platform on rails 5. I migrated our front end to Vue over the winter and couldn’t be happier. When we started (my cofounder and I) our company in early 2017, it had been a few years since I coded daily, and I’ve never been a front end programmer. I’m not well skilled in JS, so I punted on using any front end frameworks for the first six months. Our entire MVP was rails 5 server side rendered pages, with a dusting of jQuery when needed. It definitely got me as far as I needed it to, but I felt a lot of pain once I began to try to mix in a lot more interactivity in the app. For me, migrating to Vue made a lot of sense and continues to pay dividends. For others, the author’s arguments are probably far more applicable. One area where I deeply agree with the author is around how in JS I often don’t know exactly where I should write certain parts of my code. For a long time, I had a lot of model logic in my Vue components, but that quickly became a nightmare and I’ve abandoned that. Now I use ES6 classes to wrap a bunch of my logic, but even then I still find stuff bleeding places that seem wrong. One thing I also avoided so far was using any state management (a la Vuex). In some rare examples I use a message bus to send information around, but even then that usually triggers a component to go refetch information from the source of truth (the API endpoint). So far this pattern helps to restrict me from making certain lazy choices which will feel good in the moment but become maddening in the future. My app, as such, is not as maximally performant as it could be, but the trade off for the rare update has so far felt worth it. So, to sum it up, as a veteran coder who spends 12 hours a day writing code, but knew rails really well and not any SPA frameworks, I’m sympathetic to the article but respectfully have a different experience.

sho 8y ago
> I felt a lot of pain once I began to try to mix in a lot more interactivity in the app I don't think you're actually disagreeing at all. You're using the right tool for the job. You started with one job and the right tool, and when the job changed you switched tools. That's as it should be! Use Rails until you can't. That's what you did and I can't see the author disagreeing. You can generalise this to most technology. I know someone who has gotten it into his head that he needs to write his entire new web app using golang and microservices. I'd suggest that when he actually outgrows Rails enough to require that then he can suggest it to his 50-person-plus engineering team, but in truth I don't think he'll ever actually finish it.
- debaserab2 8y ago
  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.
zitterbewegung 8y ago
I think that prototyping your software with (insert server side software ) and jquery is a really good way to prototype. It lets you get to market and or fail faster .
- emodendroket 8y ago
  I think that quickly becomes untrue if you have any significant amount of front-end functionality.
  - zitterbewegung 8y ago
    Can you expand on significant amount of front-end functionality ?
    - emodendroket 8y ago
      Writing jQuery to accomplish a feature like hiding one element if another is checked is significantly more code and more error-prone (not to mention difficult to test) than doing the equivalent thing with a tool like Angular is.
      - GordonS 8y ago
        It's 1 line with jQuery, so I guess "significantly more" is relative?
        emodendroket 8y ago
        Alright, fair, you could just assign a toggle on click, but if the interaction is any more complex than that (check some other form value, see if multiple different boxes are checked, etc.) it's not.
        _Tev 8y ago
        Every spaghetti ball starts with these one liners. Using just one line implies no structure or separation of concerns (needed for anything complex), which is why nobody is talking about this case, and immediately jumping to theoretical "SPA-like functionality, but implemented in jQuery". EDIT: as for your original question ("significant amount of FE functionality"), from my experience jQuery loses a lot of its appeal when you have over 1k lines of JS, and I guess over 5k JS frameworks (React, Ng, Ember, Vue) start to be significantly better. When over 10k jQuery would be crazy mess (I have seen one such project, it was fun trainwreck).
EGreg 8y ago
If you use PHP and you like turbolinks etc. then look at this: https://qbix.com/platform/guide https://qbix.com/platform/guide It has pages and AJAX out of the box, and works with existing web tech. Turn your website into an SPA.
rlafranchi 8y ago
I’ve had a wonderful experience using Vue in Rails applications and there are ways to do this without building a full blown SPA. The philosophy towards JS frameworks has usually been full throttle or not at all. I think there is a happy medium where you can use Vue when it makes sense to. This is a great application especially for existing projects that need to be more interactive.
- GordonS 8y ago
  I've used the same approach on some web apps, but combining ASP.NET MVC Core with Vue. I think it's quite common for web apps to have only parts that have a complex UI (even if it's the main part), so this pattern makes a lot of sense for some teams.
greenhatman 8y ago
How do you handle SSR for SEO? Or do you not need SEO?
- wjossey 8y ago
  I don't need SEO for what I've released so far, and the pages are properly indexed by Google, despite being SPAs. Our product is primarily B2B, so the website isn't a destination at the moment. If I needed to have SEO friendly pages, there are SSR solutions I would look into using (like nuxt) or just pre-rendering the pages myself (I already use puppeteer for PDF rendering elsewhere in the product).
manquer 8y ago
My experiences are pretty much the same, the important distinction was when we added support for mobile apps, the API design problems had to be solved anyway, and significant differences between the interfaces for both mobile and web made it a pain to work with, we shifted to full API driven back-end and ember front-end and I cannot be happier. I think the author is missing the fact that it it hard to justify Rails only approach if you have to support mobile interfaces and HTML is not only medium you are working with.
- jgalentine007 8y ago
  This is what is pushing me to write spa first now - it covers all the consumption bases. You get desktop, mobile web/progressive/hybrid and half of native.

sho 8y ago

> I felt a lot of pain once I began to try to mix in a lot more interactivity in the app I don't think you're actually disagreeing at all. You're using the right tool for the job. You started with one job and the right tool, and when the job changed you switched tools. That's as it should be! Use Rails until you can't. That's what you did and I can't see the author disagreeing. You can generalise this to most technology. I know someone who has gotten it into his head that he needs to write his entire new web app using golang and microservices. I'd suggest that when he actually outgrows Rails enough to require that then he can suggest it to his 50-person-plus engineering team, but in truth I don't think he'll ever actually finish it.

debaserab2 8y ago
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.

zitterbewegung 8y ago

I think that prototyping your software with (insert server side software ) and jquery is a really good way to prototype. It lets you get to market and or fail faster .

emodendroket 8y ago
I think that quickly becomes untrue if you have any significant amount of front-end functionality.
- zitterbewegung 8y ago
  Can you expand on significant amount of front-end functionality ?
  - emodendroket 8y ago
    Writing jQuery to accomplish a feature like hiding one element if another is checked is significantly more code and more error-prone (not to mention difficult to test) than doing the equivalent thing with a tool like Angular is.
    - GordonS 8y ago
      It's 1 line with jQuery, so I guess "significantly more" is relative?
      - emodendroket 8y ago
        Alright, fair, you could just assign a toggle on click, but if the interaction is any more complex than that (check some other form value, see if multiple different boxes are checked, etc.) it's not.
      - _Tev 8y ago
        Every spaghetti ball starts with these one liners. Using just one line implies no structure or separation of concerns (needed for anything complex), which is why nobody is talking about this case, and immediately jumping to theoretical "SPA-like functionality, but implemented in jQuery". EDIT: as for your original question ("significant amount of FE functionality"), from my experience jQuery loses a lot of its appeal when you have over 1k lines of JS, and I guess over 5k JS frameworks (React, Ng, Ember, Vue) start to be significantly better. When over 10k jQuery would be crazy mess (I have seen one such project, it was fun trainwreck).

EGreg 8y ago

If you use PHP and you like turbolinks etc. then look at this: https://qbix.com/platform/guide https://qbix.com/platform/guide It has pages and AJAX out of the box, and works with existing web tech. Turn your website into an SPA.

rlafranchi 8y ago

I’ve had a wonderful experience using Vue in Rails applications and there are ways to do this without building a full blown SPA. The philosophy towards JS frameworks has usually been full throttle or not at all. I think there is a happy medium where you can use Vue when it makes sense to. This is a great application especially for existing projects that need to be more interactive.

GordonS 8y ago
I've used the same approach on some web apps, but combining ASP.NET MVC Core with Vue. I think it's quite common for web apps to have only parts that have a complex UI (even if it's the main part), so this pattern makes a lot of sense for some teams.

greenhatman 8y ago

How do you handle SSR for SEO? Or do you not need SEO?

wjossey 8y ago
I don't need SEO for what I've released so far, and the pages are properly indexed by Google, despite being SPAs. Our product is primarily B2B, so the website isn't a destination at the moment. If I needed to have SEO friendly pages, there are SSR solutions I would look into using (like nuxt) or just pre-rendering the pages myself (I already use puppeteer for PDF rendering elsewhere in the product).

manquer 8y ago

My experiences are pretty much the same, the important distinction was when we added support for mobile apps, the API design problems had to be solved anyway, and significant differences between the interfaces for both mobile and web made it a pain to work with, we shifted to full API driven back-end and ember front-end and I cannot be happier. I think the author is missing the fact that it it hard to justify Rails only approach if you have to support mobile interfaces and HTML is not only medium you are working with.

jgalentine007 8y ago
This is what is pushing me to write spa first now - it covers all the consumption bases. You get desktop, mobile web/progressive/hybrid and half of native.