Gitea: Rewrite frontend

[JWo1F]

Hello!

I’ve been using Gitea for about 3 months and lately I’ve been looking at the frontend. Comrades, it seems he has lagged behind what they are doing now.
I am a front-end developer and in my free time I can do rewriting the front-end to a modern technology stack, which will be much easier to maintain.
I am going to use the API, but I think it will not be enough for my tasks. I ask the help of the community in developing additional API methods upon request for the normal functioning of the frontend.

I am going to use webpack, react, redux and typescript for frontend development. I think this should be a quick SPA. My main task is to separate the frontend from the backend to adequately support all this in the future.

What do you think about this feature? I am waiting for a community reaction in order to understand if this is necessary.

[HenrikBengtsson]

I'm just watching from the sideline, but:

My main task is to separate the frontend from the backend to adequately support all this in the future.

seems like a great design objective for Gitea (maybe it already is? if so, this is a good test) ... even if the end result is that the existing front-end stack is kept.

[sapk]

This is long running task. If you want to have a look at it I would highlight two point you may haven't foreseen :

• We use Vue instead of React.
• Some user disable JS so the UI need to also be accessible without it. Maybe we can have two front-end (similar to what does gmail).

[lunny]

I prefer use vue/vuex/vue-cli and removed all server-side template rendering.

[JWo1F]

@sapk, @lunny, why do you want to use vue instead of react? We can render react at the server (if user disable JS).

[sapk]

AFAIK, it was related to react license and better knowledge of vue by maintainers.
For server side rendering of React, I am curious of what lib you use in Go to do that. Server side of vue is also possible but I don't think with a go implementation.

[lunny]

I would like to make frontend and backend as two parts. Backend we will use golang as before, frontend we should use vue/less as before. :)

[brandonkal]

I would prefer React/Preact or even Svelte over Vue. By doing so, you are likely too see more frequent front-end contributions from others.

[gary-kim]

I would rather we use Vue. Vue is pretty easy to pick up for new and seasoned developers and it doesn't try to stray too far outside handling the view.

In terms of contributions from others, it seems like vuejs/vue has more starts than facebook/react. Although, that's sometimes not a good comparison and according to GitHub's Used By, React is far more common. According to Stack Overflow's 2019 Developer Survey Vue is only lagging behind React by about 1% in their Most Loved, Dreaded, and Wanted Web Frameworks question of being one of the most loved frameworks but it's lagging behind, about half, in terms of Most Popular Technologies: Web Frameworks.

The size of the Preact and Svelte projects do give some pause but I'd say they are big enough that it doesn't count them out.

Also, Gitea was forked from Gogs in part due to not enough community say. Vue, while still being kind of a BDFL, is a far more community based than React or even Angular -if that was on the table- while still being large enough that we can be sure it will continue for a while without the company backing.

With regards to the license, React is now MIT Expat licensed instead of whatever that BSD modified license was but with the CLA that gives Facebook the ability to relicense future versions of the framework, I'd still call it cause for concern.

Also, personally, I work with Vue a lot more often as a few of my open source projects and others I contribute to use Vue. :smile: I've never used React in an OSS project but that may just be the projects I tend to contribute to.

If we decide Vue, I'll make a pr for compiling Vue with Webpack and SFC.

[brandonkal]

I don't follow your first point, because "handling the view" is all that React does.

To be fair, Vue also leads React by that 1% for the most dreaded category.

React leads by 5% for most wanted. They don't give info on the standard deviation but I'd wager these differences are not statistically significant.

Because you are using Semantic UI, there is the Semantic UI React project that has a lot of big contributors. So that is one big selling point.

As someone who has used both, React definitely has the edge in terms of developer grok speed. This is because it doesn't really add any new directives, whereas Vue has a mess of "v-if" among others that are not immediately intuitive.
I expect Vue's popularity will die off as more people switch to React or its lighter Preact cousin. The reason I say this is because Vue invents its own template language that must be learned. That language is sub-par to JavaScript, and reinventing the wheel there is why we've seen Angular die off. Meanwhile, React is just JS. With React you also get JS-in-CSS, something that provides a much better experience than using less.

I mentioned Svelte because its syntax is similar to Vue that the maintainers are familiar with but is the fastest modern framework for a fresh (or unfamiliar) developer to grok. Though I have much more investment in React, Svelte is on my list to build something with.

For on-demand SS Rendering, you'll have to use a node sidecar container as JavaScript has to be evaluated regardless.

I'll offer a PR for webpack and React.

[lunny]

@gary-kim PR is welcome.I never used react so I cannot compare the two. I have used VUE ever and I like VUE too.

[lunny]

@brandonkal We have already used some vue components. So I think convert to react may need more work. Why not just vue? Any obvious problem of VUE?

[brandonkal]

I'll sum my preferences for React:

1. Easier to understand. It's just code. It doesn't put an artificial boundary between its templating language and JavaScript.
2. More contributors likely (including myself and OP)
3. You can ditch jQuery entirely and use React Semantic UI for component logic. Doing the same for Vue would be a monumental task.
4. Productive CSS-in-JS options such as Styled Components or my own brandonkal/linaria for zero-runtime.
5. Removing the build complexity of less because of the above (though with my lib it can be slowly phased out)
6. A simple path to a native phone app
7. The effort to move to Vue SFC would be about the same as to React components
8. More open source components
9. Larger community. More than 2x last time I checked
10. Better typescript integration and testing. Even without typescript, this means a more productive IDE experience.

I bring this up because the refactoring effort would be about the same so now would be the time. Personally I have tried and used Vue a few times and it has never clicked.
I'd be interested in seeing a poll.

[guillep2k]

I'd prefer any path that uses typescript over one with javascript. IMHO, strongly-typed TypeScript naturally leads to better modularized and structured projects. This is helpful for the occasional contributors because it's easier to get a grasp of the project wherabouts.

I don't mean to start a JS vs. TS debate, as I don't have enough real-world experience with any of those, and I know that JS (with JS Doc for example) can do most of the things TS can, but it becomes _too discretionary_ for my liking; it's like "I don't need to JS Doc this function" or "I'll do that later"; if you need to enforce that with code policies, why not just do it at the language level? It's my humble opinion.

[brandonkal]

@guillep2k brings up a very important point. TypeScript has been massively helpful in improving productivity. As long as you don't enable 'noImplicitAny' and some of the stricter options, TS does not get in the way. Type inference with JSX works really well.

Because JSX is JavaScript sugar for calling a function, TypeScript and babel support is much better and natively supported by the TypeScript project. JSX is a nice shared syntax between various libraries and because it is just JavaScript, tooling support is greater.

Completely type-checking Vue won't be possible until and only if Vue adopts HTMLx and the TypeScript teams adds native HTMLx support. I really do want this to happen, but something like that is likely years out and a chicken-and-egg scenario. Vue has JSX but it is a second-class citizen.

Some other points:

1. Smaller API surface: Fragments, createContext, and Hooks. That's all you need to know. Vue has a vast amount of component options, instance properties, template directives, slots, and its own event listening syntax to remember.
2. Favors functions over classes
3. Fragments mean you are not limited to returning exactly one DOM node in a component. This means no div soup and more semantic HTML and better CSS grid support.

To @lunny if you are interested in experimenting with React on your own, I can recommend this project. It was the project where React clicked for me, and I find it rather intuitive.

Anyways, I believe this is enough info for a decision to be made. I would recommend React/Preact with TypeScript + Semantic UI React.

[lafriks]

To be honest I have used quite much both Vue and react and coming form angular to react and later to Vue, I can say that Vue is so much easier to use and so much cleaner and lighter that I would really hate to see react being used in this project

[lafriks]

Also we should really move away from semantic UI because it is quite awful css framework with lot of !important usage

[techknowlogick]

Thanks all for the feedback. I've locked this issue as it has gathered all the information needed, and we will go from there.

As the project is currently using Vue, and it has the maintainer team has most experience with that we will continue to use it. However we are certainly always working on improving the API so that alternate SPAs are possible. I know there are already some people already doing that (sadly their implementations are not open, otherwise I would link them here).