Live data from Hacker News

Fuse

fusetools.com

31–40 of 100 posts

Re: Fuse

#31
post #11

I really don't see the point. 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 bu…

Because it's fast and slick. I'm​ no expert but my impression is that Fuse gets you the slickest, smoothest apps barring coding them in Swift and Java.

Additionally Fuse has pretty amazing devtools for something not as hyped as, say, React Native.

Re: Fuse

#32
post #22
post #12

Earlier quoted context omitted.

I don't really get the trend of name collisions. First React, now Fuse... what's next, a Linux brand of detergent?

What's not to get? Pretty much all words are used as names already and roughly in proportion to how simple they are. 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?

They could have pulled up a thesaurus and found a better name.

Re: Fuse

#33
post #22

Earlier quoted context omitted.

What's not to get? Pretty much all words are used as names already and roughly in proportion to how simple they are. 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?

If the name is already taken, you can at least go for some qualification (capitlization doesn't count). For example, "Fuse Tools" (or "Fuse Apps"). As a bonus, the domain name is already fusetools.com.

They don't care, they win in any case. Their user base don't know about fuse, and:

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

Re: Fuse

#35
post #28

Earlier quoted context omitted.

> Also, I never understood why people hate native languages so much - why do you want to replace everything with Javascript? 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...?

You don't need completely separate code bases, just separate UI implementations. 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.

> When did we decide that developer time was more precious than user experience anyway?

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.

Re: Fuse

#36
post #3

Looks like Electron on steroids. The landing page is nice but it's like putting lipstick on a pig - it's still a pig in the end. 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?

> it's still a pig in the end.

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.

Re: Fuse

#37
post #28

Earlier quoted context omitted.

You don't need completely separate code bases, just separate UI implementations. 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.

> When did we decide that developer time was more precious than user experience anyway? 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 b…

> and a non-native experience is something like 7 out of 10 good

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

Re: Fuse

#38
post #28

Earlier quoted context omitted.

You don't need completely separate code bases, just separate UI implementations. 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.

> When did we decide that developer time was more precious than user experience anyway? 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 b…

> 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

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.

Re: Fuse

#39
post #28

Earlier quoted context omitted.

You don't need completely separate code bases, just separate UI implementations. 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.

> When did we decide that developer time was more precious than user experience anyway? 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 b…

Spotify would be vastly improved going native. That thing has ridiculous lag when loading the app, trying to play a song. I have an older iPhone, so it's much more noticeable, but then when you use the built-in music app and see how fast it is, it's inexcusable. I've started buying music again instead of using Spotify because of it.

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.

Re: Fuse

#40
post #28

Earlier quoted context omitted.

You don't need completely separate code bases, just separate UI implementations. 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.

> When did we decide that developer time was more precious than user experience anyway? 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 b…

As a user, if good native is 10/10 non-native is at best 5/10. Usually though a native app isn't good so it's only 6-7/10. Non-native though are usually in the 2-4 range...

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.

Post reply on HN