Enable JSX support in frontend

[silverwind]

This enables frontend to use JSX to generate DOM nodes using the jsx-dom module. JSX is inherently safer than concatenating HTML strings because it defaults to HTML escaping. Also it is easier to work with and more powerful than template strings.

To demonstrate JSX usage, I've rewritten the context popup feature to use it, looks pretty much exactly as before:

Generally the aim of this feature is to provide a safe and convenient alternative to string concatenation to generate DOM elements. I plan to migrate more string usage to this method after this is merged.

[silverwind]

Switched to vhtml which is a more lightweight JSX rendering alternative that outputs strings instead of DOM elements which I think is more suitable to our general use cases. Escaping is still taken care automatically and we save around 8kB unminified bundle size with it compared to jsx-dom.

[silverwind]

Some more refactors done. Moved the JSX components to its own file and added a informational comment about them.

I've been attempting to test the components but could not get the JSX tranformation to work with the unstable version of Jest, so I guess we'll have to wait a bit for jest to stabilize their ESM features.

[silverwind]

I guess I may actually switch it back to jsx-dom because one can not bind event handlers on strings which would prove inflexible later on. Putting on WIP until then.

[lunny]

Why not just continue with vue but switch to JSX ?

[silverwind]

Vue/React are for SPA-style rendering (e.g. build DOM elements and render/update). Only few isolated components in the UI use this type of renderning.

This JSX usage is for cases where we only construct DOM elements/HTML and insert them manually (.innerHTML or jquery .html()). There are many such cases in the codebase and they are inherently unsafe with user-generated content unless properly escaped. Using JSX makes this type of rendering both easier and safe from escaping-related errors.

[silverwind]

Using Vue JSX later on should be possible, we just need to define multiple jsxFactory functions and do filename-based matching to route different files to different JSX transformers. Thought it seems Vue depends on Babel for their JSX transform which I'd rather not like to re-introduce, so we probably can't have that.

[silverwind]

Switched back to jsx-dom and cleaned up a few more things to keep the diff minimal. Ready again.

[lunny]

CI still failed.

[silverwind]

Can't be related, rebased.

[lafriks]

I would also prefer that these components be converted to Vue instead of jsx, we already have way too big frankenstein in fronted to introduce yet another concept

[silverwind]

I'm not going to do Vue, sorry. I could easily convert all current string-built HTML to JSX but to me Vue is a framework I deeply disagree with and I'd rather like to get rid of it in favor of React.

The JSX currently returns plain DOM elements but could easily be converted to React later. Maybe also migrate the existing Vue components to React.

I think JSX is by far the best way of representing HTML in JS, there are no strange .vue files that are some odd mix of HTML/CSS/JS but proper JS via the help of a transformation.

[lafriks]

I will agree to disagree 😸 I'm on the other hand don't like react very much but everyone has their own favorites and I respect that 😉
I just don't like when JS code get mixed with html so much that it reminds me old PHP code 😅

[silverwind]

Well if you really want to keep it to Vue, we could use the Vue JSX factory function, e.g. https://github.com/vuejs/jsx-next#content. It looks exactly like a React functional component in the simplest variant and close to it in the other variants, they Vue has apparently been copying hard from React on that part.

I think using that JSX means current components need to migrate to Vue 3 because Vue 2 does not export the necessary factory functions. It'd be a mess which would probably have to load Vue twice.

I just don't like when JS code get mixed with html so much that it reminds me old PHP code 😅

I'd count that as a benefit of PHP. I enjoy being able to use JS functional methods like .map to compose HTML and this JSX transformer allows just that, nothing more. It should be easy to switch from this to either Vue or React JSX later.

[lafriks]

That's to be honest is exactly what I dislike about react most is mixing js with html 😕

[lunny]

The pure VUE is a framework like jquery, it's very small. I think the .vue file is better than js or JSX syntax because it's more clear to developers, it will not mix different type codes.

I agree we should switch to vue3 but it's for better performance and smaller size.
And also maybe vite which also based on esbuild and have the most fastest development speed.

[silverwind]

I still want to replace all the current places that construct HTML from strings with JSX, I don't really care whether it's Vue or something else that is processing the JSX as long as the output format of DOM nodes or string is possible. Vue 3 (finally) embraces JSX and I think it's the future, so I prefer if we start converting the existing SFCs to Vue 3 JSX.

[silverwind]

maybe vite

Not sure whether that supports all our current webpack use cases. Stuff like license file generation may not be possible. Webpack is certainly much more flexible in terms of extensibility.

[silverwind]

That's to be honest is exactly what I dislike about react most is mixing js with html 😕

Do you dislike React or dislike JSX? I think it's a weak argument. Composing HTML parts from JS just feels natural to me and it's already practiced in many places in the current code base because it is essentially the only possible way.

[silverwind]

The pure VUE is a framework like jquery, it's very small

The same is true for react-dom, it's size, while slightly bigger than Vue is not much of a concern:

https://bundlephobia.com/result?p=react@17.0.2
https://bundlephobia.com/result?p=react-dom@17.0.2
https://bundlephobia.com/result?p=vue@3.0.11

[lafriks]

That's to be honest is exactly what I dislike about react most is mixing js with html confused

Do you dislike React or dislike JSX? I think it's a weak argument. Composing HTML parts from JS just feels natural to me and it's already practiced in many places in the current code base because it is essentially the only possible way.

Is both an answer? :) But yeah I dislike JSX mostly because of mixed JS and HTML that makes it unbearably unreadable. And react for it's bulkiness and some of it's design decisions.

I like vue that's just like go is plain and simple, maybe I'm too old but I'm too tired of complex languages that makes it hard to maintain in the end, I have seen too many such systems in last 20 years 😆

[lafriks]

Only change here still needed is moving contrast color function to utils.js. @silverwind can you move it to other PR?

[silverwind]

Yes I can extract that later.

[wxiaoguang]

I vote for Vue3 (Vue is already used in this project) + JSX (nice to have)

[silverwind]

Closing as this won't happen.

[wxiaoguang]

I think it is good, if more people accept it, maybe we can welcome it back in future.

[silverwind]

Yeah, I'm still in favor of JSX for inline HTML snippets. We should at least have something that auto-escapes inserted values (but also provides a way to intentionally have unescaped content like SVGs).

GitHub apparently uses https://github.com/lit/lit/tree/main/packages/lit-html for this, but I'm not sure it's suitable because I see no way to introduce unescaped content. Also, it seems to bloated in case one only uses the template function, we effectively get the same by using htmlEscape as tagged template function.