one great development for Frontend is React. It is a bit steep in its approach but that’s why VUE 2 is so great. It can just be included in any frontend (few KB, much less then jQuery) and does Databind, Transformations and Templates out of the box.
It is the perfect VIEW for all our data and could unify development (Frontend across plugins) as nextcloud could offer also some core components to make live easier.
For even further integration and code seperation on can step it up to VUE 2.x CLI and use .VUE-files with webpack etc. and all the node.js goodness.
Check out:
Youtube video to get you started in a minute with any HTML-Page:
A lot of this sounds like it will create giant barriers to entry. Tech like this is cool for small projects with small communities, but not for bigger projects like Nextcloud.
Technologies come and go these days, and a lot of the stuff that has come in the 7+ years Nextcloud exists has gone again. Before deciding to use something, we really need to be sure that it provides a lot of value for the investment.
We already use different tech stacks for different apps like Backbone for server, Mail and Video calls, and Angular for Calendar, Contacts, News etc. This is something we should rather unify instead of introducing yet another technology.
Yes, having a backlog makes implementing something new rather hard. I must admit it is very young but the reactive approach (virtual DOM) has some rather nice attributes.
So I accomplished at least the minor goal of bringing this kind of data binding and frontend templating to your attention.
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.
