So, you’ll get a two part answer now. Let’s start with your initial question.
I am a React person, and although I have looked at Vue.js (and by “looked”, I’m talking about several days of research, not just reading the README.md
), and I stayed at React. Vue is opinionated, and while that’s nothing bad, it’s just not my taste. ![:slight_smile: :slight_smile:](//discourse.diasporafoundation.org/images/emoji/twitter/slight_smile.png?v=5)
In detail, I dislike Vues template system, for once. I was really happy when we got rid of template languages in React by either using JSX (which basically mixes plain JS calls with plain HTML code), or by using the createElement
functions. I’m liking the latter approach, because it basically allows me to create HTML by not writing HTML, resulting in what is to me pretty code. In addition, it enables (read: forces) you to build generators, maps, … for repeating components. With template languages like the one used in Vue, you often end up doing the classic for loops. That being said, it is true that this makes writing components a bit harder in the first place. However, given that we would end up with a lot of examples to get inspired by, I doubt this is an issue.
Talking about opinionated, let’s talk a bit about data handling. Vue seems pretty opinionated towards Vuex, which is their first-party replacement of Redux, which is a central state management. First, I absolutely do not understand why they even bothered developing Vuex as a fully standalone project. Redux has nothing to do with React, and all their custom integrations could be easily modeled upon Redux. It’s a nice task, but I am not sure if people should reinvent the wheel over and over again. But each their own. Comparing Redux vs. Vuex, Redux is superior in my opinion, mainly for the higher flexibility for extensions, and the tooling around Redux is superb.
At the end of the day, there are some things Vue does nice, and I’d like to completely derail this discussion now and ask another question:
Does it matter?
You made two assumptions I think are not applicable in our case:
- Copying/reusing components from other projects is possible.
- Gradually shifting/filling/mixing Backbone and Framework X is a good idea and we could/should start gradually embedding another framework.
To 1: out of experience, this is not the case. Even if you find a component, regardless if it’s React or Vue, you need to do a lot of work to make it fit your application. In the end, you mostly end up taking over or reimplementing the logic within your application base, and at that point, it absolutely does not matter if the component you get inspired from is using React or Vue. At the end of the day, both framework are using very similar concepts, and porting between them is not a huge deal. The ability of using components should not impact the choice of Frameworks here.
To 2: I disagree.
There is more to a frontend than the view layer. While it is true that you can use Vue with Backbone, so can you use React with Backbone without any issues. Again, this should not impact our decision either. But I don’t think this is a good idea.
We have a lot of issues in our frontend, and some of them are big enough that I do not have fun working on it, and those are not related to the view layer. We have serious issues in the way our data flows and in the way we store and handle said data. We do XHRs everywhere, we have some global data, we have some data provided via templates, and we have a lot of magic. Adding Vue or React will not make this issue go away, if everything, it will make the entire frontend more complicated.
Now, one could say “well, we’ll just write components, and we can reuse them when we fixed our data handling”, and I do not agree with that. The way components are written is highly dependent on the way you let the data flow in, regardless of how good you design your components. So in the end, you’ll end up with a lot of required changes just to adopt to the new data handling.
I actually have even more concerns against adding another framework, but ultimately, I think that, in our specific case, adding another framework to our current frontend is a bad idea.
As we are now at a point where we could rename this thread to “Engineering the new frontend”, let’s actually talk about data handling. Vue seems pretty opinionated towards Vuex, which would be similar to the famous React/Redux combination. For most applications, I’d totally agree that this is great and happily use it, but I am not sure if it is the right choice for diaspora.
Central state storage and bound components like with Redux/Vuex are complex. Like, really complex. When you consider the amount of points we have to pull data from and push data to, we’ll quickly get to a point where data handling is so complex that only people with experience in React/Redux or Vue/Vuex can contribute more complex tasks. Contributor friendliness, in addition to future maintainability, is something to consider very carefully.
Also, I do not feel like a central state storage with bound components is in a good idea for us in general. If you think about it, we actually do have a lot of standalone components with isolated data sources (think about the notification thingy). And maybe, this is reason enough to really design something that works best for us.
I recently had a chat with some of the folks who work on and with Flight by Twitter, which is going “back” to a global event dispatcher, almost a bit like a PubSub channel for the frontend. I do not like some of the decisions they did (like, depending on a lot of jQuery), but I like the idea of a global event hub. In fact, I like this so much that I started playing around with a custom implementation of a “event based data flow” component that keeps its state in Redux and passes it to React. However, this has some other issues I am still in the process of figuring out, and I am not comfortable with claiming that this is a good solution at all. But if you think about this in the scope of diaspora, it actually would make some sense.
To end this post: these are all just brainstormy ideas, not proposals or worked out plans. But I think we should not keep doing as we’re doing, and as you are suggesting, and not work on embedding another framework into our current frontend. I’d like our frontend to be a 100% API consumer, and a nicely designed one.
Instead, I propose to repeat our “success story” we had with our federation core: Throw it away. Think about it. Think about it some more. Draft specs. Think about the specs. Build something fancy, new and maintainable. I think this is the only way we will end up with something that is good, and ultimately, fun.
I am aware that this is a huge project, and I am aware that technically, we are not there yet. We have no API. Still, this does not stop us. We can plan, we can discuss. We can work out UX concepts. And, we have an API spec, so writing a dummy server that responds with predefined JSON payloads is easy.
Maybe we should have some discussions about this first. That is, if we should target a new, from-scratch, implementation, or a gradually changing one. Because that will impact a lot of decisions further down the road.