4 ms·

This is now my feeling as well, after coding in Vue for only 9 months. If I started a project tomorrow, I'd use Vue on day 0 100% of the time. Even if I'm just

This is now my feeling as well, after coding in Vue for only 9 months. If I started a project tomorrow, I'd use Vue on day 0 100% of the time. Even if I'm just rendering HTML, the process of using it helps me to separate out my components and break them down into small and understandable pieces. I'm sure I'd get the same benefit from Ember, Angular, React, etc., if I knew those frameworks as well. My feeling is that I don't experience a startup tax with using a frontend framework, like Vue. To me, it's now as natural as using Rails on day 0.

andrei_says_ 8y ago
I’ve used both Vue and Rails. Rails partials does meet my needs for compartmentalizing code. Don’t really see what benefit would I get for adding the complexity of separating the front end in its own layer. Turbolinks gives me the speed of an SPA and I get 5x the dev productivity by not adding one. And I absolutely love Vue. What am I missing?
- wjossey 8y ago
  You're probably just not writing that much javascript, or needing javascript, so it sounds like you're not missing anything! I don't find using Vue adds complexity for me anymore, and I enjoy a lot of the benefits of it (component libraries, scoped styles). That might not be enough for you when you're working with mostly vanilla CRUD pages, so I totally get it. If your productivity goes down with Vue, then it should take a big reason to add it. For me, it at minimum is not net negative, and I'd say even for trivial pages it's a net positive.
  - brandonmenc 8y ago
    > That might not be enough for you when you're working with mostly vanilla CRUD pages > I'd say even for trivial pages it's a net positive Curious, what do you consider more complicated than CRUD, yet simultaneously "trivial"?
    - wjossey 8y ago
      Poor choice of words on my part. For me, using Vue is worth for CRUD pages, trivial pages (pure HTML), etc. There's enough it gives me that even though I don't need it, I enjoy utilizing it in my workflow. What I was attempting to express is that I understand that for many, it doesn't give them anything in a basic CRUD page, and in fact can add a lot of complexity when you move away from built-ins with the backend framework (like what rails gives you). So, I can get why someone might say "it's not enough".
      - andrei_says_ 8y ago
        Reading this, I am windering if the way I am approaching Vue is more complex than the way others do. Could you outline your approach to including Vue, to carrying state and changes from the rails api to the Vue-powered views, incl. initial state? Do you think you could share a code sample?
        wjossey 8y ago
        Hey Andrei! I don't have any clean code examples easily handy, but let me work on it for you. Shoot me an email (email is in my profile) and i'll share a gist with you. The tl;dr is: [0] Use single file components [1] API endpoints return JSON. Nothing super fancy, just taking rails objects and return JSON. [2] What would have been a rails "view" corresponds with a route in my vue-router config. Nothing special there either. [3] A top level page (think /index or /item) [4] Each top level page calls a private endpoint, which is just its own natural route in the browser, and pulls down data it cares about through the JSON request. Each json object corresponds with an ES6 class which wraps any object specific logic (usually end up having to dupe some code between ruby + js here). [5] Each top level page is broken down into components (widgets, major sections of the page), for code clarity. [6] Anytime I find myself doing a for-each loop, I usually look to see if whatever the sub element is should be its own component. Usually the answer is yes (just depends on whether it has its own independent logic). Everything is passed top down as an object, but I do break the "cardinal sin" of mutating props on the object. Traditionally, props should be immutable in Vue, which requires use of Vuex or an event bus to change state. I haven't had a case yet where this has been an issue, likely because each page transition reloads whatever data it needs, and the same object isn't being mutated by multiple components in a way that would cause debugging nightmares. A few patterns I use to keep myself sane are wrapping objects with their own save methods (so I can just .save() ) an object and persist it back to the server. I dunno, probably a lot more there, but I haven't given this any deep thought. Reach out, and let's exchange thoughts!
- eropple 8y ago
  You're missing that writing TypeScript, for a lot of people (myself included these days, if we're being honest), is a lot faster than writing Ruby. My productivity has spiked a ton by moving almost exclusively over to Swagger APIs in TypeScript and continuing that by writing a (relatively easy, relatively quick, not-magic-Rails-junk) React frontend is just the path of least resistance. And I like Ruby.
- _Tev 8y ago
  I think both sides are doing something different. If you want to prototype / start new project with complex UI (think filterable lists / tables, communication apps, dashboards, ...), you are building the app around the client and SPA is natural choice If your app is more like (simple) CRUD app, then you probably don't need SPA features, and they might even slow you down. There is no clear line between those two, so lot of the time you can do both approaches, but in the end your desired UI complexity drives the tradeoffs.
  - andrei_says_ 8y ago
    This makes sense, for the few views which contain the complex UI. What I’m having a hard time with is the suggestion to replace all views. I don’t see the benefit in that.

andrei_says_ 8y ago

I’ve used both Vue and Rails. Rails partials does meet my needs for compartmentalizing code. Don’t really see what benefit would I get for adding the complexity of separating the front end in its own layer. Turbolinks gives me the speed of an SPA and I get 5x the dev productivity by not adding one. And I absolutely love Vue. What am I missing?

wjossey 8y ago
You're probably just not writing that much javascript, or needing javascript, so it sounds like you're not missing anything! I don't find using Vue adds complexity for me anymore, and I enjoy a lot of the benefits of it (component libraries, scoped styles). That might not be enough for you when you're working with mostly vanilla CRUD pages, so I totally get it. If your productivity goes down with Vue, then it should take a big reason to add it. For me, it at minimum is not net negative, and I'd say even for trivial pages it's a net positive.
- brandonmenc 8y ago
  > That might not be enough for you when you're working with mostly vanilla CRUD pages > I'd say even for trivial pages it's a net positive Curious, what do you consider more complicated than CRUD, yet simultaneously "trivial"?
  - wjossey 8y ago
    Poor choice of words on my part. For me, using Vue is worth for CRUD pages, trivial pages (pure HTML), etc. There's enough it gives me that even though I don't need it, I enjoy utilizing it in my workflow. What I was attempting to express is that I understand that for many, it doesn't give them anything in a basic CRUD page, and in fact can add a lot of complexity when you move away from built-ins with the backend framework (like what rails gives you). So, I can get why someone might say "it's not enough".
    - andrei_says_ 8y ago
      Reading this, I am windering if the way I am approaching Vue is more complex than the way others do. Could you outline your approach to including Vue, to carrying state and changes from the rails api to the Vue-powered views, incl. initial state? Do you think you could share a code sample?
      - wjossey 8y ago
        Hey Andrei! I don't have any clean code examples easily handy, but let me work on it for you. Shoot me an email (email is in my profile) and i'll share a gist with you. The tl;dr is: [0] Use single file components [1] API endpoints return JSON. Nothing super fancy, just taking rails objects and return JSON. [2] What would have been a rails "view" corresponds with a route in my vue-router config. Nothing special there either. [3] A top level page (think /index or /item) [4] Each top level page calls a private endpoint, which is just its own natural route in the browser, and pulls down data it cares about through the JSON request. Each json object corresponds with an ES6 class which wraps any object specific logic (usually end up having to dupe some code between ruby + js here). [5] Each top level page is broken down into components (widgets, major sections of the page), for code clarity. [6] Anytime I find myself doing a for-each loop, I usually look to see if whatever the sub element is should be its own component. Usually the answer is yes (just depends on whether it has its own independent logic). Everything is passed top down as an object, but I do break the "cardinal sin" of mutating props on the object. Traditionally, props should be immutable in Vue, which requires use of Vuex or an event bus to change state. I haven't had a case yet where this has been an issue, likely because each page transition reloads whatever data it needs, and the same object isn't being mutated by multiple components in a way that would cause debugging nightmares. A few patterns I use to keep myself sane are wrapping objects with their own save methods (so I can just .save() ) an object and persist it back to the server. I dunno, probably a lot more there, but I haven't given this any deep thought. Reach out, and let's exchange thoughts!
eropple 8y ago
You're missing that writing TypeScript, for a lot of people (myself included these days, if we're being honest), is a lot faster than writing Ruby. My productivity has spiked a ton by moving almost exclusively over to Swagger APIs in TypeScript and continuing that by writing a (relatively easy, relatively quick, not-magic-Rails-junk) React frontend is just the path of least resistance. And I like Ruby.
_Tev 8y ago
I think both sides are doing something different. If you want to prototype / start new project with complex UI (think filterable lists / tables, communication apps, dashboards, ...), you are building the app around the client and SPA is natural choice If your app is more like (simple) CRUD app, then you probably don't need SPA features, and they might even slow you down. There is no clear line between those two, so lot of the time you can do both approaches, but in the end your desired UI complexity drives the tradeoffs.
- andrei_says_ 8y ago
  This makes sense, for the few views which contain the complex UI. What I’m having a hard time with is the suggestion to replace all views. I don’t see the benefit in that.