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

51–60 of 79 posts

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

#51

Post by azangru »

sbjs wrote: post #49
azangru wrote: post #47

Earlier quoted context omitted.

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!

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.

> And TypeScript uses the ECMAScript module system.

Erm, I was thinking of a discussion like the one over here:

https://github.com/Microsoft/TypeScript-React-Starter/issues...

Q: `import React from "react";` breaks in Typescript

A: have you tried `import * as React from 'react';`

Me: Golly!

> Decorators are a JavaScript (TC39 stage 2) proposal, and TypeScript only uses them if you use --experimentalDecorators.

Oh, didn’t know about the flag; I thought it's already a standard language feature now, what with all the Angular apps relying on it. As for decorators being a TC39 proposal, I am aware of that, but they have remained a proposal for quite a long time now, haven’t they (about 4 years now?), and I remember babel renaming the transformer for decorators to legacy-decorators-something, saying that the very semantics of decorators in JS is still debatable (some thought of them simply in terms of functions accepting a function and returning another function; some in more angular sense of injecting some properties into methods). I hope I am not completely misrepresenting the rationale here.

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

#52

Post by swsieber »

sbjs wrote: post #50
lhorie wrote: post #26

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

To build upon your comment, I really like the way Rust does things (they do it for coherence and major-minor versioning changes not breaking inference) - you declare types in functions (you have to) & structs, and everywhere else is optional (unless the type checker can't infer the type).

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

#53

Post by sbjs »

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

> And TypeScript uses the ECMAScript module system. Erm, I was thinking of a discussion like the one over here: https://github.com/Microsoft/TypeScript-React-Starter/issues... Q: `import React from "react";` breaks in Typescript A: have you tried `import * as React from 'react';` Me: Golly! > Decorators are a JavaScript (TC39 stage 2) proposal, and TypeScript only uses them if you use --experimentalDecorators. Oh, di…

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 them and try to avoid libraries that use them. That's probably why TS has them disabled by default and calls them "experimental". I like the concept of decorators in and of themselves, but they don't fit cleanly into the JS world, and I am looking forward to seeing how the JS/TS world innovates alternative "cleaner" solutions that fit better into the existing model!

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

#54

Post by jacobr »

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

> And TypeScript uses the ECMAScript module system. Erm, I was thinking of a discussion like the one over here: https://github.com/Microsoft/TypeScript-React-Starter/issues... Q: `import React from "react";` breaks in Typescript A: have you tried `import * as React from 'react';` Me: Golly! > Decorators are a JavaScript (TC39 stage 2) proposal, and TypeScript only uses them if you use --experimentalDecorators. Oh, di…

Pretty sure `import * as React from 'react';` is the correct EcmaScript syntax because React does not expose an ES module compatible `default` export. You're just used to it working anyway thanks to babel accepting CommonJS modules, but TypeScript is the one that actually follows the standard here.

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

#55

Post by sbjs »

lhorie wrote: post #29
swah wrote: post #28

The author seems to be the same person behind http://mithril.js.org

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 that's just more evidence that you're a smart guy, so thanks for making Mithril which helped widen my view of what could be done with JavaScript frameworks! Also is there any reason you chose Flow over TypeScript?

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

#56

Post by orf »

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

> And TypeScript uses the ECMAScript module system. Erm, I was thinking of a discussion like the one over here: https://github.com/Microsoft/TypeScript-React-Starter/issues... Q: `import React from "react";` breaks in Typescript A: have you tried `import * as React from 'react';` Me: Golly! > Decorators are a JavaScript (TC39 stage 2) proposal, and TypeScript only uses them if you use --experimentalDecorators. Oh, di…

> A: have you tried `import * as React from 'react';`

> Me: Golly!

You're fundamentally misrepresenting that whole issue, and if you'd read just two or three comments down you'd see that there is a better fix, and part of the problem is a behaviour that's not even related to the ECMAScript standard.

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

#57

Post by azangru »

orf wrote: post #56
azangru wrote: post #51

Earlier quoted context omitted.

> And TypeScript uses the ECMAScript module system. Erm, I was thinking of a discussion like the one over here: https://github.com/Microsoft/TypeScript-React-Starter/issues... Q: `import React from "react";` breaks in Typescript A: have you tried `import * as React from 'react';` Me: Golly! > Decorators are a JavaScript (TC39 stage 2) proposal, and TypeScript only uses them if you use --experimentalDecorators. Oh, di…

> A: have you tried `import * as React from 'react';` > Me: Golly! You're fundamentally misrepresenting that whole issue, and if you'd read just two or three comments down you'd see that there is a better fix, and part of the problem is a behaviour that's not even related to the ECMAScript standard.

Yes, I missed that, thank you for the rebuke.

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

#58

Post by Bahamut »

The idea behind this looks awesome - if I understand correctly, this is to encourage people to program more to interfaces provided by plugins so that implementations can be swapped more easily. This does not require a type system either to use, which lowers the barrier.

The one thing I think should change though is decoupling from requiring Node from the runtime. I think the broader JS ecosystem could benefit from some of the ideas this library seems to promote.

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

#59

Post by mediumdeviation »

sbjs wrote: post #49
azangru wrote: post #47

Earlier quoted context omitted.

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!

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.

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

#60

Post by xanderjanz »

sbjs wrote: post #53
azangru wrote: post #51

Earlier quoted context omitted.

> And TypeScript uses the ECMAScript module system. Erm, I was thinking of a discussion like the one over here: https://github.com/Microsoft/TypeScript-React-Starter/issues... Q: `import React from "react";` breaks in Typescript A: have you tried `import * as React from 'react';` Me: Golly! > Decorators are a JavaScript (TC39 stage 2) proposal, and TypeScript only uses them if you use --experimentalDecorators. Oh, di…

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.
Post reply on HN