Live data from Hacker News

Fusion.js: A Plugin-Based Universal Web Framework

eng.uber.com

21–30 of 79 posts

Re: Fusion.js: A Plugin-Based Universal Web Framework

#21
post #14

Can someone write a sales pitch / direct comparison to next.js please? Does it only support react?

I wrote a small comparison here: https://fusionjs.com/docs/getting-started/framework-comparis... The main difference is Fusion.js has more support for backend things. For example, we provide a GraphQL plugin, and plugins such as I18N are bundle-splitting-aware out of the box. The plugin system is universal (meaning you can isolate concerns by what the library is responsible for, rather than whether the code is server…

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

Re: Fusion.js: A Plugin-Based Universal Web Framework

#23
post #3

Looks like a competitor to next.js, and from their docs built on koa. It’s nice to see more libs in this space, but it seems a little over complicated to me with the “plugin” style arch.

Correct about Fusion.js being based on koa. We find that this fits really nicely within the plugin system. The diagram is complex, but we inject the render phase into the middleware stack. Everything before `await next()` is pre-render, and everything after `await next()` is post-render. It makes it very easy to reason about the lifecycle of a plugin, as everything is in one place.

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

Re: Fusion.js: A Plugin-Based Universal Web Framework

#24

Looks like Angular 1

Can you explain what you mean?

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.

Re: Fusion.js: A Plugin-Based Universal Web Framework

#25
post #6

Seems to use Flow instead of Typescript. I wish MS and FB just merged their projects already. Really unnecessary friction when their syntax is 90% the same AFAICT.

Yes. I wonder what's the future of Flow (even if it's still used and maintained). As I posted in another topic about TS: > It's kind of crazy that Facebook has let TypeScript takes so much market share. I've been using Flow for so long now. The techno is good, the integration with the code editors is good too, but Flow has a lot of small-but-really-annoying bugs (2235 issues on GitHub right now), the type definitions…

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!

Re: Fusion.js: A Plugin-Based Universal Web Framework

#26
post #6

Seems to use Flow instead of Typescript. I wish MS and FB just merged their projects already. Really unnecessary friction when their syntax is 90% the same AFAICT.

Yes. I wonder what's the future of Flow (even if it's still used and maintained). As I posted in another topic about TS: > It's kind of crazy that Facebook has let TypeScript takes so much market share. I've been using Flow for so long now. The techno is good, the integration with the code editors is good too, but Flow has a lot of small-but-really-annoying bugs (2235 issues on GitHub right now), the type definitions…

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

Re: Fusion.js: A Plugin-Based Universal Web Framework

#27
post #14

Earlier quoted context omitted.

I wrote a small comparison here: https://fusionjs.com/docs/getting-started/framework-comparis... The main difference is Fusion.js has more support for backend things. For example, we provide a GraphQL plugin, and plugins such as I18N are bundle-splitting-aware out of the box. The plugin system is universal (meaning you can isolate concerns by what the library is responsible for, rather than whether the code is server…

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

Thanks! Pushing a fix

Re: Fusion.js: A Plugin-Based Universal Web Framework

#30
post #26

Earlier quoted context omitted.

Yes. I wonder what's the future of Flow (even if it's still used and maintained). As I posted in another topic about TS: > It's kind of crazy that Facebook has let TypeScript takes so much market share. I've been using Flow for so long now. The techno is good, the integration with the code editors is good too, but Flow has a lot of small-but-really-annoying bugs (2235 issues on GitHub right now), the type definitions…

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

Does this inference work across files?
Post reply on HN