Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fusion.js: A Plugin-Based Universal Web Framework

eng.uber.com

Post reply on HN
Print view View original

61–70 of 79 posts

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

#61

Post by sbjs »

mediumdeviation wrote: post #59
sbjs wrote: post #49

Earlier quoted context omitted.

That's not true. TypeScript spec is just the latest JavaScript spec. Decorators are a JavaScript (TC39 stage 2) proposal, and TypeScript only uses them if you use --experimentalDecorators. And TypeScript uses the ECMAScript module system. Whatever other features you think TypeScript has that aren't "proper JS" probably are either already JS, or are late-stage TC39 proposals.

Enums are not JavaScript, and I've never heard of an Enum stage X proposal.

Oh, you're right!

http://www.typescriptlang.org/play/#src=enum%20Direction%20%...

And yeah this could be valid JavaScript too, having nothing to do with types, but it's not in JS, only TS.

That said, it is a very cool and clever way to set k=v and v=k in an object at the same time!

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

#62

Post by grrowl »

sbjs wrote: post #25
ggregoire wrote: post #8

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…

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 F…

We are in the process of doing this on a moderately large product. We've found TypeScript itself has much less friction to write (quicker development), and has a lot less gotchas (probably because it restricts the language itself, unlike Flow), so porting the code has been a big task but a very positive one. We went with Flow originally because it would work with our untyped JS better, but in hindsight we should have bitten the bullet earlier and gone straight to TS.

We're still exporting Flow types generated from TS modules to be imported by older projects (which is... _okay_). I would recommend just choosing the better option from the outset. You'll save hours researching why Flow has a problem (and eventually just writing `// $FlowFixMe https://github.com/some-flow-issue/666` and moving on). I don't see any compelling reason to start a Flow project these days.

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

#63

Post by sbjs »

xanderjanz wrote: post #60
sbjs wrote: post #53

Earlier quoted context omitted.

Ah right, the `import * as` problem. That was fixed with --allowSyntheticDefaultImports. According to the docs: > Allow default imports from modules with no default export. This does not affect code emit, just typechecking. https://www.typescriptlang.org/docs/handbook/compiler-option... And I think you're right about decorators. They are an iffy concept in the context of JS semantics, and I personally avoid using the…

We have high order functions in JS. Which are similar to decorators.

Similar, but harder to use safely and correctly in class methods using the new class syntax. There's more surface area for typos and other mismatch errors since you have to type the method names twice. See: https://mobx.js.org/best/decorators.html

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

#64

Post by RyanCavanaugh »

azangru wrote: post #47
egeozcan wrote: 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.

But Typescript is a language on its own. It claims to be a superset of JavaScript, but includes JS features that aren’t even certain to end up in JS (decorators). And their import system... Whereas Flow is proper JS. It’s just so... nice!

What definition of "superset" are you using?

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

#66

Post by t1amat »

watty wrote: post #45

Looks awesome and love the focus on plugins. I also like some of the choices made, Redux, React Router, Security, etc. but going with Flow?? Our company has standardized on Typescript, it has practically "won". Unfortunately for me, introducing Flow would get shot down.

It’s a library so either they need to be convinced to provide definitions or the community needs to be convinced to build them. But at the point that they are built it’s no different than anything else in your stack.

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

#67

Post by swyx »

panoply wrote: post #34

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

hmm. so he made Mithril but he's using React here? any insight on why that decision?

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

#68

Post by brlewis »

swyx wrote: post #67
panoply wrote: post #34

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

hmm. so he made Mithril but he's using React here? any insight on why that decision?

I certainly don't speak for him, but I think it's a combination of things. First, Fusion is a group project and not his personal project. Second, React has a virtuous cycle where because there are so many jobs calling for React, more people learn it. People also seek out jobs that involve React because it will help their resumes. Demand keeps feeding supply and vice versa.

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

#69

Post by lhorie »

swyx wrote: post #67
panoply wrote: post #34

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

hmm. so he made Mithril but he's using React here? any insight on why that decision?

I joined Uber last year. They had already standardized on React long before that.

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

#70

Post by erlich »

lhorie wrote: post #48
erlich wrote: post #46

Have any of the maintainers used Next.js? What was your opinion? What does Fusion.js do differently/better?

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). I found that it obfuscated the code too much. Makes it hard to trace what is happening and make adjustments. The closer the code is to the "Getting Started" examples of Redux, I18n, Apollo, the easier it is to tweak and understand.

E.g. Sometimes it might be clearer to just wrap a Provider manually around the app root, than expose a plugin hook. Because you can see the React tree, whereas with plugins everything is dynamic so you must rely on logging.

I think devs are naturally drawn to DRYness and dividing code up by feature, which is what a plugin system offers, but there are big tradeoffs. I'm interested to dive into Fusion to learn more about their approach though.

> - better support for maintaining server-side complexity (e.g. by using Koa + DI system to make testing/mocking easier)

Great to see you adopting Koa! I use it myself, and feared that the community had stagnated, but now with Fusion, it may be reinvigorated.

> DI system to make testing/mocking easier

Very cautious of DI systems. Same reasons as plugin systems: its hard to see what is going on. And sometimes manually wiring up all the dependencies is actually not much code at all, and you can manage cyclic dependencies and ordering easier.

Keen to dive in deeper though.

Post reply on HN