Hacker News new | ask | show | jobs
by qbasic_forever 1930 days ago
History has shown us over and over again, always bet on the web. Sure you might not like JS as a language, you might find CSS confusing and full of warts, etc. but it's here and will be here 20, 50, and 100 years from now. We're not going to just sit up and throw away 25+ years of progress and history on the web overnight. Tech like java applets, flash, silverlight, etc. come and go like fads. Who knows if Google will even care about flutter in 5 years, let alone 25 years. A page that Tim Berners-Lee wrote 25+ years ago renders just fine in a browser today.
6 comments

[Flutter Eng. Dir here]

I guess I would like to think we are betting on the web. :) All of the Flutter founders came from Web backgrounds. After years of attempting to make the Mobile web awesome, we forked Chrome and built a new thing. Now we're bringing it back to the Web.

The web is a big tent. I think there is a lot of room for innovation here. We're attempting with Flutter to push on some of the newer aspects of the Web. There are still some pieces missing from the Web to make things like Flutter really shine (e.g. a multi-line text measurement API could help get rid of a ton of code in Flutter Web). As you saw in the keyonte today, we're working with Chrome to continue to improve life for developers.

I don't think Flutter will ever be the right solution for all of the Web. Certainly not today. For example, we don't even support SEO or great indexability yet (although it's long been planned for and will be coming soon).

I just want to believe we can do better. We, developers, can all push development (including the web) to be better. Hopefully Flutter will do it's part.

Read somewhere flutter canvas rendering was only a first « quick n dirty » way of rendering something on the web, but a true DOM renderer was the end goal.

Can you give more info on that ?

Another question i’ve always had about flutter : last time i explained how this tech looked promising, a friend asked me about performance. I said « they said it’s really good and smooth ». But then we tried the iOS demo app (something very basic about vegetables) from the app store, and the scrolling performance was a total disaster (on an iphone x).

Do you have an explanation for the discrepancy between the official ad one can read on google blogs, and the real-world experience of app developped with flutter ?

When Chrome has become synonymous with the Web :facepalm:
You have to fork something, you can’t just fork the web as it is an abstract noun.
As long as you manage to recreate Flash game ecosystem you will win alone on it.
> History has shown us over and over again, always bet on the web.

This is a mantra on HN. But is it true? I don’t think it is if you’re trying to build a big product mainstream people will use.

People want native apps. No one needs the apps to work in 25 years. The web is just part of the picture, an important part, but still just a part.

> People want native apps.

I'll take a well done web page anytime over a native app.

> well done web page

That is an oxymoron.

People want native apps for some domains. On my phone, I typically want the opposite. Every company has to have its own app, and it’s annoying. I do want Flux, because that functionality can’t be done without an app. I don’t want a terminal in my browser because that would be ridiculous.

Blanket statements don’t work.

> I don’t want a terminal in my browser because that would be ridiculous.

Secure Shell[1] is actually my go-to terminal for daily use, and supports some features that are important to me (e.g. OSC 52 codes) that GNOME Terminal doesn’t.

[1] https://chrome.google.com/webstore/detail/secure-shell/iodih...

> People want native apps.

I would argue that people want a certain quality experience. They don't care about whether the developer used Swift or Javascript or OCaml to deliver it.

The Web does usually deliver a certain baseline experience, and most platforms actually deliver a browser which mostly matches platform experience.

For native apps, there is a wide variety of things which you may or may not be able to do based on what the developers implemented and whatever their chosen toolkit supports - including toolkits which reimplement their own drawing, widget and event systems and does not support accessibility or even consistent copy/paste.

For web apps, you do have to somewhat actively have to break this stuff as a developer.

The same engine of HTML + JS has powered entire businesses and industries from $0 to billions and billions of dollars over 25 years. Amazon.com would not exist without web browsers, and its entire trillion dollar+ business is an enormous bet on the web. I would say there's zero danger of the web going away when folks like that (and many, many more... Google, Facebook, etc.) depend on the web for every microsecond of their existence.
>Amazon.com would not exist without web browsers, and its entire trillion dollar+ business is an enormous bet on the web.

Except 70% of e-commerce, 90%+ of Social Media are now on Mobile Apps, where they were all previously 100% Web.

The problem with Tech industry is that too much thinking is about centralised, decentralised, Technology with backend front end. etc. When its users or customers dont give a fuss at all.

That's because the current mobile platforms were engineered from the ground up specifically to kill the web in favour of walled garden app stores.

We'll have to see how long this approach will stand up for, both legally and technically. With real open source phones and antitrust developments we might see a revival of mobile web eventually.

Even in the extreme unlikely case of opening up Apps without App Store. People will still be using apps. Even if they are Web Apps or Apps with WebView. It will still be Apps. Simply because accessing a button is easier than typing in a link.

Web is still great for Discovery though.

How is a home screen app icon different from a tab in your browser, if it leads to what is essentially a web app? I count such apps as a success wrt "betting on the web".

Sadly, the capabilities of PWAs are very much second class on every mobile platform right now. But I don't think it will stay that way forever.

If today FAANG had to choose: shut down your websites or shut down your native apps: which would it be?

Which platform did Clubhouse build out first? Why?

For Facebook and Apple, mobile (native) is definitely the most important.

Advertising accounts for 99.9% of Facebook revenue, with mobile advertising accounting for 94% [1]

Not sure for the other ones.

[1]https://www.businessofapps.com/data/facebook-statistics/

Clubhouse is targeting the middle-class silicon valley market right now (quite literally, those are the only people who got invites early on), who of course are infatuated with apps and have the money for fancy phones, tablets, etc. It's smart marketing for them to go where their customers are right now.

The web is for everyone--I can go to an internet cafe in a slum and browse and buy from the same Amazon.com as I can from inside a $15M mansion. It's a quantum leap in access to the world using the web.

Not sure what personal income has to do with anything. Hand held touch devices have revolutionized Internet access. The deeper down the income scale you go, the less likely you are to encounter a personal computer while you’ll still likely encounter a smart phone. Amazon will work on the web or as an app on that phone, but with the app the user experience will be better. That may be because Google and Apple have intentionally prioritized native APIs while hindering PWAs, but that’s still the case.

Anyway, I do still wonder: if FAANG had to pick between native and web apps, which do you think would they pick?

F: A few months ago I'd have said apps. Now after their latest spat with A, maybe they're having a think?

A: web, for sure. That's how they make their money.

A: I wonder how much money they would lose if they shut down their website? Would they sell their stuff on A instead?

N: Who cares, it's only there to make the acronym nicer.

G: Web.

Apart from Google which has a complex answer. Most of the traffic from FAANG are now coming from Apps.

Facebook could have shut down their Website and it wouldn't even have a 10% revenue impact.

My own self would say native apps, 10 years ago.

Today, 10 years later, I say Web.

They can collect more metrics and have more control when it's a native app. My web browser is still my most used app on my phone.

But I think betting on the web actually meant to bet on native for each respective platform. Bet on native for the web is betting on HTML/CSS/JavaScript. And then have a Java/Kotlin version for Android. And have a Swift/Objective C version for iOS

I think the learning is, write once run everywhere is what has been tried and failed time and time again for user applications. Java failed many times, Silverlight, Flash, etc.

The reason is always the same, user experience is limited when you go that route, and it eventually loses out to competitors who offer the better user experience on the user's platform of choice.

> People want native apps.

Only because OS vendors made them believe that.

Or maybe because native apps are a better experience, nearly every time. True multi-threading, native code performance, latest UI implementation, more and better hardware access/performance, etc.... I can keep going but the point is that the web really is the lowest common denominator. That isn't bad but it also isn't how you build the best experience.
If OS vendors wanted web-apps to succeed, they could have done a lot more than they have done so far. E.g. better integration, or improved web standards to optimize for certain cases.
No matter how "better you integrate", there's one big core issue: the DOM. You simply cannot make the DOM behave as smoothly an as reliably as a native app. And no, no amount of "improved web standards" can help with that.
The DOM is just a kind of retained mode graphics, which can be fast depending on implementation. Also the DOM in most browsers is already sufficiently fast for many applications. It will never be as fast as native, but if you think that it needs to be then you are missing the point.
Why would they want that if they can build native SDK and won't be tied to anyone else?
That is my understanding as well.
I generally agree with you, but I don’t think it’s unequivocally true. Facebook bet on the web/HTML5 for their iOS app, and Zuckerberg later referred to it as the company’s biggest mistake.
That was because he trusted his engineers that believed in ideology rather than objective and rational evidence.

Wanting / Loving something to succeed is one thing. Whether it will actually work or succeed is an entirely different matter.

> History has shown us over and over again, always bet on the web.

For what it's worth, people had the exact same mantra about internal combustions engines for decades any time someone brought up electric cars.

You're absolutely right that entrenched systems are hard to change and attempts to change them mostly fail... until one succeeds.

I will gladly throw away 25 years of “progress” because it is just programmer busywork and monopoly lock-in.
Google does have a history of ditching tech that, to them, doesn't work out.