Revamp project

[Coachonko]

Focus on most important and core packages only.

Drop:

• babel-plugin-inferno
• ts-plugin-inferno
• compat^*1
• create-class
• hyperscript
• mobx or redux, or both^*2

*1: React has moved very distant. The effort to support React compatibility is futile at this point, embrace differences.

*2: Like many other libraries available today, Inferno could become more opinionated and provide its own state management solution.

Use bun as platform. The advantages are very many.

• write jsx transformer (Bun's transpiler API is similar to esbuild, this is mostly a matter of refactoring babel-plugin-inferno code).
• support a single starter for SSR applications: the industry is leaving SPAs behind.
• archive unmaintained and dropped packages (including create-inferno-app, brunch...): prevent confusion for new adopters.
• remove outdated information from website.
• Internally: all tests can be run with bun test instead of jasmine.

[Havunen]

Having a compiler for Bun sounds like a good idea, but I don't think we should drop babel-plugin-inferno it is very widely used still. There is also plugin for typescript compiler called ts-plugin-inferno

[Coachonko]

I don't think it makes sense to support this many transformers.
I think the correct way to move forward is to only support and recommend one toolchain, and bun seems the most convenient to lean in. It will definitely offer better developer experience and user experience.
The major players (next, remix, nuxt, solidstart, sveltekit) already have abandoned babel in favor of esbuild or swc.

[Havunen]

There is now initial version of inferno SWC plugin available, go try it out! :)

https://github.com/infernojs/swc-plugin-inferno
https://www.npmjs.com/package/swc-plugin-inferno
https://github.com/infernojs/inferno-swc-example

[farooqkz]

I agree with forgetting React compatibility. However, the babel and typescript plugins should not get dropped. Unless you want to replace babel with swc. I also disagree integrating a state management system with Inferno. IMO, both mobx and redux are big for some specific applications.

I also disagree stop supporting SPAs.

[farooqkz]

Integrating a builtin state management for Inferno such as mobx or redux will surely affect KaiOS apps. Or perhaps I got you wrong? It won't be builtin and just official?

[Coachonko]

Integrating a builtin state management for Inferno such as mobx or redux will surely affect KaiOS apps.

Why would this affect KaiOS apps? Applications are self-contained, they don't share internal state with outside systems.

Or perhaps I got you wrong? It won't be builtin and just official?

One option I proposed is to only support either one, not both.

The reason for this is simple: suppose I only use mobx but a new user asks for help with redux. I don't know how redux works, so I can't help the new user. Suppose now that everybody is recommended to use redux with the official redux package: more people will use redux and people who use mobx will likely migrate to redux because it will be officially supported. Users can more likely help each other under these circumstances.

[farooqkz]

The problem of integrating mobx or redux is code size.

[Coachonko]

The problem of integrating mobx or redux is code size.

Nobody suggested to integrate mobx or redux. Only officially support either one instead of both.

[farooqkz]

My bad. I thought you meant integrating one of them and thus being mandatory for every Inferno application. As a note to self, either don't enter discussion or if you do, read with your mind on...