Is this framework tightly bound to nodejs or can it be used with other backend stacks like asp.net core or spring?
Fusion.js: A Plugin-Based Universal Web Framework
31–40 of 79 posts
Re: Fusion.js: A Plugin-Based Universal Web Framework
#32Earlier quoted context omitted.
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 s…
Years ago, I played with the idea: https://github.com/danneu/klobb
I went on to implement it in Swift (https://github.com/danneu/hansel) and then seriously improved on it in Kotlin (https://github.com/danneu/kog).
It was fun but hard to really make a convincing upgrade to Koa once you consider the rest of the ecosystem. For example, since Koa exposes Node's req/res, then you can still use existing Node/Express middleware.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#33Can 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…
Will it be compatible with mithril? :)
Re: Fusion.js: A Plugin-Based Universal Web Framework
#34I'll use anything that the author of this article (Leo Horie) releases or is attached too. He is one of the greatest minds in JavaScript of this generation. After Angular, Vue and React I stumbled upon his framework Mithril.js and it was like I stumbled across the shroud of fucking turin, that framework is true poetry.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#35Re: Fusion.js: A Plugin-Based Universal Web Framework
#36Earlier quoted context omitted.
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?
That's true. Both Flow and TypeScript generally uses structural typing, but flow also has nominal typing for classes.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#37Earlier quoted context omitted.
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?
Yes, with some caveats. If you're `export`ing something as a package, you need to expose its types so that the consumer knows what its signature looks like. Once that is done, calling a function that was defined in another package will get type inference, as seen in the screenshot I posted.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#38Earlier quoted context omitted.
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…
TypeScript seems to do structural typing for classes too: https://www.typescriptlang.org/play/#src=class%20Foo%20%7B%0...
Re: Fusion.js: A Plugin-Based Universal Web Framework
#39Is this framework tightly bound to nodejs or can it be used with other backend stacks like asp.net core or spring?
Fusion.js is a javascript framework meant to be run on Node. There's nothing stopping you from calling out to other backends and asp.net if you stand up a Fusion.js frontend Node server.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#40Seems 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…
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.