Dependency injection scares me as it feels like a move towards the JavaEE/Spring world.
Me too.
The increase in complexity and lack of visibility from a DI system, vs what the manual wiring code would look like, can be immense.
Fusion.js: A Plugin-Based Universal Web Framework
71–79 of 79 posts
Re: Fusion.js: A Plugin-Based Universal Web Framework
#72Reframe (https://github.com/reframejs/reframe) is an alternative that focuses on flexibility.
Fusion.js locks you in, Reframe doesn't.
(I'm Reframe's main author.)
Re: Fusion.js: A Plugin-Based Universal Web Framework
#73Reframe ( https://github.com/reframejs/reframe ) is an alternative that focuses on flexibility. Fusion.js locks you in, Reframe doesn't. (I'm Reframe's main author.)
Can you expand on why you think Fusion locks you in?
Without a more detailed argument this sounds like you're just plugging your product.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#74Earlier quoted context omitted.
We did evaluate it. Some of the things off the top of my head that I think Fusion.js does better: - isomorphic treeshaking - more powerful bundle splitting (i.e. lazy loading can happen in any component rather than only at "page" level) - async server-side rendering is composable via HOCs rather than only at top-level getInitialProps - more things are provided by the team via plugins (e.g. I18N, CSRF protection, atom…
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)…
Having used Fusion a bit now (I'm an engineer at Uber, but not on the Web Platform team that produced Fusion), I'm really enjoying the DI system. Agreed other DI mechanisms (e.g.: Angular) are too magical; Fusion uses a token system which is very easy to reason about.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#75Earlier quoted context omitted.
We did evaluate it. Some of the things off the top of my head that I think Fusion.js does better: - isomorphic treeshaking - more powerful bundle splitting (i.e. lazy loading can happen in any component rather than only at "page" level) - async server-side rendering is composable via HOCs rather than only at top-level getInitialProps - more things are provided by the team via plugins (e.g. I18N, CSRF protection, atom…
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)…
> You can use dynamic imports anywhere in Next using `react-loadable`
I joined the team after the code splitting part was done, so I don't know off the top of my head whether this library was considered, but it does look interesting. From a glance, it seems to suffer from the issue of sprinkled configuration, but it might be something that we could potentially use to replace our current implementation. Does it support HOC-level async data fetching?
> Very cautious of DI systems. Same reasons as plugin systems: its hard to see what is going on
Interestingly we had a completely opposite experience maintaining our old closed-source framework. Everything was built on top of express and it was really hard to reason about where code for any given thing was. For example, trying to debug some I18N thing meant digging through at least 3 files filled with unrelated concerns in completely unrelated packages.
FWIW, we spent a lot of time designing and redesigning the plugin system (like months). What is there today looks nothing like our first approach. I think we arrived at a pretty good solution, which is centered around colocating related concerns into one place.
> sometimes manually wiring up all the dependencies is actually not much code at all
Yes, wiring things up manually is relatively easy. The challenge we kept running into was taking things out (e.g. no-op-ing production-hitting tracing/metrics code in tests)
Re: Fusion.js: A Plugin-Based Universal Web Framework
#76Dependency injection scares me as it feels like a move towards the JavaEE/Spring world.
Having used other DI systems, I think the parts that most confused me were that the injector would usually be hidden away (meaning you couldn't see _what_ was being injected), and also the conflation with various initialization patterns (factories, providers, singletons).
In Fusion.js, the injectable registration is done in the entry file, and initialization patterns are the concern of the service API. I think these design choices simplify things a lot.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#77Earlier 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
To me that's a feature and not a bug. A good codebase would have --noImplicitAny enabled, which would catch this. Relying on usage of a function to know its types is fragile, the function should be the one declaring the types it uses so that callers can adapt to changes, not the other way around.
--noImplicitAny isn't quite equivalent though. What type inference provides is the ability to define the type of something somewhere and propagate that contract throughout a complex system such as a DI container.
The playground examples are just an oversimplication to illustrate the core difference between TS and Flow, but the screenshot gives a better idea of how it actually plays out in practice. In our case, we tie the type to the DI token and a plugin receives something that is guaranteed to be of that type.
This means someone migrating doesn't need to explicitly add types to their code, but can still get better gradual type coverage than `any` or the break-the-world `--noImplicitAny` flag.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#78Earlier quoted context omitted.
To me that's a feature and not a bug. A good codebase would have --noImplicitAny enabled, which would catch this. Relying on usage of a function to know its types is fragile, the function should be the one declaring the types it uses so that callers can adapt to changes, not the other way around.
--noImplicitAny isn't quite equivalent though. What type inference provides is the ability to define the type of something somewhere and propagate that contract throughout a complex system such as a DI container. The playground examples are just an oversimplication to illustrate the core difference between TS and Flow, but the screenshot gives a better idea of how it actually plays out in practice. In our case, we ti…
I can totally see an argument for that if you need gradual type coverage, which I guess is needed on large code bases. I have only worked on smallish ones of a few thousand lines of code, and it took maybe an hour to type everything, although most of it was really fun and exciting :) but in cases where that's not realistic, I could see using Flow to help transition.
Re: Fusion.js: A Plugin-Based Universal Web Framework
#79Earlier quoted context omitted.
Hi, that's me :) Fusion.js is a team effort though: https://fusionjs.com/team
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 tha…
Funny you say that, as for me it was the exact opposite. I had tried multiple frameworks before discovering Mithril, and it was the first that clicked with me. I think what appealed to me the most was the lack of magic, its minimalism, and flexibility. Whereas with other frameworks, I felt I was always encouraged to `npm install `, Mithril made me dig deeper and understand the nuances of JavaScript.