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…
Fusion.js: A Plugin-Based Universal Web Framework
21–30 of 79 posts
Re: Fusion.js: A Plugin-Based Universal Web Framework
#22Dependency injection scares me as it feels like a move towards the JavaEE/Spring world.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#23Looks 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.
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
#24Looks like Angular 1
Can you explain what you mean?
- 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
#25Seems 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…
> 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
#26Seems 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…
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
#27Earlier 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.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#28Re: Fusion.js: A Plugin-Based Universal Web Framework
#29The author seems to be the same person behind http://mithril.js.org
Fusion.js is a team effort though: https://fusionjs.com/team
Re: Fusion.js: A Plugin-Based Universal Web Framework
#30Earlier 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