3 ms·

It's well intentioned, but this project is destined to go nowhere fast. Abstracting away web development and http has been tried again and again, and always en

It's well intentioned, but this project is destined to go nowhere fast. Abstracting away web development and http has been tried again and again, and always ends up being more hassle than plain ol' HTML+JS+HTTP. Then you've limited yourself to interop with the js libraries they've provided leaky wrappers over, or you can write your own leaky wrapper if you want to use coolnewthing.js you saw on github. And to cap it all, this framework requires commercial licensing for closed source projects!

zastrowm 12y ago
I don't really think requiring commercial licensing for closed source projects is really a con. Seems like a logical way to make money, yet still allow open source projects to benefit.
MichaelGG 12y ago
It's been around for a few years. I was able to use it to quickly whip up some sorta-complicated UIs for some internal tools. I despise JS, and have spent hours of time fixing simple casing errors or other things that static typing would fix. Plus F# the language is quite superior to JS, so I don't feel icky while working on it. The other benefit is that I can use all the same type definitions, so I don't need to write some generator or wrapper around my XHR functions - it just works. It's quite easy to just drop out into pure JS if you feel the need. And defining wrappers is actually very very simple. For example: [<Direct "foo($a, $b)">] let foo (a: string) (b: int) = () Doesn't Google use a Java-based system to do essentially the same thing (GWT)? But you're right that if you are already happy with JS then there's a lot less reason to pick it up.
- g8gggu89 12y ago
  GWT has long-ish compile times and it involves quite a house of cards, with getting the Eclipse plugin to talk to the browser plugin, for the 1? browser that actually has a plugin. Yeesh :(
  - RyanZAG 12y ago
    Fixed in GWT 2.7 builds (already available): https://www.youtube.com/watch?v=qpCSbj36O44&feature=youtu.be https://www.youtube.com/watch?v=qpCSbj36O44&feature=youtu.be
_random_ 12y ago
This is why the so called "open web" that locks you to a few legacy languages must be fought with. Transpilation is not an answer. Luckily mobile is thriving, no problems using F# with Xamarin as a first-class citizen
cordite 12y ago
Sounds exactly like Opa Lang. Though they've finally moved away from AGPL, but it is too late and their confusing incorrect marketing (it isn't a js framework.. It compiles to js..) is not saving them.
Vektorweg 12y ago
Its true that its difficult to build an working magical all-around wrapper, but the core parts can be replaced well. HTML+JS+HTTP is open to be LightwightMarkupLanguage + SupportedLanguage + NetworkWrapper, e.g. Markdown+Haskell+WAI .
cromwellian 12y ago
Interop with JS libraries can be solved without wrappers. GWT 3.0 introduces a new interop system that can take WebIDL, @JsDoc, or TypeScript annotations as descriptive of the interface of the underlying Javascript and synthesize Java interfaces that match the API. The compiler can generate code to call into Javascript with zero wrappers, maximizing performance and code size. It can even sub-class native Javascript objects (class Foo extends Bar.Prototype) using only standard Java syntax. For example, using similar techniques that html5index.org uses, all browser native APIs are automatically covered by fetching the latest WebIDL definitions from Chromium or Firefox's repository or via standards docs, and used to generate the interfaces. Or, using IDE FileWatchers, we use the Closure Compiler to read in Javascript libraries and/or externs, infer types, and write out interfaces. Likewise, we'll be able to read in typescript library interfaces and generate Java interfaces. Combining the new JsInterop system, Java8, and SuperDevMode's <1 second compiles, the new system eliminates wrappers, reduces Java boilerplate overhead (lambdas, method references), and provides fast refresh times.

zastrowm 12y ago

I don't really think requiring commercial licensing for closed source projects is really a con. Seems like a logical way to make money, yet still allow open source projects to benefit.

MichaelGG 12y ago

It's been around for a few years. I was able to use it to quickly whip up some sorta-complicated UIs for some internal tools. I despise JS, and have spent hours of time fixing simple casing errors or other things that static typing would fix. Plus F# the language is quite superior to JS, so I don't feel icky while working on it. The other benefit is that I can use all the same type definitions, so I don't need to write some generator or wrapper around my XHR functions - it just works. It's quite easy to just drop out into pure JS if you feel the need. And defining wrappers is actually very very simple. For example: [<Direct "foo($a, $b)">] let foo (a: string) (b: int) = () Doesn't Google use a Java-based system to do essentially the same thing (GWT)? But you're right that if you are already happy with JS then there's a lot less reason to pick it up.

g8gggu89 12y ago
GWT has long-ish compile times and it involves quite a house of cards, with getting the Eclipse plugin to talk to the browser plugin, for the 1? browser that actually has a plugin. Yeesh :(
- RyanZAG 12y ago
  Fixed in GWT 2.7 builds (already available): https://www.youtube.com/watch?v=qpCSbj36O44&feature=youtu.be https://www.youtube.com/watch?v=qpCSbj36O44&feature=youtu.be

_random_ 12y ago

This is why the so called "open web" that locks you to a few legacy languages must be fought with. Transpilation is not an answer. Luckily mobile is thriving, no problems using F# with Xamarin as a first-class citizen

cordite 12y ago

Sounds exactly like Opa Lang. Though they've finally moved away from AGPL, but it is too late and their confusing incorrect marketing (it isn't a js framework.. It compiles to js..) is not saving them.

Vektorweg 12y ago

Its true that its difficult to build an working magical all-around wrapper, but the core parts can be replaced well. HTML+JS+HTTP is open to be LightwightMarkupLanguage + SupportedLanguage + NetworkWrapper, e.g. Markdown+Haskell+WAI .

cromwellian 12y ago

Interop with JS libraries can be solved without wrappers. GWT 3.0 introduces a new interop system that can take WebIDL, @JsDoc, or TypeScript annotations as descriptive of the interface of the underlying Javascript and synthesize Java interfaces that match the API. The compiler can generate code to call into Javascript with zero wrappers, maximizing performance and code size. It can even sub-class native Javascript objects (class Foo extends Bar.Prototype) using only standard Java syntax. For example, using similar techniques that html5index.org uses, all browser native APIs are automatically covered by fetching the latest WebIDL definitions from Chromium or Firefox's repository or via standards docs, and used to generate the interfaces. Or, using IDE FileWatchers, we use the Closure Compiler to read in Javascript libraries and/or externs, infer types, and write out interfaces. Likewise, we'll be able to read in typescript library interfaces and generate Java interfaces. Combining the new JsInterop system, Java8, and SuperDevMode's <1 second compiles, the new system eliminates wrappers, reduces Java boilerplate overhead (lambdas, method references), and provides fast refresh times.