Live data from Hacker News

Fusion.js: A Plugin-Based Universal Web Framework

eng.uber.com

11–20 of 79 posts

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

#12
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.

They aren’t the same though. Flow’s type system is nominal, typescript’s is structural, which is a huge language difference.

i thought nominal typing was only for the classes?

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

#13
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.

They aren’t the same though. Flow’s type system is nominal, typescript’s is structural, which is a huge language difference.

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...

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

#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 code, browser code, React provider boilerplate, HTML hydration code, etc).

This plugin architecture has already proved to be very valuable on more than a few occasions. One example is a service worker implementation we've been working on. It needs a middleware, browser-side registration code, etc, but all of this complexity is encapsulated in a plugin that can be added to any app with one line of code.

> Does it only support react?

Many plugins have a `-react` version that allow them to auto-integrate with React, but the core itself is view library agnostic.

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

#17
The Fusion plugin system is rather powerful and enables colocation of related/coupled code that would normally be spread across several places. For example, the Styletron plugin for Fusion (an integration for a CSS-in-JS implementation) will do several things:

* Wrap the application component tree in a React context provider component (which provides an instance that components will render styles into)

* On the server, extract rendered styles after SSR from provided instance and add necessary markup into the server-rendered page

* On the client, hydrate the provided instance from the server-rendered styles

* On the server and in development, set up a route handler that serves two assets, a web worker implementation and associated WebAssembly binary [1]

* On the client and in development, fetch and execute the web worker. Normally, this would be a somewhat difficult integration because of CSP-related issues with web workers, but because the plugin sets up its own route handlers, the requests will be same-origin, sidestepping most CSP issues that normally arise. Additionally, Fusion plugins can also modify response headers for requests, so if needed, CSP headers could also be set appropriately.

All the code to do this actually is related to a single concern, namely styling, but in a universal web app, such things typically requires the involvement of many different parts of the application lifecycle and both server and client code. Fusion plugins allow you to slice up the independent parts of your application logic in this fashion, somewhat analogous to how colocating HTML/CSS/JS for individual components in CSS-in-JSX is often much nicer than splitting apart component implementations across separate HTML/CSS/JS files.

[1]: This web worker generates debug CSS at runtime that maps rendered CSS to the source styled component definitions in JS using source maps, making it easier to reverse map the rendered CSS to the source CSS-in-JS when inspecting the DOM with the styles pane. https://github.com/rtsao/css-to-js-sourcemap

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

#18
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…

[deleted]
Post reply on HN