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.
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 .
Maybe for you. I write React and a web API (using Swagger in Ruby or TypeScript/NodeJS) significantly faster than I do any server-side framework I've ever used. React components are an easier way to frame HTML--here, let me not remember how Bootstrap elements are created and just invoke --and JSX is the most fluid and flexible templating system I've ever used.
Dealing with stateful and rickety jQuery is why I stopped doing web stuff in the first place. Having React and a halfway decent dev environment in ES6/ES2017 and now TypeScript brought me back.
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.
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?
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.
> 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"?
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".
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?
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!
On the server side I use Express in Node and either `tsoa` or `inversify-express-utils`, while in Ruby I use my own Modern[0] library to autogenerate a Swagger document from the controllers I specify.
[0] - https://github.com/lukeautry/tsoa