Iām with @jan about keeping the amount frameworks to the minimum and that we have to look for the long-term.
Although the argument about what we use right now, can be dismantled a bit:
Backbone is more of a data handling library, than a real frontend framework and we use angular 1.x as far as I know, which will become outdated at some point in the future and the switch to angular 2 is a big one. So if we do it, it should be a conscious decision, because from my experience angular2 forces more architecture and is a little harder to get in to. (Disclaimer: Not used vue.js, but played with it and am eager to try it out. Use angular2 in a small project)
I was thinking about migrating the calendar to React once Angular 1 is EOL. But there is still plenty of time before that happens (afaik). And I didnāt discuss the React thing with @tcit yet, so that was only a wild thought and nothing set in stone yet.
Okay so letās take the discussion to the future. If at one point the framework will have to be updated or changed (angular2 etc.) ā¦ having a framework that seperates the backbone from the fronted may come in handy. I like how Vue/React (and this kind of data binding) works with states and a datastore that trickles its updates down to a component tree. This way one hasnāt have to care about keeping data up-to-date and track every view (one of the main reasons Facebook switched to/developed react).
Also if you look at the code in the Movie-DB example above you can see how the certain views load und update data when a component is initialized. Also how one can use ātransformā to animate the interface from one state to the next. Also nice about a virtual DOM ist that one can tell a component/route/view to be persistent and even if it is removed from the actual DOM it still keeps itās state ā¦ so one can reattach it to the current view without loosing itās settings. Not mentioning reusable HTML-like components.
I find Vue.JS more accessible then react. Also it can be used as CDN only (simple to extend existing apps with data bing etc.) or as a CLI with routes (for full app dev).
We definitely had a lot of developers voice complaints about Angular or saying itās not super easy to understand. Also that they change their entire thing from one release to the next doesnāt inspire confidence.
With Backbone, apps use Marionette which I guess achieves the other part. cc @ChristophWurst@MorrisJobke for more JS info.
A move to React could be discussed. Itās one of the first library where lots of JS people I know seem to agree itās great.
Whatever path we take, I think one of ours goals should be to separate our code more into the view technology and the logic behind it. The latter could often be reused across views and even apps. Right now itās all tied together very closely, using plain Backbone. Additionally we have to come up with a proper API for apps, that can be used regardless of the technology stack there.
In terms of React vs Angular vs Vue, Iām currently favoring Vue, because of its simplicity. Also the Laravel project (which is also a big PHP project) adopted it recently. All I know from React is that youāll not be happy without JSX. And you cannot use JSX without a proper build too, which we do not allow. And angular has always been steep in terms of its learning curve, it abstracts away a lot of things which eventually makes debugging harder.
In any case, this is just a personal taste. If we want to move forward, we have to get rid of Backbone in the long run and replace it with a scalable framework. Whichever framework that will be has to be evaluated thoroughly.
Would also consider Vue.js above React, but whateverās chosen, I think the whole Nextcloud apps should migrate to it for better coherence.
As @ChristophWurst said, I also think we should profit from this migration to separate more the view and the logic (es6 classesā¦) and provide better - and documented - js API for the apps.
I thought about migrating the Tasks app to Angular2 but this would certainly (but not necessarily) mean using Typescript. However, I would like to know if there is already a preference in what will be used in the future. I donāt want to start writing code using something which will not be used by the majority of apps.
I just wanted to leave my opinion here since I did a not so small project in Vue 2 for university and have worked with Angular 1.
First of all I really like Vue and itās much easier to work with than with Angular 1, there are less concepts to understand and the browser extension is way better than the Angular version. Also it looks like itās easier to control the performance of Vue than the performance of Angular. (e.g. viewing a table with about 150 records really slowed the Angular app)
But there is a caveat: really please donāt use Webpack. I donāt say webpack is bad (it isnāt actually) but there are some things which makes developing very difficult:
a production build takes about 2 minutes in the project I was speaking of
the output of Webpack is impossible to debug, the errors you get inside your console are a bit random (every variable is mangled and line numbers are wrong). A solution is to use a development server include in Webpack (also reduces the build time) but even then errors are hard to debug. Line numbers are off by a random number (> 30), you donāt know which file caused the error, and integrating the development server inside a project like Nextcloud isnāt that easy.
in my experience the development is very Chrome oriented, what I mean with this is that the development āshouldā work in Chrome and maybe it works in Firefox. But even then things like source maps doesnāt work very well in Chrome.
Also donāt use Babel, yes ES6 is better than earlier versions, babel works perfectly fine and itās actually easier to development in it, but babel makes the three points of above even worse. The generated code is even harder to debug.
Rather than webpack I would go with Grunt or Gulp. In the JSXC app we are using Grunt for some time now and itās actually very handy to work with. With Grunt you have 100% control about how you develop.
TL;DR: go for Vue but donāt use Webpack/Babel etc since itās hard to develop in and will scare new contributors.
Yes, the React.license was another issue but that is resolved. I still think Vue has a lower barrier of entry and works nicely as a āpluginā in any existing codebase.
I have a lot of experience building React/Redux apps, also teaching/coaching this. I recently did some research on Vue and got some intros by enthusiastic people. Although Iām lacking experience here I think it could be a good choice for nextcloud. React/Redux, although much more popular, has quite a learning curve if you want to follow best practices with little benefit for smaller apps. I found some good arguments why Vue could be easier while not having significant disadvantages.
I did a project in Angular 1 a couple of years ago, but found the learning curve way too steep. Then a while back I tried React but had a hard time figuring out how it worked. After reading this thread I gave Vue.js a try and was really impressed. Very easy to dive into.
@xMartin You mention that React is much more popular, they have almost the same number of stars on Github, but there seems to be more than double the number of people using the developer tools for Firefox and Chrome.
Lastly some people say that Vue.js doesnāt work with big projects, but Gitlab is using it and seems to be happy about it. You can read about their decision here. And their follow up a year later here
In a āphilosophicalā percpective, would be more coherent to use Vue, as it is more a community driven project. In my point of view, Vue is to React as NextCloud is to OwnCloud.
React can be more ready to use now, but Vue is growing more, in users, in resources, in projects, in approval (Vue came closer to PHP after adopted by Laravel, Vue is used by GitLab, React has restrictions in China, etc.)
And many AngularJS users feel more āat homeā with Vue than with Angular 2 or 4.
I know this is really old post, but I was not even using Nextcloud back then, so forgive me for resurrecting this old post. The reason why I was compelled to post was the comment @jan made here:
And here im in 2023 experiencing the very thing he mentioned here. In fact this is how i found this post ,searching how to get a grasp of the UX nextcloud/vue. Google sent me here, so blame google
Iām not a āfull stackā developer, or even class myself as a developer Iām more of entrepreneur who knows how to code. Iām familiar with symfony and even Mojavi MVC from back in the day. I have a few really compelling ideas to contribute to Nextcloud but Iām finding it difficult to even create a Mockup. I bemoan the fact that you have embed a framework within a framework with 2 totally different technologies creating twice the work, How do even keep it secure ?
