Please don't name it Fuse. Yes, it's a good name, but there is already a rather well known project with that name, plus it's a common household item. You make it unnecessary hard to be found and not con-fuse-d (hah!) by users.
I speak from experience: I often have to look up errors/bugs related to root. Root as in "CERN analysis software", not the user. One of the most annoying names ever. (In that sense it's rather fitting)
Exactly. While reading the title, I thought... what a good idea.
But what I had in mind, was to use FUSE (Filesystem in USEr space) to locally mount a webservice/API and then use C# native GUIs to do the presentation :)
That's interesting, but I'm not sure what FUSE gets you, except maybe not having to fiddle around with streaming the bytecode yourself? I do like the idea of having a compiled bytecode hosted on a server, streaming that to a local C# VM (.NET?) then having the native GUIs do the presentation. :)
It's interesting that FUSE (the file system library) has a FAQ entry about why they chose the name when there was already a ZX Spectrum emulator named Fuse. Apparently it's name collisions all the way down.
* Will you have a freemium model? (Free for opensource apps.)
Yes, there will always be a free way of using Fuse and Uno.
* Will you change the name like others have suggested?
No :)
* Will you consider a no-JS model to develop?
Yup. We have that already. You can use Fuse with just Uno if you like, JS is an optional component. However, our main focus is on creating a very rapid and streamlined development workflow with UX+JS.
>Very likely - but details/license TBA.
>Yes, there will always be a free way of using Fuse and Uno.
If I had to choose, I would release the whole platform (not only Uno and your libraries, but your whole toolkit/IDE) under dual license: RPL and proprietary. This way, if people choose the RPL way, they're forced to publish the sources (even if they distribute the app internally), unless they buy you a license. And this way you allow contributions from outside too.
> Oh really, you're not going to change the name because 3 people on HN suggested it?
I'm sure the people behind FUSE file system library might have some comments to add. I would never name my product after a major open source project. Like as if I created something and called it Blender or Pencil.
I doubt they have the money to do anything about it. Furthermore, I doubt they have a trademark on the name because it costs $10k to get one.
The worst they could do is to blog about it and if they're lucky and get coverage with their article, it could be settled in the court of public opinion.
Trademarks are free, you just start putting ™ after it and using it like a trademark. Registered trademarks ® cost money, but even then it's only a few hundred depending on which filing option you choose. Just the same, the file system guys don't seem to treat it as a trademark, so it's not an issue here.
Javascript, javascript, javascript... So, where's the C#?
> Uno, a light-weight, high speed dialect of C#.
Ah! Here it is. A light-weight dialect, you say. Similar to Unity3d's old Mono fork that hasn't been updated since .Net 2.5, and still crashes when you attempt to use some of language features (like named parameters)?
Yes, at least he could reverse the order of words in the subj. The link on the website leads to the API docs - there is no language description. I bet "high-speed" actually means "we removed things we think you don't need". Feels like a Unity3d-inspired afterthought.
It does not matter though, the world is moving away from JS. Better support the full C#.
The world where the browser is yet another virtual machine using a bytecode format called WebAssembly, with developers having found memories (or not) from the days when JavaScript was the only option.
Before they where called outracks.com and were making some kind of 3D studio. But apparently they have switched over to working full time on Fuse instead, which is kinda sad as Uno is pretty awesome. I'm guessing documentation is going to come up on their new webpage eventually, I remember them doing a private beta of Uno and the 3d studio thing. I'm wondering if they have given up on the 3d studio thing, or if they are just planning on rebranding it, since it seems they have given up the name outracks.
Not sure if it will go that fast , but i'm using any language that compiles to JS instead of using JS. That includes C#, but rather ClojureScript, PureScript & Shen. It is definitely already possible to never touch JS, however the debugging side of things is not very nice mostly... You have to dive into the generated JS and then have to think how it translates to your code... With webassembly that should be a lot better.
What's the relationship between your UX markup language and XAML? Superficially they look similar - DockPanel/ScrollViewer etc (or are these more standardised elsewhere?) - with bindings/triggers being very different, Each being very different.
Is yours a superset? Does it implement full xaml layouts? Do you support xaml grids? Do you have an equivalent to xaml namespacing? Is yours actually xml in the xhtml sense or is it looser?
Is building a Fuse app anything like building an MVVM WPF app? Are you creating .net objects at any point? Is your c# thing (uno) .net?
UX markup is not directly related to XAML, allthough it is based on much of the same principles. UX markup is designed to be much less verbose and more compact. It is not very strict Xml, it prefers expressiveness over Xml conformance. Xml namespacing is supported though :)
UX with the Fuse libraries offer pretty much the same layouts as xaml, including Grid.
Uno is not .NET based at runtime. Uno is translated to C++ and runs as native code with no VM.
Because html+css was designed for viewing static documents, not unlike Word or PDF. Most of the efficiency problems of the web stem from that fact. The rest stem from the bloat that's required to support every browser in existence from the past 5 years. I still shudder every time I hear the words "this works in ie8, right?" It's like having 5 different Java VMs, each supporting a slightly different undocumented version of the java bytecode spec and then requiring everybody to support all 5 VMs, their quirks and make it all backwards compatible.
Not really. A lot of the efforts of Fuse seem to go into making it easy to build smooth animation and stunning graphics using high level primitives instead of programming GPU directly
Yeah, that's pretty accurate, there's plenty difference between Fuse and hybrid app solutions / traditional cross-compilation stuff. The people behind Fuse come from GPU design and demoscene backgrounds too, which I would say is a good sign :)
I speak from experience: I often have to look up errors/bugs related to root. Root as in "CERN analysis software", not the user. One of the most annoying names ever. (In that sense it's rather fitting)