First of all, I’m very glad to see that discussion happening
I never worked with React nor Vue so I can’t tell which one should be pick. Most of my developer friends I asked this question answered Vue, saying things like “Something always bothered me with React, Vue feels smoother and more intuitive to use”. However keep in mind that they don’t know the diaspora* codebase, so it doesn’t mean Vue is the solution for us.
As for restarting from scratch vs changing one part at a time, although the first solution looks more fun and nice, I’m afraid we will never see it live. I mean, we have hundreds of small issues open that we don’t have time to fix, where will we find the resources to rewrite everything? That’s such a massive work.
So was rewriting the entire federation source. Took quite a bit, but you know what, it turned out working, and the result is superior to what we could have achieved with staying at the old codebase. Also, what is the alternative? Replacing all views in Backbone with new stuff? Staying on two solutions forever™? Have you considered the extra amount of work that would be needed for maintaining that? I doubt that the actual work effort is that much higher in the long run.
Funny this blog post is talking about Netscape, when in fact, Mozilla just rewrote large parts of the rendering engine. Was it a bad decision? No. Did Netscape/Mozilla go out of business? No. So what. This post is generalizing everything and claiming like re-engineering solutions is never good, completely disregarding the reality. You cannot turn a car into an airplane without starting from scratch. It’s just not going to happen.
Also, this, from the year 2016. You know what, I don’t care what other people are saying. I care about what the people involved in this project are saying, and that’s about it. Decisions have to be made within a given context, and not based by blog posts that ramble on some points because they think they are right.
Would a rewrite be a large task? Yeah. Might it fail? Hell yeah. So what? I’m honestly more concerned by the risk of us not being able to maintain the frontend in an adequate way (which, by the way, is the case right now) then the fact of us potentially delaying or rethinking a frontend reimplementation.
($0.02, and probably the last comment of this kind in this thread)
I’m not good enough at frontend development to actually tell why the approach you propose to try might be better than others approaches mentioned. I think I would just trust you with that it is something worth trying.
Do you think there is something I can do now to contribute to this research?
Can you describe some intermediate tasks which could be seen as a step towards our eventual UI approach? For example you mentioned “event based data flow” component based on React/Redux. Maybe it is possible to try implementing some of our UI components logic on top of this approach? And therefore see what issues it brings up.
But I agree with @denschub, doing a complete clean rewrite sounds much better than trying to mix things up. It probably takes some time until it’s finished and you see some results, but when it’s finished it’s worth it. When it’s never finished, then that’s sad, but at least we don’t end up with a half mixed frontend (when we would start to mix our current frontend with a new one, but not finish that) where it is even harder to do anything than with the current frontend. And it’s probably less work when you can just start from scratch instead of making sure that you don’t break anything existing by everything you touch. And I don’t regret that I’ve done that with the federation rewrite. It was a lot of work until seeing results, but it was totally worth it!
For the other discussion (which framework to choose), I don’t know both of them, so I can’t say anything about that topic.
Well, actually the federation rewrite was also gradual to some extent. We had some distinct steps and even the huge PR for the new gem integration was split to some commits which were gradual steps as well.
So even if we do accept the new UI paradigm it wouldn’t be “throw everything away at once”. It would be still gradual at least to some extent.
How do you think, guys, maybe I can build the front end for the seed migration feature based on the new UI paradigm? It could be a good playground, since it would be largely isolated from everything else.
Yikes. At the moment, no, not really. I’m only spending some hours per week on that at max and it is not open sourced yet for a reason. But I take this as a motivation to change that.
Well, if we decide to carefully reengineer things, a really good point of start would be to make a list of our current UI components, then go over each and consider UX and UI ideas to come up with a solution on how it could/should be. But since that requires a lot of time, I’d do that only after we decided that we indeed want to “start over”…
That being said, if you really think this is the way to go and want to have a playground to implement against, one could write a little dummy server (possibly using Sinatra or something lightweight) that respons with some API JSON dummies as speced. Not sure if this is a good approach at the current state, though.
Maybe my federation example wasn’t the best. As said before, I do not think it is possible to “gradually rewrite” the frontend without making different design decisions in the first place. And when we decide to rework data handling later on, this would be a huge effort to adopt the “just recently” created components.
If we’re planning on having a new, clean UI that is internally designed well, I think we should not built upon something that is not.
I don’t think so. At least not until we decided we want to have two frameworks in the frontend. There is no way to have a truly isolated environment in the frontend, since all dependencies are packed together and you cannot use one framework on one page but another framework on another page.
The only separate steps for the federation rewrite were the webfinger parts. But the last step was really one big PR. Sure there were many commits in there (and I hope that a UI rewrite also has multiple commits and not just a single “New UI ” commit ). But only after the last commit was functional. The other commits I just deleted old stuff without taking care if something breaks and then add the new federation stuff.
And I think we can save a lot of time when we don’t need to take care that we don’t break the existing UI and just write a completely new one. Maybe we can add part by part to the new UI and already add it as separate beta UI (like the mobile UI is also separate). But I don’t know how easy this is and if it’s worth it (since it would be really incomplete in the beginning).
This is a good discussion here, so I take my chance to contribute…
For the framework decision:
I’m working all day with React and Redux in my daily job, so my preferred way to go would be React.
I did not yet work with Vue.js, but I heard a lot of it.
Vue is easier for people coming directly from Angular I heard.
So it seems we are all agreeing on the fact that Angular is dead and we currently have React and Vue in the ring.
But things in the web are changing fast these days and since our new UI is still far away, I’m not sure when we should decide for a technology.
For the rewrite discussion:
I also don’t think we should embed any new framework in the current user interface.
So in my opinion what we need is a modern web application rewritten from scratch which does nothing than consuming a well designed API.
I don’t know, how it is possible to integrate a beta UI (like with the mobile UI) because it has to be all bundled together somehow and of course we should avoid having multiple UIs for a long time (like with the mobile UI).
Talking about components:
There are lots of nice component collections out there, so we can also think about using some of them instead of write all standalone components from scratch.
Even if you all want to hit me now for posting this link, in my daily business I often work with some of the React components of Microsofts Office UI Fabric React with some good components for a social network like the “Aspect Pickers”.
There are lots of other well-maintained component libraries out there, so we wouldn’t have to rewrite everything.
While the Facebook webapp has a similar front-end requirements and similar components as diaspora (streams, notifications, contacts, private conversations, profiles, etc) they make use of Flux and central state storage. I feel your point is right, but how does it work for Facebook then?
Or they don’t use a central state storage and use multiple independent state storages in the same app?
Oh, one can make things happen in a lot of different ways! Certainly, a central trust storage is never a really bad idea, and it makes a lot of sense if everyone is familiar with the concepts and the layout of that central storage.
As for diaspora*, however, we have a lot of different developers and should, at least in parts, aim towards being more contribution friendly. I don’t want to build something new that ends up being incredibly complex, putting contributors in a position where they have to understand that trust storage and its entire data, and also the flow of data, to be able to work with it.
If you, in contrast, consider something like a global event bus, “the experienced, core developers” have to come up with the events and their payloads, but each individual component is able to simply listen to them, and building data flow based on callback functions off those events, for example. That makes the individual components much more isolated from the global environment, and maybe a bit simpler for new people to work on.
I want to get back to the front-end topic with one more question. Time goes by and there’s no news on this one, and I think the community still wants improvements to the front-end of diaspora*. We have talked here about fully rewriting the front-end of diaspora* here, but the work is not in progress, is it? So this doesn’t have to block improvements to the current version of the diaspora front-end.
One of the legacy things we have in our front-end is component dependency management. We’re using rails-assets.org which relies on bower which is kinda deprecated now. Also some of the front-end packages we’re using are built specifically for Rails as Ruby gems. Today NPM is usually used to get packages for front-end.
With the present dependency management if someone wants to import a new JS package to diaspora they have to either create a bower package which doesn’t make too much sense in 2018, or create a Ruby gem manually, which is not a great time investment, or just include the source code of the component directly to diaspora*.
Most of the modern JS libraries are primarily distributed using NPM. Rails now has rails/webpacker which is something like an official support for NPM in Rails.
If we want to keep improving our current front-end, I think that including Rails webpacker support is a nice thing to do. This will make it easier to use some up-to-date packages which are only available as NPM modules. And it will make it easier to share some front-end code which we develop for diaspora as external packages so that these package might be used in some other projects.
As a short example, I’ve been working with @jcbrand on making a headless build of converse.js which can be integrated in other projects, but it is delivered either as a file or as NPM package, so this is where we could use webpacker to easily integrate this package.
So my question is: what’s the diaspora* core team’s opinion on enabling rails/webpacker for diaspora?
I actually am not in favor of using rails/webpacker, or anything like it. I actually think we should completely decouple the backend and the UI, and if we do any severe frontend work, this probably (<- my opinion, not a general consent) should be our goal. I think I hinted at that earlier, but never elaborated on it, so here we go.
In my dreams, we have implemented the entire API already. Therefore, we could build our client 100% as an API consumer, except for maybe a little bit different login flow to keep the UX constant. And if that is the case, there is no reason to couple backend and frontend sources together, so they should end up in two separate repositories. This might seem overly complicated in the first place, but there are actually pretty compelling reasons to follow this approach.
Separations of concerns always is a huge topic, and by decoupling UI and backend, maintaining parts of the projects can actually become easier. It doesn’t matter what backend changes you perform, as long as it still responds with the API we defined. Also, no matter how your frontend architecture looks like, it’s absolutely fine as long as it can handle the clearly defined API.
The backend gets more friendly for Ruby-developers to contribute to, as they are less likely to be forced to touch frontend codes if they just touch the way API payloads are generated.
Likewise, frontend developing is much easier and much more contributor-friendly, as they could focus on exactly their frontend world, without the need to touch anything related to Rails. Heck, they even could develop their frontend using a real-world, live production pod to test their implementation, as the API would be considered somewhat stable.
Developing new features gets a bit easier for backend folks. Instead of designing controllers and views for the frontend and the API, they just have to create the API. Granted, it might require some more discussion around payloads and response formats, but this still should be a win at the end of the day.
Because of this approach, we’d never end up features with non-existent/incomplete API routes. Our official client would consume the API, so implementing a feature without exposing an API would literally be impossible. We’d also immediately be aware of issues and unexpected requirements.
Customizing the UI, or even building independent UI projects for different needs (like special accessibility needs, or just fancy UX ideas), would be super easy.
So, in my opinion, we should maybe hold off any frontend work until the API is done (says the one supposed to work on the API for a couple of years, I know), and build something new when the API is done. Is that adventurous and maybe a costly (in terms of work required) idea? Yeah, for sure. But ultimately, I think it’s a good idea, both for our own happiness (as it would make code less dependent on tasks outside one’s individual expertise) and user happiness (as we would finally get the chance to re-imagine the user interface in a way that actually makes sense for the user, without continually having to fight backend restrictions).
If you, or anyone else, have serious interest in starting that work, maybe even based off an API mock server to get things going, please reach out to me. I have both some UI drafts and a general frontend architecture idea, both are unfortunately not in a state where I could share them publicly, but we can get there if needed.
Iam just an outsider, who currently dives into the state of the project. But working with and building frontends is part of my job.
First off, “hold off any frontend work until the API is done” is always a critical point. In a Company it is usually problematic to block feature development for more than half a year (actually more likely 2 years and more for a rebuild)
You can argue this is less of a topic for a OpenSource project with just a hand full of people, so I will try another argumentation-chain.
For OpenSource you have a special situation as you have a very undefined Team with high fluctuations of different skill levels and expectations.
I clearly support putting a majority of work into building a Frontend System, which is just interacting via an API with the Backend. (and I really would like to participate here, but did not found a url in this thread)
But, still allowing continued work on the existing system is important to gain new contributors, who are maybe not so experiences with building new architectures, but are able to modify and extend an existing codebase. Blocking new willing contributors over a timeframe of several months will drive them away longterm and makes it a lot more likely, they will instead bind to another open source project, or even non at all.
By still allowing contributions there, you will only need to invest a minimal ammount of time for reviews. Its even possible to establish from this new contributors a Reviewing group, which can minimize the review work the current core team needs to do. And you dont even need to handle them with the highest priority.
The thing I want to say is: If there are people who want to improve the old approach, see how to make it possible without hindering yourself from working on the new approach.
Be supportive, positive, enabling.
As long as it does not lead to significant problems or more work for the core team in the next few months, there is no good reason to block or deny work on the old approach.
In my dreams, we have implemented the entire API already. Therefore, we could build our client 100% as an API consumer, except for maybe a little bit different login flow to keep the UX constant.
Oh good I thought I was the only one who thought that if we had the API finished that this would be the preferred mechanism for interacting with the new UI (desktop and mobile). It’s why I want to make it such a priority with my development time on this project right now.
I spit the other discussion off this thread. I think it’s important to have a thread about “when will it be done” that we can link to, but let’s keep this about the frontend framework and the frontend framework only, and continue the other thing here.
FYI as I use the API I think we are going to have to look at how OpenID is configured or what we want to do with the authentication to the main website since we will have a bit of a chicken-and-the egg problem with the users having to validate API access to the Website but they need to be logged into the website to do that, etc. I’m not worried about that problem since it is in the authentication layer not directly in the API implementation but I thought I’d bring that up as something I’m discovering as I’m dogfooding the API with an external driver program. Once the API is feature complete I intend to go back around and starting looking at that.