Live data from Hacker News

Fuse

fusetools.com

81–90 of 100 posts

Re: Fuse

#81
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…

Even if you do have the budge for two native apps it may be that you would rather not spend all that money twice, or you would rather have one app with twice the features of two native apps.

That said, all cross-platform solutions at the moment currently suck, except maybe Flutter, but that is still very alpha.

Re: Fuse

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

Yeah, except "Fuse Tools" still sounds like tools that you'd use for the fuse filesystem. I'm pretty sure there's at least one fuse-util or fuse-tools package for the major linux distros out there that has nothing to do with this Cordova equivalent.

Re: Fuse

#83
post #52

> I never understood why people hate native languages so much You actually need to know some programming if you want to write applications in Swift, Java or .NET. That's why.

You can write Javascript without knowing how to program?

You don't know how much I did with the magic of copy-and-paste

Re: Fuse

#84
post #70

Earlier quoted context omitted.

Cross platform apps don't need to have separate codebases. Cross platform libraries and toolkits do exist.

Existing is not sufficient. Convince us one of those tools is any good, because it doesn't seem like it, from the traction they've had so far.

I want the same thing you want, but I recognize that such a thing is very, very hard to do.

Re: Fuse

#85

Earlier quoted context omitted.

I wonder if it's struggling with the size of some of my playlists. I've got a 70 hour coding music playlist, that's the only thing I can think would slow it down during startup. My machine has 16GB RAM. Helpful to know I might be an isolated case, though.

Hmm, 70H and downloaded? Because I have a 63H playlist in my 'Playlists' that I didn't make but have, and I have no lag like you describe on my Windows 10 machine.

The 70hrs isn't downloaded on my Mac desktop, just streaming. I've timed Spotify ("native" Mac app) at 25 seconds from launch to UI - but even at that point, the Browse UI still doesn't appear for a long time.

Guess I'm just unlucky on this one. Thanks for the additional info though.

Re: Fuse

#87
post #74

> I never understood why people hate native languages so much You actually need to know some programming if you want to write applications in Swift, Java or .NET. That's why.

So, how many multiplatform releases do you have under your belt romanovcode?

I did some mobile application releases for some big companies which products you are using, actually.

Re: Fuse

#88
post #76
post #40

Earlier quoted context omitted.

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.

> That Spotify, Whatsapp and Slack don't have native apps a disgrace beyond comprehension 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.

> Pretty easy to comprehend why you wouldn't burn more developer resources than necessary actually.

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.

Re: Fuse

#89

Earlier quoted context omitted.

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.

[deleted]

Re: Fuse

#90
post #75
post #38

Earlier quoted context omitted.

> 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 c…

> I also don't see why it matters if your MVP is built on a cross-platform abstraction To reach a larger audience with less dev time/fewer devs?

Reaching a larger audience isn't a minimum viable product. Especially, like I said, if you're fighting with the abstraction to achieve your minimum viable feature set.

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.

Post reply on HN