Fuse
fusetools.com
fusetools.com
If you don't need cross platform the best choice is native so you can leverage all the platform goodies.
If you do need cross platform and have the budget you will go with 2 native projects.
If you don't have enough budget for 2 native apps you have a few options.
Cordova is good enough for a lot of apps. Even Apple uses Webviews in its own apps. Also check the Missive mail client all built with web technologies:
https://medium.com/missive-app/our-dirty-little-secret-cross...
We are building a universal app that will work on iOS, Android, Mac, Windows, and Chrome OS with a single code base.
If you need better performance you can always use React Native, NativeScript, or Xamarin.
Why go with this Fuse thing?
Additionally Fuse has pretty amazing devtools for something not as hyped as, say, React Native.
TL;DR We're primarily about being able to create cool stuff in less time (cross-platform is just a side-effect of that). A lot of what we build comes down to creating good workflows for going from idea to the final product, and to find the right level of abstraction so that you can work very quickly (staying focused on the real job rather than boilerplate and glue code) without giving up control and being sandboxed.
Is it really crossplatform when according to your website it only supports the two majors compuphones makers ? Seems to me it's more marketing than anything else.
So much hate in your comment. Why are you so quick to be dismissive and rude?
I for one think it's fair to claim they are cross platform if they work with 97.12% of the mobile market share [1].
1. https://www.netmarketshare.com/operating-system-market-share...
> So much hate in your comment. Why are you so quick to be dismissive and rude?
GP raised multiple apparently valid objections. This is neither hateful nor rude, and your efforts would be better spent on answering issues than name-calling.
That said, all cross-platform solutions at the moment currently suck, except maybe Flutter, but that is still very alpha.
Maybe. My point is not about how you manage your budget, but how you make an app with the available budget for the app.
> or you would rather have one app with twice the features of two native apps
If you need those features then you can't really afford 2 native apps either.
Does no one understand what native means anymore? UI wise, native means using the platforms widget toolkit which this does not seem to do. I'm not sure if it's even possible on android unless they are calling into the java stack for rendering the UI. Notice how in the MacOS screenshots they give a giant middle finger to the current OS theme? Doesn't look like it's using cocoa/carbon (whatever the current mac toolkit is) underneath.
I'm not sure if I'd even consider it native code on android, which would be ART/Dalvik byte code, for better or worse. I also think transpiling from c#/javascript to to c++ would rule it out as being considered native, but that's debatable.
Never trust a project that will lie to you in the elevator pitch.
Lot of examples that look very promising really help to get into the main stuff quickly.
Tough, after learning React (preact actually) ; I'm wondering what it could help achieve more than going trough Native React. The last one is already well implemented and is "structured" like react, merging up some learning curve.
as Pier25 said earlier tough, trouble is when you need to implement "fancier" things. At which point you could have gotten into real native anyway.
It saves some time, but the pricing plans are ridiculous.
If you want to build a tool people want to use you need to build up something they'll like first.
I doubt anyone could be using it since more established tools are already been accepted by the community.
I will never pay you for a Visual Studio. I like coding with VIM or Subl, and I look after tools that I can use with a idiot text editor.
Hope you grow up from this :)
Cheers
edit: misread plans
Your feedback around pricing is also duly noted.
Even if you are making mobile apps all year round, what if tomorrow you don't want to use Fuse anymore? You'd need to keep on paying the subscription to fix bugs.
What if you are a freelancer who only makes mobile apps from time to time? Again you need to pay the whole enchilada to be able to fix little bugs from time to time.
A price per published app would make more sense IMO. Allow devs to use the complete experience for developing, make them pay when they need to compile and publish the app. If you are confident that your users will love your dev experience (which seems your stronger selling point) this would not feel like a trap.
Also, I never understood why people hate native languages so much - why do you want to replace everything with Javascript? It's shit - it's a necessary evil in the browser but when the environment gives you something better (Swift, Java, etc) why not enjoy it?
Plus weird build tools and binaries in source control
1: https://github.com/fusetools/fuselibs-public/blob/master/.tr...
2: https://github.com/fusetools/fuselibs-public/tree/master/Stu...
I guess their actual compiler for "UX Markup" could be written in .NET but Javascript is definitely and unfortunately invited.
That said, my company tried Fuse out around a year ago and went with Ionic instead. Partially because adapting Angular to Fuse was a lot of effort, and partially because at that time Fuse was not nearly release-ready.
Because people don't have the time, money or expertise to write multiple completely separate code bases for cross platform apps and having to keep these code bases in sync will dramatically slow down your ability to extend and adapt your product...?
Convince us one of those tools is any good, because it doesn't seem like it, from the traction they've had so far.
When did we decide that developer time was more precious than user experience anyway? Every time I see an electron app now I just assume that the devs don't care about their users, just how much easier it is for them to push bloated crap out the door.
I think people really over exaggerate native UI experiences... maybe a native experience is 10 out of 10 good and a non-native experience is something like 7 out of 10 good but it's not as bad as 1 out of 10 good. I'm sure there's lots of occasions where users will be happy with a non-native app rather than not having one at all because the developer didn't have enough resources for multiple native apps.
Don't we promote MVPs around here as well?
I use the Spotify, Whatsapp and Slack apps frequently for example and don't think they'd be vastly improved going native.
I'd agree. Maybe even as high as 9 out of 10, depending on the framework used and the adherence to platform norms. User experience is not just the UI though, using a GB of RAM when you could be using 10MB is also a poor user experience, particularly when you run out of memory. Most people won't be knowledgeable to blame the app for this poor experience though, they'll blame MS or think there's something wrong with their computer.
> Don't we promote MVPs around here as well?
An MVP can be single platform, multi platform is clearly not the minimum.
>I use the Spotify, Whatsapp and Slack apps frequently for example and don't think they'd be vastly improved going native.
On what hardware? A good chunck of users are on less than 4GB of RAM still (http://store.steampowered.com/hwsurvey). Even if you've got 16GB, what happens when everything in the computer starts to be a resource hungry as electron apps? These are companies with a tonne of money to spend, there is no reason they can't stop being so wasteful with their users resources.
And that's on desktop. Go get a low end android phone and see how many apps you can even install. Very quickly you have to start making decisions like "should I uninstall facebook or audible".
The problem is that when a native app falls short, it stays with the conventions of the platform. When a non-native app falls short, it'll stay with the convention of the framework and likely be confusing or broke for the user.
As an example Adobe Flash was really popular for 10+ years. On all platforms it broke copy/paste, swallowed keystrokes, and ate battery, cpu, and memory. Those things could technically be addressed, but rarely were. Most of the time the website was for a restaurant where I was only interested in the menu, location, or hours.
I don't use any of the apps you cited regularly, but I do often hear complaints about them using excessive battery and memory usage for apps that just do chat and music playback.
I also don't see why it matters if your MVP is built on a cross-platform abstraction? In my experience, I often find details where I have to fight the abstraction to access something exposed in the native API.
To reach a larger audience with less dev time/fewer devs?
Sure, use a library if it papers over deficiencies or adds features your app needs to be viable. That's always a technical debt : developer time call. But, especially with the amount of iteration on the native mobile platforms, I haven't heard of that very often.
It's not just my ancient iPhone though - the Mac Spotify client regularly sticks for at least 30 seconds on the Browse screen, or if I try to search for an item. I could literally type my search, go make a coffee, and by the time I return it will almost be ready to display the result.
As for Slack, I deleted it because it was so slow and a resource hog. Pushover is faster and less resource intensive for my purposes.
>Don't we promote MVPs around here as well?
That's to get it out the door and evaluate whether it has business potential. That's not meant to be your final product. If your product is just an MVP you don't have much of a competitive moat - you also want it to be difficult for competitors to match what you have.
Works great for me. I could understand not liking it if it did that on my machine though.
Helpful to know I might be an isolated case, though.
Guess I'm just unlucky on this one. Thanks for the additional info though.
That Spotify, Whatsapp and Slack don't have native apps is a disgrace beyond comprehension. Those are probably the easiest type of apps anyone can come up with.
Pretty easy to comprehend why you wouldn't burn more developer resources than necessary actually.
Try to set aside your own dev bias towards 'non-native' and consider what the average users of those apps think. They don't care the apps are non-native, they don't even know what that means.
No, it is incredibly short sighted and in the long run Spotify in particular must have spent a ridiculous amount of effort ironing out bugs and issues (this often takes many many months) that are a consequence of unnecessary cross-platform efforts.
The average user don't care about native and non-native. But they do absolutely care about performance, look and feel.
It's easier to transition from the (presumably) single code-base they have now to build specialised native apps later, if there's some expected pay-off, no?
But if they'd had separate code-bases all this time the maintenance effort to date would have been an order of magnitude higher. And consolidating to a single codebase from that would be a nightmare (should some new cross-platform toolkit mature).
> The average user don't care about native and non-native. But they do absolutely care about performance, look and feel.
And I've never heard anyone in my office (which has lots of non-devs) complain about Spotify's UI when they're changing the office music. Search for a song or playlist, play ... works fine as far as they're concerned.
Show me the evidence average users think there's a problem.
Just because the average user is unaware the shitty UX, performance or battery-draining is your app's fault, doesn't make it a good or professional choice. It means you can get away with it, because the user is unaware there was a choice, who's making it, and based on what criteria.
Why would you say that? I'm not convinced you even looked at it longer than to arrive at the conclusion that it has some JavaScript in it so it must be like Electron.
The whole point of Fuse is that all the heavy loading is not JavaScript. Basically your business logic is JS, but the UI is declarative and both the UI and the animations are all hardware accelerated, compiled down to machine code. This makes it very much not like Electron, and more in spirit like, say, PyQt or something like that.
It's a bit more like React Native, in that the UI controls are native. But unlike React Native your UI composition (the "components" in React lingo) plus the animations are compiled down to machine code too, and always hardware accelerated.
And to answer your question - people don't hate native languages, they hate making the same app twice.
has anybody actually used Fuse for a real product? we could not find anyone to talk with about it and that was a deal breaker
So for my MVP, I'm planning to use React Native to build the minimal interface, and then (once funding clears and we can figure out the hiring situation) I'll get one or two engineers to work on building a native app for each system.
But why are they completely different? Surely the UI parts are different, but the meat of the work done internally is exposed by a common API?
Our CEO (and primary engine coder) was interviewed by Forbes earlier this year, and in the interview he touches on A LOT of these points: https://www.forbes.com/sites/julianmitchell/2017/06/29/this-...
Quick quote:
"Our (former) jobs as programmers at ARM gave us a front-row view of all the capabilities of modern mobile devices, and it became apparent that most developers underutilized a lot of these devices. As a consequence, much of the raw power didn't benefit the end users who bought these pocket-sized supercomputers. Secondly, the way apps are developed hasn't changed much in the last 20-30 years. New tools and computer languages have come and gone, but the process remains largely the same, with developers and designers operating in separate worlds, using a different set of tools.
This is partly because collaboration across these boundaries requires a huge amount of additional work just to translate and re-implement the vision of stakeholders and designers into production code. In turn, this resulted in unsustainable processes of slow iterations for testing and validating ideas. Consequently, you end up with products and user experiences that are less thought-through or polished, even though you've spent an unacceptable amount of time, resources and risk to produce them.
These two takeaways lead us to realize that what was needed wasn’t another micro-optimization tool. We had to take a step back and consider the entire development process from through the lens of product owners and designers, as well as developers. Fuse is the byproduct of that process."
Fuse Studio is meant for people who want or need extra tooling on top, and is indeed our premium offering (the Fuse Professional plan doesn't just include Fuse Studio, but also premium components, Xcode and Android Studio library export support, multiple viewports and more). It's definitely not just for teams either, it's just _more suited_ if you work together with others.
There's a 30-day free trial of Fuse Studio too, so check it out and see if you'll do more than well enough with regular Fuse.
https://www.redhat.com/en/technologies/jboss-middleware/fuse
This same comment chain can waste space in pretty much any thread on any product. What's the point in having it in every thread?
For example, "Fuse Tools" (or "Fuse Apps"). As a bonus, the domain name is already fusetools.com.
- if they are not successful it will not matter;
- if they are successful they will out google the original FUSE and win.
So their strategy will work for them whatever happens.
It's now just a question of moral stand.