Fusion.js: A Plugin-Based Universal Web Framework

i thought nominal typing was only for the classes?

Are they though? As a TypeScript user with very little Flow experience it seems like they are about the same:

https://flow.org/en/docs/lang/nominal-structural/

"For example, Flow uses structural typing for objects and functions, but nominal typing for classes." This statement also applies to TS.

Flow does have nominally typed Opaque Type Aliases[1], which are essentially newtypes from what I've gathered. However, you can build similar zero-cost newtypes in TypeScript using union types, casting and "unique symbol"[2].

[1] https://flow.org/en/docs/types/opaque-types/

[2] https://github.com/Microsoft/TypeScript/issues/4895#issuecom...

As I replied in that same thread:

> I tried Flow and TypeScript for the first time a few months ago. Flow is absolutely abandoned and dying. TypeScript is taking over where Flow left off, and is far ahead of the game by now. I use TypeScript with create-react-app in my client work and it is invaluable and a wonderful experience, with no downsides as far as I can see.

To add to that, the only reason I can see to use Flow in 2018 instead of TypeScript is if you already have a large project that uses Flow and migrating to TypeScript might take a few days. But even then it's probably worth making the switch. I have noticed a much smoother experience and much better integration with TypeScript than with Flow. And there are many type errors that Flow never caught no matter how much I tried to configure it right. Existing code bases may have these too. Even more reason to switch sooner than later!

We chose Flow for a number of reasons. One of the main ones is type inference. For example:

https://www.typescriptlang.org/play/#src=function%20a(x)%20%...

https://flow.org/try/#0GYVwdgxgLglg9mABAQwBQA8CUiDeAoRRAJwFM...

With Flow, we can surface type errors even in files that don't have any type information other than the @flow directive, e.g. http://eng.uber.com/wp-content/uploads/2018/07/image4.png

Yeh those small bugs are very frustrating. I wish it was written in Javascript too.

A big issue IMHO is Ocaml. FP heads usually hate JS, and they cannot dogfood Flow.

All the little issues feel like the devs don't use it enough to know the pain.

That's not true. TypeScript spec is just the latest JavaScript spec. Decorators are a JavaScript (TC39 stage 2) proposal, and TypeScript only uses them if you use --experimentalDecorators. And TypeScript uses the ECMAScript module system. Whatever other features you think TypeScript has that aren't "proper JS" probably are either already JS, or are late-stage TC39 proposals.

What definition of "superset" are you using?

I certainly don't speak for him, but I think it's a combination of things. First, Fusion is a group project and not his personal project. Second, React has a virtuous cycle where because there are so many jobs calling for React, more people learn it. People also seek out jobs that involve React because it will help their resumes. Demand keeps feeding supply and vice versa.

I joined Uber last year. They had already standardized on React long before that.

Koa is an improvement over Express, but I think it would neat if the JavaScript ecosystem adopted an even more functional middleware style, like Python's WSGI, Ruby's Rack, Clojure's Ring, etc.

Conceptually it's simple: middleware is a function that typically accepts a downstream "app", and returns a new "app" which accepts a "request" and returns a "response":

    const middleware = (app) =>
      async (request) => {
        // do stuff with request
        const response = await app(request);
        // do stuff with response
        return response;
      };

I worked on this idea way back in ~2009 (creatively called "JSGI" for the interface spec and "Jack" for an implementation) but promises weren't really a thing in JS, and async/await definitely wasn't a thing, so it was awkward.

More recently Michael Jackson had a project called Mach which was a similar idea, but it's no longer active either: https://github.com/mjackson/mach

As an aside, one of my favorite aspects of this style is having symmetric interfaces for HTTP servers and clients. You could do neat things like use a cache middleware for both a client and server, or write a simple HTTP proxy in a couple lines.

Anyway, with the addition of promises, async/await, and async iterators to JS I'm starting to dust off these old ideas. prototype here https://github.com/tlrobinson/twosixonesix

How many full-time employees working on the framework?

I thought your name sounded familiar! I played around with Mithril.js for a bit before settling on React.js and was really impressed with how you took the simplicity of JS and used it to your advantage with Mithril! Sad to say that I couldn't replicate that cleverness in my own code because I could not really wrap my head around the reasoning you used to come to code you did in your examples of using Mithril, but that's just more evidence that you're a smart guy, so thanks for making Mithril which helped widen my view of what could be done with JavaScript frameworks! Also is there any reason you chose Flow over TypeScript?

There's a typo in the beginning of the Next.js paragraph, developer -> developed.

Will it be compatible with mithril? :)

The dependency injection (DI) system is indeed inspired by Angular's. It has some major differences though:

- Fusion.js DI is token-based rather than string-based, so no naming collisions

- We support statically typing injectables (similar to Angular 2+)

- plugins are the only injectable entity type (whereas Angular is conceptually complex: e.g. modules, services, providers, factories, etc)

- plugins are isomorphic, whereas AngularJS injectables are not

I sorta already expected that people might get mixed feelings when seeing a DI system, but we spent a lot of time designing/tinkering with the plugin architecture to make it truly useful for managing complex library integrations and complex backends. I'd be happy to answer any questions about how we've been using it.

Thanks!

> lazy loading can happen in any component rather than only at "page" level

You can use dynamic imports anywhere in Next using `react-loadable`.

> more things are provided by the team via plugins

Next relies on its thorough `examples` dir for integrations. But it means a lot of manual coding.

I had a crack at a plugin system in the past (i.e plugins for adding features like apollo, redux, etc. AOT like stuff). I found that it obfuscated the code too much. Makes it hard to trace what is happening and make adjustments. The closer the code is to the "Getting Started" examples of Redux, I18n, Apollo, the easier it is to tweak and understand.

E.g. Sometimes it might be clearer to just wrap a Provider manually around the app root, than expose a plugin hook. Because you can see the React tree, whereas with plugins everything is dynamic so you must rely on logging.

I think devs are naturally drawn to DRYness and dividing code up by feature, which is what a plugin system offers, but there are big tradeoffs. I'm interested to dive into Fusion to learn more about their approach though.

> - better support for maintaining server-side complexity (e.g. by using Koa + DI system to make testing/mocking easier)

Great to see you adopting Koa! I use it myself, and feared that the community had stagnated, but now with Fusion, it may be reinvigorated.

> DI system to make testing/mocking easier

Very cautious of DI systems. Same reasons as plugin systems: its hard to see what is going on. And sometimes manually wiring up all the dependencies is actually not much code at all, and you can manage cyclic dependencies and ordering easier.

Keen to dive in deeper though.