[HN Gopher] App Should Have Been a Website (and Probably Your Ga...
___________________________________________________________________
App Should Have Been a Website (and Probably Your Game Too)
Author : thunderbong
Score : 239 points
Date : 2024-12-31 07:38 UTC (1 days ago)
(HTM) web link (rogueengine.io)
(TXT) w3m dump (rogueengine.io)
| gazchop wrote:
| I disagree. The problem is more nuanced.
|
| A well implemented (native) app is always better than a well
| implemented web site.
|
| The problem is poorly implemented apps which are just UI wrappers
| hitting dumb APIs or embedding entire web stacks which hit dumb
| APIs. A well implemented web app isn't much better than that.
| They don't work offline, they use way more resources than
| anything native and they leak data like a sieve generally.
| adastra22 wrote:
| > at Rogue Engine, we're committed to being the go-to game
| engine for Three.js and the web
|
| and there you go, author has a vested interest in you making
| web apps.
| polotics wrote:
| well the article is well reasoned enough. what I gave up on
| was finding actual pricing information for this engine. all
| it say is free if you earn less than 80k... so what's the
| price please?
| egypturnash wrote:
| https://rogueengine.io/GetStarted says:
|
| Plus $ 20 $ 10 / month / seat Billed Annually $ 120
|
| Pro $ 50 $ 25 / month / seat Billed Annually $ 300
|
| Enterprise $ 90 $ 45 / month / seat Billed Annually $ 540
|
| Each of those tiers has a different "free if you earn less
| than $xxx" level that I'm not gonna cut and paste. There's
| a chart with the differences between what those tiers gets
| you too.
|
| Also:
|
| Can I publish anything I want to Rogue Play?
|
| You're allowed to publish content that is neither sexual in
| nature or illegal under either UK law and the laws of your
| country of residence.
|
| What happens to my files if I cancel my subscription?
|
| When you cancel your subscription your files will be locked
| and you won't have access to them until you buy a new
| license. They will be scheduled for deletion in 30 days.
|
| What happens to my files if I downgrade my subscription?
|
| It's your responsibility to free the necessary space before
| downgrading. Your files will be deleted after 24hs unless
| you take action.
|
| ----
| adastra22 wrote:
| I don't think the article was well sourced. WebGL
| technologies might be adequate for casual games... maybe.
| But it will be a very long time before they approach AAA
| gaming performance. And there is still a ton of funkyness
| about input (gamepad? multitouch?) and latency that is hard
| to address on a web stack.
|
| He just asserts that the underlying technology has come
| along. It hasn't.
| ndr42 wrote:
| From the article: "[...] web apps have caught up. They're
| faster [...]" Especially how can this be true?
|
| Maybe this doesn't matter because it's already fast enough but
| the difference in look and feel will be noticeable.
| oneeyedpigeon wrote:
| The writer probably meant "faster [than they used to be]"
| rather than "faster [than native apps]".
| hombre_fatal wrote:
| > A well implemented (native) app is always better than a well
| implemented web site.
|
| Dunno, native app doesn't have URLs nor deep links. I can't
| link you to a page in my native app that you can click on.
|
| In my iOS HN app I'd have to click "Copy website link" to share
| a submission. If there were no website, I couldn't share it at
| all. Same with Reddit.
|
| For most apps, that's a lot to give up when you app is
| basically just a website without a url bar.
| oneeyedpigeon wrote:
| Same native apps don't even relayout when you change window
| size, let you change the font size, or let you copy text.
| manmal wrote:
| Native apps made with SwiftUI or Jetpack Compose adjust
| their font size according to user preference in system
| settings out of the box. They also relayout automatically.
| Copying text on press is a one-liner in both frameworks,
| just need to think of it.
| sltkr wrote:
| Android apps absolutely support deep links:
| https://developer.android.com/training/app-links (surely iOS
| supports this too?)
|
| It's also widely implemented in practice. For example,
| Instagram allows copying links to posts, and if you can view
| an Instragram link in the browser, it opens in the app.
| victorbjorklund wrote:
| ios and mac got url schemes. Sure not all developers
| implement it correctly. But not all sites implement a good
| url structure either (keeping state etc in url for sharing)
| jcotton42 wrote:
| Android and Windows do too.
| dickersnoodle wrote:
| iOS apps absolutely do support deep links and URLs. Custom
| URL schemes are the older of the two and let iOS launch the
| app when someone taps on a URL that begins with its protocol
| (e.g. "bugmunch://orders?id=xxxxxxx"); the newer is Universal
| Links, which lets you set your web site up to launch your app
| from the web page if it's installed on your device.
| backspace_ wrote:
| On a side not, I like how we have electron apps that are 100s
| of mega that just access a website. Just as much of a waste.
| amelius wrote:
| > A well implemented (native) app is always better than a well
| implemented web site.
|
| No, because it fails to support the feature of running
| virtually anywhere.
|
| For many people this is the #1 feature. Everything else is just
| icing on the cake.
|
| Who cares about an app that is 2x faster but doesn't run?
| flkiwi wrote:
| I've watched Logseq (note app) go from a perfect little
| browser-based app that did exactly what I wanted--block-based
| markdown notes synced through git--to an app with dozens of
| features that are pure bloat for me that I can't use in half
| the places I need it because I cannot install apps.
|
| It was an interesting process to watch start, because people
| were like "finally an app!" and "moving on from 'just' a
| website!" but without any real justification for it. The app
| itself was the accomplishment.
|
| And I should note the Logseq app is a good piece of work. In
| absolute terms it's great. It is, however, not what it used
| to be and not really what I want. I'd like to fork Logseq,
| deprecate the app, and have a self-hosted browser interface
| with storage on the server, synced to a git repository for
| backup.
| mjmsmith wrote:
| > For many people this is the #1 feature. Everything else is
| just icing on the cake.
|
| I hear this sentiment from developers much more than non-
| developers. I wonder what percentage of developers do all
| their work within a browser.
| amelius wrote:
| Non developers typically don't think about these things.
| They just suffer them subconsciously or accept the
| situation as something they can never change anyway and go
| on with their lives. You have to ask them to find out.
|
| And I also hear developers complain more about performance
| issues than non developers.
| syndicatedjelly wrote:
| > A well implemented (native) app is always better than a well
| implemented web site.
|
| Given that the entire article argues pretty strongly against
| this, you need to at minimum argue against the points posed, or
| present your arguments for why "well-implemented native apps
| are always better". It's not enough to make a straw man of the
| worst possible scenario and claim that it holds true for the
| general case as well.
| wiseowise wrote:
| > A well implemented (native) app is always better than a well
| implemented web site.
|
| No, not always. I don't care how well implemented or optimized
| your "app" if it's something that could've been a static web
| page.
|
| > They don't work offline, they use way more resources than
| anything native and they leak data like a sieve generally
|
| False, false and false.
| throwitaway1123 wrote:
| > They don't work offline
|
| This isn't true. Offline functionality is the raison d'etre for
| Service Workers. You can run an entire HTTP request router on
| the client to respond to requests while offline:
| https://hono.dev/docs/getting-started/service-worker
| Spivak wrote:
| Are you guys okay? Don't get me wrong it's clever, but it's
| also insane.
|
| If I pitched the idea of having SMB shares work online by
| shipping a driver that could intercept low level SMB calls
| and reroute them to a mock SMB server that holds the cache
| they would have assumed I'd lost it.
|
| Surely the browser could help you a bit more to implement
| offline sites in a more integrated fashion.
| throwitaway1123 wrote:
| It's ultimately just a little event listener function that
| accepts a Request object and returns a Response object. I
| bundled the service worker by running a quick `npx esbuild
| --minify --bundle --outfile=sw.js sw.ts` command, and it
| produced an 18.6kb JS file in 10 milliseconds. That's not
| even half the size of libraries like HTMX, Alpine, and
| jQuery.
|
| You can of course use the CacheStorage API directly as well
| (you're not obligated to use a mock server):
| https://developer.mozilla.org/en-
| US/docs/Web/API/CacheStorag...
|
| I've certainly seen crazier things though. People routinely
| include entire copies of Ubuntu LTS in their Docker images
| to ship tiny HTTP servers.
| ctippett wrote:
| I sympathise, but talking to my sister I've come to appreciate a
| different point of view. I have an "app", a PWA, that she says
| she cannot find because it's not in the App Store. Despite
| telling her it's available as a website, this seems too much...
| she just doesn't use -- or is comfortable using -- Safari.
| spiderfarmer wrote:
| Never call a PWA an app, people will get confused.
| oneeyedpigeon wrote:
| But the "A" stands for "app"! Is there anything you could
| call it that would be _less_ confusing (because "PWA" or
| "Progressive Web App" sure ain't it)?
| spiderfarmer wrote:
| Until some massive marketing campaign explains to all users
| of the internet what PWA's are (which is never going to
| happen), there's nothing wrong with calling your PWA a
| website if it prevents a lot of confusion.
| oneeyedpigeon wrote:
| Sure, but I also think there's nothing wrong with calling
| it an "app" if that's the buzzword that will tip some
| people from dismissing it towards trying it out.
| spiderfarmer wrote:
| If it's clear that people expect 'apps' to be in the app
| store, how can you think "there's nothing wrong" with
| calling PWA's 'apps'?
| oneeyedpigeon wrote:
| OK, "there's nothing wrong with calling a PWA an 'app' in
| most contexts, unless the person listening to you is
| likely to try to search for the PWA in an app store".
| spiderfarmer wrote:
| Ask any random person where they would go to install an
| app and you'll stop belittling this problem.
| jay_kyburz wrote:
| I don't know why you wouldn't just call them "web apps".
| Why the P and why the acronym.
| neilalexander wrote:
| Further to that, there are plenty of people who can't
| really articulate what a web browser actually is or how a
| website differs from an app. It's not clear to me whether
| these users would be more accepting of a PWA or if they
| would be even further confused by them, particularly if
| they have to be left to find the app on the web first in
| order to "install" it, even more so if they've never
| bothered to look at what all those buttons in their web
| browser actually do.
| Ntrails wrote:
| I dislike apps and avoid installing them in general terms.
| They're bloated and frankly I have better things to store on my
| phone (mostly music, but also photos, conversation histories
| etc). I do not need an "app" for submitting a form. Looking at
| a website. etc etc
|
| My favourite thing about using a website? It can't send me
| attention grabbing notifications. It can't harass me for perms.
|
| I'm 100% an outlier. My friends don't blink twice to install
| all manor of loyalty, news, social media, lifestyle, games etc
| etc and rarely clean up. It's all just choices and preferences
| - the world does not suit me.
| mrweasel wrote:
| The world seems to be reversed in my mind. On my phone
| everything wants to be an app, and everything on my computer
| wants to be a webapp. I want the opposite. Native apps on the
| computer and the phone can just be webapps, because I don't
| really care, nor do I need to repeatably use the same app on
| my phone.
|
| On my computer I have a few programs installed, which I just
| constantly. On the phone I need each app only a few times a
| month, if that, yet they all insist on being actual apps.
| rpdillon wrote:
| I'm right there with you. There are probably dozens of us!
| SoftTalker wrote:
| Same. I have only a few apps installed that my phone didn't
| come with. No games. No social media apps. Even email I
| access via Safari. If I absolutely must use an app for
| something, I typically install it, do what I need, and then
| delete it.
| mdaniel wrote:
| If you're on Android, you may enjoy the new "Archive"
| functionality, which uninstalls the app but retains its
| local data directory so when you tap the icon it re-
| downloads the apk on top of its existing data directory, so
| no more first-user experience
| https://support.google.com/googleplay/answer/15523443?hl=en
|
| I believe it's primary use case is storage efficiency but
| it works perfectly fine in your use case of preventing the
| code from running while you're not actively using it
| 00deadbeef wrote:
| > My favourite thing about using a website? It can't send me
| attention grabbing notifications. It can't harass me for
| perms.
|
| But it works the same as for apps. You get prompted once on
| iOS at least. You either opt in for notifications or you
| don't. There's no difference.
| fidotron wrote:
| This was because every ad agency on the planet wanted to be in
| apps when the App Store took off, so they rebranded websites to
| apps to confuse people.
|
| Chrome, being a division of a huge ad company that makes money
| from these agencies, not merely played along but took a leading
| role in sowing the confusion.
| franze wrote:
| It is not about tooling, but distribution.
| noam_compsci wrote:
| This should be auto posted as first comment on every post about
| a new technology / platform
| streptomycin wrote:
| Android lets you list PWAs in the app store, so we're halfway
| there...
| oneeyedpigeon wrote:
| > Platforms like Poki and CrazyGames, with a combined 95 million
| players a month, are leading the charge in, what I like to call,
| the Browser Games Renaissance.
|
| I'm probably not the target market, but my first impression of
| Poki is that it's absolute trash; it looks like a shopfront for
| the lowest quality mobile games I can imagine. The first thing I
| tried was a block-puzzler that involved drag-and-drop to move
| pieces, but the drag didn't track the mouse cursor properly.
|
| If someone asked me "which site is leading the charge in the
| Browser Games Renaissance?", I would say itch.io, hands down.
| noam_compsci wrote:
| Agreed I'd rather spend more time on itch. But from a dev
| perspective poki has a chance to monetise while itch
| monetisation is near zero at the moment.
| nottorp wrote:
| That's a good thing for the customers though.
|
| When the original article is talking about escaping the
| tyranny of the app store it sounds to me like they don't want
| to share the loot box revenue with Apple/Google, like our
| chinese friends at Epic.
|
| Unfortunately for them, there are still pay once real games.
| Some of the good indies are on itch.io indeed.
|
| Stop calling lootbox dispensers "games" please. I prefer
| paying for a game in advance instead of being monetized.
| nforgerit wrote:
| Whilst I agree with most of the points, author is making here I
| cannot help but make a small snarky remark that we, as a dev
| community, have been talking and dreaming about those talking
| points since the advent of html5 which is roughly 15ys.
|
| Marketing and availability, i.e. is it within reach when a
| customer thinks about it, are core problems needing to be solved.
| manmal wrote:
| Maybe 2025 will be the year of PWAs? /s
| syndicatedjelly wrote:
| Who is this unified hivemind dev community you speak of?
| spiderfarmer wrote:
| As the solo founder of a couple of 'popular' websites I get asked
| regularly if I want to create an app. When I ask them what they
| want the app to do what a website can't, they can't name a single
| USP, especially now notifications work on all devices.
|
| And really, who has the time to maintain a website and two apps?
| Or rebuild a decade old platform in a janky cross compiling
| solution like Flutter that is always on the brink of being
| sunsetted?
|
| Not me. I'll spend that time on improving my websites, thanks.
| I'll let my competitors go bankrupt on trying to monetise an
| expensive app that should have been a website.
| _fat_santa wrote:
| > And really, who has the time to maintain a website and two
| apps? Or rebuild a decade old platform in a janky cross
| compiling solution like Flutter that is always on the brink of
| being sunsetted?
|
| I'm a solo dev for a startup and this is something I always
| hammer home to my non-technical co-founder. I tell him that
| spinning up an app that would have parity with our current app
| will not only take close to a year for a single person to
| develop, but from there on out every feature will come out
| slower since we need to have mobile parity as well. Out current
| plan is to slowly make all the pages on our website mobile
| friendly and even that is a big lift for a complex business app
| kdmtctl wrote:
| > I'm a solo dev for a startup and this is something I always
| hammer home to my non-technical co-founder.
|
| He is just trying to piggyback an another distribution
| channel to get more visibility and another place to be found.
| It has nothing to do with UX.
| mertbio wrote:
| > But fast-forward to today, and browsers can do all that.
|
| Browsers can't access all the APIs in iOS.
|
| > Developers pay hefty app store fees
|
| You pay 99$ per year and 15% for each sale. Apple handles VAT,
| refunds, distribution and so on.
|
| > They're faster, more flexible, and work seamlessly across
| devices. Native apps? Not so much.
|
| Enabling iCloud sync for your app is just a single click on
| Xcode.
|
| > Why Web Apps Are the Future
|
| On a national TV program in Germany, they talked about an app
| related to trees in Hamburg. That same day, my app on the App
| Store experienced a significant spike in downloads. When I looked
| into it, I discovered that the app they mentioned on the news was
| actually a PWA! :)
|
| I feel like the author doesn't have any idea about native app
| development.
| jampekka wrote:
| There are other platforms than iOS.
| oneeyedpigeon wrote:
| Your first quote is very misleading because it followed this:
|
| > apps had unique features like notifications and offline
| access.
|
| Browsers _can_ do those things. If you 're going to offer
| "Browsers can't access all the APIs in iOS" then, at the very
| list, provide one or two examples of what you're referring to.
| aman-pro wrote:
| Contacts API; Not all sensors are supported
| charrondev wrote:
| One major one for anything with a text input it the inability
| to know when the keyboard is open and closed and how large it
| is.
|
| It's very common for something like a comment box to keep the
| text pinned above the virtual keyboard. This is impossible on
| the web. If you have ever seen an implementation of this on
| the web (for iOS) please point me in that direction as I
| would love to copy the implementation.
|
| Notifications just came recently, but weren't available for a
| decade after availability to native apps.
|
| The final hurdle is discovery. It's not possible for a site
| or app to act as a one click installer of a PWA (add to
| homescreen) and sites can't prompt to be added.
| threeseed wrote:
| > Browsers can't access all the APIs in iOS
|
| And nor should they.
|
| Every single API that gets added to a browser increases the
| likelihood that you will be accurately fingerprinted and
| tracked across the web. This data is then packaged and sold to
| third parties whom you will never know about.
|
| Every time I hear the PWA argument it's always what is in the
| best interest of developers not users.
| bogdan wrote:
| Fingerprinting isn't going anywhere without legislation. New
| browser APIs or PWAs won't change the underlying problem.
| It's the same status quo.
| the_gipsy wrote:
| Apps fingerprint you much, much better, and can access more
| data (despite what apple marketing says), your argument is
| moot.
| scarface_74 wrote:
| What data can apps access without your explicit permission?
| bdangubic wrote:
| install tiktok (if you do not have it) and disable
| everything, no mic/camera/photos/contacts/... nothing.
| then ask you partner/friend/... to send you some text
| messages about purchasing an ebike for instance. open
| safari and do some searches for ebikes (https://blue.bike
| perhaps and others)... the head on over to tiktok and
| scroll a bit and see if any ebikes start showing up...
| threeseed wrote:
| a) There is no evidence that Apple is sharing messages
| with third parties.
|
| b) You are simply confirming my point which is that when
| you visit a website it is able to tie you to an
| consistent identifier through the APIs your browser
| supports.
| bdangubic wrote:
| there is no evidence for a whole lot of things... /s
| scarface_74 wrote:
| So you think there a conspiracy and that TikTok for iOS
| has been able to break out of its sandbox and read your
| text messages?
|
| This would have made news if so.
| acheron wrote:
| What? No. Apps are guaranteed to be sandboxed and can't
| access anything you don't let them.
| rpdillon wrote:
| > Every time I hear the PWA argument it's always what is in
| the best interest of developers not users.
|
| I can control a web app through customizations to my browser
| in ways I can't with a native app. It's about user choice.
| mamcx wrote:
| > Developers pay hefty app store fees
|
| So, hosting doesn't cost?
|
| Too many app-but-websites should be local, but because are web
| requires hosting and likely a database (that must be 'web-
| scale' so it survives bots).
|
| My web app cost far more than my older native one. And is far
| harder to maintain...
| e12e wrote:
| >> They're faster, more flexible, and work seamlessly across
| devices. Native apps? Not so much.
|
| > Enabling iCloud sync for your app is just a single click on
| Xcode.
|
| How well does that work on Android, Linux and Windows desktop,
| ChromeOS?
| wiseowise wrote:
| > Browsers can't access all the APIs in iOS.
|
| Always laugh at the argument. Surely this matters for yet-
| another-mobile-crud #3553333.
|
| > You pay 99$ per year and 15% for each sale. Apple handles
| VAT, refunds, distribution and so on.
|
| 15% until 1 mil, isn't it? And even without that, 15% is
| ridiculous price.
|
| > Enabling iCloud sync for your app is just a single click on
| Xcode.
|
| How many Xcode clicks to port iOS app to Windows, Mac, Android
| and Web?
| noam_compsci wrote:
| Web gaming might be a decent incremental revenue source (< 10%)
| for big developers or the main distribution channel for small
| studios that will never make it big.
|
| But it will never be more than that.
|
| 1. Game ops is too entrenched in mobile. The entire stack (user
| acquisition, analytics, monetisation) is tried and tested on
| mobile. These are difficult problems that seem easy to port to
| web games, but "devils in the detail". Eg When you're waiting on
| appsflyer to ship an update to properly attribute reinstalls for
| 6 months and end up wasting 25% of your UA budget during that
| time.
|
| 2. Consumers don't want web games. The UI just isn't there yet.
| You misclick out of a tab and lose progress or get distracted /
| start browsing another tab. Also to do with the ephemeral nature
| of a browser tab.
|
| 3. Unity's dev network effects are too large. People who know how
| to make games use unity. People who want to make games therefore
| learn unity. It's a flywheel.
|
| 4. Something psychological about downloading an app and seeing it
| on your Home Screen leads to retention.
|
| Source: 7 years game dev and each studio I've worked in has been
| paid multiple tens of thousand dollars to port a game to web.
| Metrics were never anywhere near as good.
| jampekka wrote:
| I'm sure there are problems with web games, but some of your
| arguments seem stem from ignorance about the modern web
| tech[1].
|
| > 2. Consumers don't want web games. The UI just isn't there
| yet. You misclick out of a tab and lose progress or get
| distracted / start browsing another tab. Also to do with the
| ephemeral nature of a browser tab.
|
| Fullscreen mode mostly solves the misclick problem. PWAs solve
| it entirely. Do consumers care at all about what the underlying
| technology is.
|
| > 3. Unity's dev network effects are too large. People who know
| how to make games use unity. People who want to make games
| therefore learn unity. It's a flywheel.
|
| There's Unity web. And people who really know how to make games
| can also use e.g. Unreal, which as compiled for web for ages.
|
| > 4. Something psychological about downloading an app and
| seeing it on your Home Screen leads to retention.
|
| PWAs can install to Home Screen.
|
| [1] There is admittedly one company unable to implement modern
| web tech.
| noam_compsci wrote:
| Just played around with a PWA on iOS and added it to Home
| Screen. Works really really nicely and so it seems pwa have
| come along a lot since I last looked into them! Thanks for
| the prompt to update my understanding.
|
| I do disagree in the developer point though. Those who know
| unity really do not translate well to unreal. Totally
| different languages and ecosystems. Also unity web has always
| really really sucked for anything other than gimmick games.
| antifa wrote:
| I'm not sure about the specifics of UE/Unity/Godot but I was
| under the impression that a Hello World in any of those for
| the web would be about 20MB where as the Three.js game I'm
| working on will be at most 1MB when done (not counting game
| music soundtrack).
| jampekka wrote:
| Sure, but so will be the native app.
| nazcan wrote:
| While I'm sure it wouldn't be easy, it sounds like an
| opportunity for disruption.
| rubymamis wrote:
| While the web platform is catching up due to the continuous
| supply of abstractions by modern browsers, once you must deviate
| from those abstractions, you quickly find yourself needing to
| implement something yourself that is much less efficient than a
| native implementation.
|
| I wrote about developing my own block editor from scratch[1]
| using C++ and QML after finding that Notion (and so many other
| web apps) are extremely slow and inefficient - in terms of
| CPU/RAM/battery life.
|
| I detailed a comparison between native and web block editors, and
| the difference is huge. The fastest web app (MarkText) is 60x
| slower at loading texts and uses 3x more RAM than my native app.
| Also, all web apps couldn't handle loading a very large text file
| (they were all hanging).
|
| Modern computers are blazing fast and efficient, there's no
| reason a text editor couldn't load large files. This is why, in
| my view, web apps aren't really the progress people make them to
| be. We're going backward, not forward, with web apps. This need
| to change.
|
| [1] https://rubymamistvalove.com/block-editor
|
| [2] https://rubymamistvalove.com/block-editor#8-performance
| oneeyedpigeon wrote:
| A web app that cannot handle a text file bigger than X bytes
| doesn't become useless, in the same way that a native app isn't
| useless even though it, too, has a limit on the maximum file
| size it can handle.
| rubymamis wrote:
| Any text editor that struggles to load a large text file on a
| modern computer is, simply put, inefficient. If 20 years ago
| they managed to write programs that could handle such cases
| and today many (web) apps fail at this task means we're going
| backward.
|
| My point is that it's much harder to write efficient code in
| the web ecosystem because you're bound to specific
| abstractions from the browser. Once deviating from said
| abstractions, it's not trivial to write efficient code.
| oneeyedpigeon wrote:
| > Any text editor that struggles to load a large text
| file...
|
| Define "large". If it's bigger than the biggest text file
| I'll ever open, then I don't care.
|
| My point is that "efficient" code isn't absolutely
| necessary in many, many cases.
| rubymamis wrote:
| The problem with that mentality is that you start seeing
| inefficiencies spring everywhere (why loading Discord
| takes so long? Slack? etc, etc).
| xcv123 wrote:
| It's a third world mindset where we end up with the
| software equivalent of public defecation, living in
| squalor and filth.
| kebokyo wrote:
| How is Discord not loading fast enough the result of a
| "third world mindset"? Is this one of those "this
| software is bad because it was made in China / India /
| outsourced to one of those countries" arguments (which I
| don't even think applies to this topic???)
| jknoepfler wrote:
| Inefficiency also compounds. If you're sending too much
| data over an unreliable connection using a bloated
| protocol (say), you have three multipliers. Now start
| daisy-chaining these things together, host them on
| bloated images on pods in underpacked nodes in k8s (not a
| potshot at k8s, which I like quite a bit, just... another
| plausible source of inefficiency). Write all the servers
| in Python (or worse, some Ruby on Rails backed by MySQL
| or something comically underperformant).
|
| We could keep going, but it maths out to mind-blowing
| amounts of waste just copying bytes around between
| buffers with no value add.
|
| (Old man editorializing at clouds: "and all so we can
| employ people who don't know how computers work to
| satisfy corporate product pipelines by shoveling digital
| shit onto people that they neither want nor need")
| cosmic_cheese wrote:
| The old metaphor of shipping bananas by packing the
| entire jungle surrounding the ape that's holding the
| banana does very well to illustrate the truly egregious
| level of inefficiency at play here, especially when one
| considers how there's tens or hundreds of thousands of
| these jungles involved in any given product...
| TeamDman wrote:
| I've recently been summarizing entire directories into a
| single chunk of text for use with Gemini, the other day I
| overshot and ended up pasting 28 million characters into
| vscode. It handled it pretty well.
| lurking_swe wrote:
| that's like a 28MB file, no? That's not exactly
| impressive to me on a modern computer in 2024. Maybe i'm
| crazy haha.
|
| I'd consider 28MB to be a medium sized file. Maybe 100MB+
| would be large?
| lurking_swe wrote:
| I've routinely needed to open a 5GB text file on my
| computer before (previous job), and only some "apps" can
| do it. If we even call them apps lol. It's just bloated
| web browser junk packaged as a pretty app.
|
| notepad++ solved this problem 20+ years ago.
|
| I agree it's an uncommon use case but it's kind of sad
| when an app struggles to open a file like that on a
| modern machine in 2024. Just sad.
| bee_rider wrote:
| I don't know that I completely agree. It depends on the
| functionality offered, right? Like vim, for example, can
| struggle with very large files if you ask it to do syntax
| highlighting all the way from the beginning (or, it can
| give you syntax highlighting that is just wrong if you
| don't). I don't think vim is very inefficient (could be
| wrong there, though), and I don't see any way to generally
| do syntax highlighting without looking at the whole file
| (although, of course, in practice there are often shortcuts
| for specific languages...)
| nmstoker wrote:
| First the needs of the user-base should trump those of the dev.
|
| And secondly the kinds of apps that are referred to here are
| not the type that need massive efficiency or some complex
| feature - when inconvenienced by yet another single-use car
| park payment app, I've never once thought how marvellous it was
| that the text downloaded so much faster than the many web sites
| I regularly use: mainly because that responsiveness is blown
| away by the need to faff about installing the app (not to
| mention the effort needed to avoid giving unnecessary phone
| access out!)
| wiseowise wrote:
| You forgot constant 100MB updates, which are just one page
| refresh on web.
| what wrote:
| And that one page refresh is probably also 100MB these
| days.
| wiseowise wrote:
| Uncompressed - maybe.
| mvladic wrote:
| Obsidian is an Electron app (I don't know if it belongs to the
| Block editor category). It loads just as fast as your app. I
| tried copying and pasting the text file War and Peace (66035
| lines) from Notepad into both apps and, interestingly, Obsidian
| is slightly faster. Also, scrolling through this large chunk of
| text is slightly faster on Obsidian, too. Obsidian memory
| consumption (4 processes) is 172 MB and Daino Notes consumption
| (1 process) is 352.7 MB. Tested on Windows 11 PC.
| rubymamis wrote:
| Obsidian is not a block editor. Can you put a Kanban or any
| other complex block in the middle of a document? From my
| understanding, you can't. Here's how to think of it: a block
| editor is a basically a virtualized list with dynamic
| loading, so it can load any arbitrary component *while*
| allowing the user to interact with the list as it was a
| singular piece of document - so you get text selection
| between these discrete blocks, editing, etc like you would in
| a regular text editor.
|
| Again, from my understanding, Obsidian is not that. If I
| remember correctly it is based on CodeMirror which is
| designed to only handle (EDIT: rich) text.
|
| Edit (addendum): BTW, I'm not sure your Obsidian RAM reading
| is correct, an empty instance of Obsidian with one note uses
| 285MB (all 4 processes together) on my machine (M1).
| mvladic wrote:
| Here is the screenshot showing memory consumption of
| Obsidian (I did wait 30 seconds for memory to settle down
| after initial spike which was 240 MB):
| https://pasteboard.co/uW2lPNSbL7f7.png
|
| [EDIT] Here is memory consumption of Daino Notes:
| https://pasteboard.co/z5pciLoh99i6.png
| rubymamis wrote:
| This is what I get with an *empty* vault:
| https://pasteboard.co/N3IdNUKUUNKq.png
|
| EDIT: Btw, I do have plans to cut RAM usage significantly
| in Daino Notes (I focused more on load time and
| responsiveness). But getting back to my point - I can do
| these optimizations because those RAM inefficiencies are
| a result of my code, not some abstractions I can't
| change.
| maratc wrote:
| > pasting the text file War and Peace (66035 lines)
|
| Funny, but how about a log of one Jenkins run weighting at -
| checking... - 630 MB? Or two of them so someone can compare
| them?
| kebokyo wrote:
| Obsidian is the only Electron app I don't despise.
|
| VSCode is close to counting... but it absolutely sucks on RAM
| usage, so I try to avoid it when I can.
| leptons wrote:
| RAM is cheap, my time is not. VSCode is the best game in
| town (for me), and my 32GB computer has no problem with its
| RAM requirements. Even 8GB would be enough for VSCode
| depending on what else your toolchain requires.
| hnthrowaway2376 wrote:
| > RAM is cheap
|
| RAM is cheap _for you._
|
| It's always silly when people bring up their top-of-the-
| line computer into discussions about performance.
| Software shouldn't be just for the top 1%.
| leptons wrote:
| _Apple_ RAM is expensive. Every other kind of RAM is
| pretty cheap. 32GB DDR4 can be had for under $30, and
| 16GB DDR4 can be had for about $25. I 'm not sure who you
| think has a computer, is developing software, and can't
| afford that. Maybe someone in India, I guess. Too bad if
| that's you, but "top 1%" is a laughable claim when RAM is
| so cheap. 16GB of RAM is nowhere near "top of the line".
| You're just trolling here, "hnthrowaway2376".
|
| Let's say I spent $50 on 32GB of RAM. Over the lifetime
| of the computer that upgrade would cost ~$0.02 per day.
| Two pennies a day. And that's US prices, it can be less
| expensive elsewhere.
|
| I've used VSCode on a computer with _2GB of RAM_ , and it
| worked. I expected everything to run slower - and it did
| run slower, but it ran. And I developed, and contributed
| to the project I was working on while away from my
| workstation. This was a cheap $70 Windows 10 tablet.
| YMMV.
| hnthrowaway2376 wrote:
| > Apple RAM is expensive. Every other kind of RAM is
| pretty cheap. 32GB DDR4 can be had for under $30, and
| 16GB DDR4 can be had for about $25.
|
| I'm sure that's pretty cheap _for you_ , yes. Taxes and
| other fees tend to increase those prices outside the US,
| by the way.
|
| > I'm not sure who you think has a computer, is
| developing software, and can't afford that.
|
| There is a market for lightweight code editors, isn't
| there?
|
| > Too bad if that's you, but "top 1%" is a laughable
| claim when RAM is so cheap.
|
| That was a bit of hyperbole on my part, but let's not
| forget that just being an employed SWE in the US easily
| places you in the top 1% globally.
|
| > I've used VSCode on a computer with 2GB of RAM, and it
| worked. I expected everything to run slower - and it did
| run slower, but it ran. And I developed, and contributed
| to the project I was working on while away from my
| workstation. This was a cheap $70 Windows 10 tablet.
| YMMV.
|
| Fair enough. VSCode is hardly the worst offender though -
| it actually runs quite well for an Electron app.
| leptons wrote:
| > but let's not forget that just being an employed SWE in
| the US easily places you in the top 1% globally.
|
| And not being able to afford $30 as a developer for a
| decent amount of RAM puts you in the bottom 1% of
| developers globally. Yes, I made that up just as you are
| making up your own numbers. But as I explained, you don't
| need 128GB of RAM, you don't need 64GB of RAM, you don't
| even need 8GB of RAM, you can still develop with VSCode
| with 2GB of RAM. Nobody is handing out free RAM, so if
| you need more, save your rupees, or pennies, or euros, or
| whatever. The daily cost of it spread over time is
| miniscule for anyone on the planet, and you will get back
| the investment in saved time.
| pjmlp wrote:
| Not when it is soldered on a mobile phone, tablet or
| laptop, and getting more implies throwing away an
| otherwise perfectly working device.
| ozim wrote:
| Unfortunately no one is making apps for poor people.
| darknavi wrote:
| It's funny that part of the reason computer hardware has gotten
| faster and more efficient is because heavy usage work flows,
| even things like web apps.
|
| So while you think web apps are going "backwards", they've
| likely helped contributed to modern computing hardware speeding
| up your native programs!
| freehorse wrote:
| Is that true, or the reverse? That web apps became a feasible
| thing only after consumer hardware, esp phones, became
| performant enough to handle loads like that (which lead to
| less and less offloading to servers)?
| tanewishly wrote:
| I'd say that web apps became a thing because Google really
| wanted them to be. They first tried with their browser
| plugin. That worked, but adoption wasn't good enough. So
| they ditched Google Gears and started developing a browser
| with sufficient performance for web- native apps. They
| succeeded quite well.
|
| So in my view, browsers became capable, but then plenty of
| "heavy" web apps appeared, which required more beef in the
| machine.
|
| That's also the typical way it goes: current hardware being
| okayish but not great is one of the strongest drivers for
| better hardware. Whether it is gaming (PCs), camera
| (smartphones), the web bloating (both).
| liontwist wrote:
| No. The motivation to make existing flows faster and do more
| of those at once is constant. It wasn't initiated by bloated
| web apps
| cosmic_cheese wrote:
| Native apps also give users a type of control that web apps
| can't, by way of existing as fully independent executables on
| storage in possession of the user.
|
| Web apps can just up and disappear, spontaneously grow
| paywalls, or slowly enshittify over time, and unless both the
| user is technically savvy and the web app is fully open source,
| there's nothing the user can do about it.
|
| In contrast, when a new release of a native app is worse or its
| company goes under, the user retains a useful product (old
| binary) that can be run bordeline indefinitely one way or
| another (hacks, emulation, etc).
| la_fayette wrote:
| Yes, but native Apps have adds, which at least I don't know
| how to block. On Firefox mobile I can just use ublock origin
| to watch YouTube Videos without ads, as one example...
| cosmic_cheese wrote:
| That applies mostly to online-service apps, which are in a
| bit of different category as their usefulness without a
| connection is extremely restricted. Most apps don't need to
| fall into the bucket.
| jkestner wrote:
| Let's normalize offline web apps, then. Your examples at the
| end go back to needing technical chops, and in the end,
| everything gets bitrot.
|
| The biggest problem is with apps that show you content. Web
| sites give the user more control over what content to save,
| better exposure to scrapers and APIs, standard navigation to
| every other web site.
| cosmic_cheese wrote:
| Offline web apps are better but still not great because
| unless their dev has gone out of their way to wrap it in
| Electron, they don't come in nice self-contained units like
| native apps do... for instance, if you're upgrading your
| computer and want to copy over a previously installed but
| now defunct offline PWA, where do you go looking? The
| wrapper binary built by your browser doesn't actually
| contain it, all the inner workings are squirreled away in
| some obscure directory with an inscrutable name.
|
| Websites _can_ give more control but that's hardly a rule
| these days and depends on how the site /webapp in question
| was built. Something built with a canvas-based UI (as is
| sometimes necessary for displaying high volumes of
| information without performance degradation) for example
| isn't going to give the user any better control than a
| native app would, and in some cases less.
| kebokyo wrote:
| I am so happy that you made this, legit. I'm absolutely going
| to try it whenever I get a chance.
|
| I've wanted to do the same thing you did but with coding
| notebooks (e. Jupyter) for a while now. It frustrates me to no
| end that the only native software for notebooks is JetBrains
| IDEA (and even that's only an "I _think_ it's naive" lol).
| Hopefully I can take what you learned and documented and apply
| it to my app ^-^
| rubymamis wrote:
| Very cool! I hope my blog post could be of help. Let me know
| if you need any help my socials are in my HN profile. And let
| me know what you think of my app, would love to hear any
| feedback.
| alternatex wrote:
| This app looks exactly like one I had used in the past. Took me
| a while to find it: https://www.notes-foss.com/
|
| Even the logo is almost identical.
|
| Is this the same project? Looks like two separate GitHub repos
| by the same author. Why two similar projects/websites?
| Multiplayer wrote:
| I was wondering about that too. This is in the article linked
| to https://rubymamistvalove.com/block-editor
|
| 7. The previous version of Daino Notes, called Notes is FOSS
| (free and open-source software) available at
| https://www.notes-foss.com/ and the source code is available
| at https://github.com/nuttyartist/notes. I decided to make
| Daino Notes closed source due to difficulties in monetizing
| FOSS. In order to comply with Notes' MPL license, all common
| files between Notes and Daino Notes are published in
| https://github.com/nuttyartist/daino-notes-public
| rubymamis wrote:
| Hi there! Yes, I will switch to a more distinctive icon in
| the future once I can afford to hire a new designer.
|
| Multiplayer was quoting the correct reason. I also exeplained
| more about the timeline here: https://github.com/nuttyartist/
| notes/issues/690#issuecomment...
|
| Tldr: The FOSS version earned a stable revenue through Google
| Ads placed on the website, since the website ranked high on
| Google searches. Two years ago, that changed since the
| website got de-ranked, so I created a different, proprietary
| version of the app based on the FOSS version but with a
| totally revamped block editor that I wrote from scratch -
| that I worked on full-time for a whole 1 year.
| mckravchyk wrote:
| I am not sure if it's worth it though.
|
| As you have pointed out, QML is buggy. Chromium's rendering
| engine is probably the most stable and polished GUI toolkit
| there is, not to mention a cross-platform one too. Throughout
| the last 10 years I only had to deal with 2 Chromium bugs and
| they were very minor. Well-written JavaScript is fast and the
| machines are getting faster every year. It does not take much
| real time computation to provide a UI for a desktop app, it's
| not a video game. And many of the those things that are real
| time, like the caret in the text editor or hover states are
| implemented in native code by the web browser, with no JS
| interaction. I agree though that a block editor is a little
| more real time than the average UI.
|
| The key word is well-written JavaScript. What is the most
| popular state management framework? Redux, possibly. What is
| the most inefficient state management framework? Also Redux.
| With Redux, if you have an app that displays a timer that
| updates every second, every subscription to any piece of the
| state _throughout the entire app_ will trigger. I 'm not sure
| if the app used Redux, but I used to use a time tracker app
| that would use 30% of my CPU when idle (I since moved to a CLI
| C++ solution and it is so much faster, but that does not mean a
| decent time tracker could not be built with web technologies).
| So if Redux is the most popular framework, you can see just how
| little the average web dev cares about writing apps that are
| not slow resource hogs.
|
| > Also, all web apps couldn't handle loading a very large text
| file (they were all hanging).
|
| Could it be that QT has some optimisation technique to not
| render all those lines out of view? I.e. if you have a huge
| file that can still be loaded to RAM, C++ won't sweat it, but
| is it actually getting all rendered at the same time in a savvy
| implementation, whether at the level of the app or the
| framework? Probably not. On the other hand, the textarea
| element or a contentEditable div just was not made for
| something like this. It could still be developed by
| implementing a custom element / component that loads the text
| dynamically while scrolling. If it's too much for JS to hold,
| it could use WASM or another process and pass it with IPC. It
| is definitely possible to write an Electron-based text editor
| that can open a 1 GB text file efficiently, it's just not out
| of the box experience and most people do not think there's a
| need for such a use case.
| rubymamis wrote:
| Hi there! Indeed, QML is very buggy. But there's also a large
| discrepancy between Chromium's budget (Google) and The Qt
| Company. Also The Qt Company tend to prioritize advancement
| in the embedded world (where it probably gets most of its
| cash) rather than regular applications. So, many bugs get
| fixed through open-source contributors (KDE, individuals,
| etc) And that might be a big reason why non-critical bugs
| don't get prioritize enough.
|
| Like with anything, we're dealing with abstractions. Qt and
| QML are also abstractions. But I'd argue they are better
| abstractions than the web for dynamic semi-complex to complex
| applications (for static sites/simple applications, the web
| is fine). The reason Qt and QML are a great abstractions are
| mainly:
|
| 1. Native modules/APIs - you can always plug in native
| modules into your app as needed. For example, I use native
| Objective-C APIs to draw the window on macOS for my app. It
| just looks better than what you get with just Qt.
|
| 2. Performance - Almost all QML-based components (called Qt
| Quick), are written in fast, compiled language C++, and if
| needed, you can create your own components in C++ and expose
| them via QML.
|
| 3. There are many more reasons, one of them is that I think
| QML is the best declarative UI language I've seen, and it
| plays very nicely with Qt style of C++ (signal and slots
| etc.).
|
| > Could it be that QT has some optimisation technique to not
| render all those lines out of view?
|
| Well, I detailed in my blog post my technique - it's not
| really novel - you can build virtualized lists in many
| languages, including JavaScript. You can look into the source
| code of many web apps that have done the same type of block
| editor that I implemented. MarkText[1] seems to be the most
| efficient one from my testings. My point is that building
| upon the abstractions of the web makes it very hard to write
| truly efficient code that is well-optimized for your computer
| resources. You might be an amazing programmer, but you're
| limited by a certain upper bound of performance, by the mercy
| of the web standards council and web browser engines
| implementation of those standards.
|
| [1] https://github.com/marktext/marktext
| mckravchyk wrote:
| > But there's also a large discrepancy between Chromium's
| budget (Google) and The Qt Company. Also The Qt Company
| tend to prioritize advancement in the embedded world (where
| it probably gets most of its cash) rather than regular
| applications
|
| Yep. That's precisely the point, you get all this stuff
| from a billion dollar project for free.
|
| I really would not mind writing some C++ instead, even if
| it was more difficult. If anything, it would only be better
| because of higher moat of the project as well as my own
| skills. I agree 100% on the principles that native is
| better, faster and JS is an unnecessary layer of
| abstraction slowing things down.
|
| However, if I can compare 2 timelines, one where I am using
| QML for a project, another one where I am using Electron
| and think about the time spent working around bugs,
| reporting bugs and the users of the app complain about
| crashes in the former, or not have any of that at the trade
| off of having something slightly slower, to me it's a no
| brainer.
|
| In the context of what you wrote in the article:
|
| > One of the most frustrating aspects of developing a Qt
| application is the slew of Qt bugs you encounter along the
| way. During ten months of development, I reported seven
| bugs, three of which were assigned 'critical' priority--two
| of which resulted in crashes. I also came across many bugs
| already reported by others that remain unfixed.
|
| I would rather have an app that is slightly slower than one
| that can crash unexpectedly. Even if they are quick to fix
| bugs, new bugs may be introduced in new releases. Your
| intent was to promote QT in your blog post, but
| unfortunately it has only affirmed to me that it's not
| something production-ready (QML on desktop).
|
| That's just the unfortunate state of industry where we are
| at. Hopefully it changes one day. Maybe Chromium could be
| forked into a C++ GUI toolkit where DOM could be
| manipulated directly by C++. Has anyone ever considered
| that?
| rubymamis wrote:
| > I would rather have an app that is slightly slower than
| one that can crash unexpectedly. Even if they are quick
| to fix bugs, new bugs may be introduced in new releases.
| Your intent was to promote QT in your blog post, but
| unfortunately it has only affirmed to me that it's not
| something production-ready (QML on desktop).
|
| Haha, that's interesting. But to be honest, it's really
| not that bad as it seems. Again, crash reports tend to be
| highly prioritized and most of the time you can find your
| way around them until they get fixed. It's indeed a
| frustrating experience when non-crash related bugs aren't
| being prioritized, but then again, like I explain in the
| blog, I could use a different library, probably an open
| source solution like I described using
| QBasicHtmlExporter[1] since QTextDocument toHtml uses
| weird inline HTML (and has some other bugs).
|
| The thing is, with experience I kinda start to have my
| own boilerplate of battle-tested
| components/tools/libraries. I made the following client
| for Ollama[2][3] while not working on it full-time (still
| WIP) in around a month. It already is better than many
| web apps I tried who kept hanging while the model was
| generating a response. Also, try to copy text from a code
| block in web apps while a model is still generating a
| response -> it's almost always impossible since most web
| apps keep re-rendering everything on each completion,
| while I (like the native macOS chatGPT app) do
| incremental parsing which is much more efficient. The
| binary is 28MB (and can be even smaller), the app is fast
| and can handle very large amount of data. So I can build
| QML apps really, really fast these days due to the
| experience I gained and still gaining. I'm also wondering
| if I should open source my components as AGPL and then
| have some commercial licensing for it... Not to mention,
| I rarely use my own heap allocations myself - I try to
| put as much as I can either on the stack or in QML - so
| Qt handles all the heap allocation itself. While I'm
| relying on Qt to do an appropriate job, it seems to be
| very, very stable for now.
|
| [1] https://github.com/Open-App-
| Library/QBasicHtmlExporter
|
| [2] https://rubymamistvalove.com/client.mp4
|
| [3] https://www.get-vox.com
| PaulRobinson wrote:
| A couple of weeks ago I was with a friend who was looking at a
| website for unusual holiday properties and he bemoaned the lack
| of an app. I asked him why bookmarks didn't work for him, and he
| explained it all just got lost - he wanted this to be in the
| "hotels and holidays" section of his phone's home screen. So I
| showed him how to add a website to his home screen (well, sort
| of, I've been iOS since ~2009 and he uses Android, so we had to
| do a little of collaboration to make it work). Mind blown.
| Effusive thanks. He now has a way to bookmark sites that works
| for him.
|
| I'm a big fan of the PWA phenomenon, and got very annoyed with my
| CEO when I was CTO'ing a new platform about 10 years ago, because
| he wanted to move to native apps just so that a loading screen
| looked a little nicer. Ended up using a native shell, did the
| loading screen the way he wanted and then fell back to a WebUI
| view for core functions.
|
| However, there are some areas where I think native wins out,
| primarily the developer experience - I'll take SwiftUI + Swift
| over almost any other UI based developer workflow out there.
|
| WebASM _should_ mean we see a nice little bit of innovation in
| the web app dev experience in the near future, and I keep meaning
| to find time to try Elm out, but at the moment the next app I 'm
| thinking about (which has some tricky low latency UI needs), I'm
| eyeing up native a lot.
| chrisjj wrote:
| > I showed him how to add a website to his home screen
|
| Some sites prevent rhis, diverting you to install their app.
| i_love_retros wrote:
| Apps get access to the device advertising id, can slurp up more
| valuable data from users who don't know better than to install
| it, and are harder to block ads in (average Joe isn't going to
| set up DNS level ad blocking)
|
| It's all about advertising, always, everywhere.
| newusertoday wrote:
| Webapps do not have access to public url's outside their
| domain(CORS). Webapps don't have access to gpu in 2024(there is
| webgpu in chrome but not yet enabled in firefox) Webapps don't
| have access video/audio codecs.(There is webcodecs api but its
| partly enabled and there is no api for muxing/demuxing which
| makes accessing them difficult.) Webapps don't have access to
| other hardware features that are required for ML.
|
| So while i am rooting for webapps it is still long way to go.
| leshokunin wrote:
| One aspect I find fascinating and under estimated is how Apple
| makes the browser kind of secondary to apps. The browser is
| basically a navigator, a renderer of websites.
|
| People don't think of the web as a platform for apps. For them,
| it's like a bunch of pages you get to via Google. They have very
| poor notions of how to navigate or make workflows with it. How
| many people do you know who just have a million tabs open? Who
| have no notion of what web apps to use and mainly use Gmail /
| Slack / Google?
|
| This is why Apple pushes apps so much. A dedicated little place
| for a use case.
|
| PWAs are a good in between for sure. But for a lot of humans,
| having a logo of a brand they recognize is going to be the main
| thing.
|
| "I want a button that says Music, it's Apple Music, I pay it 10
| bucks, I get all the music."
| ANewFormation wrote:
| Are you trying to tell me there are people _without_ a million
| tabs open?
| taminka wrote:
| while i understand the sentiment and having an app for everything
| is annoying, there's a reason ppl prefer app: most web developers
| are either incompetent as hell or don't care and write horrible
| websites, and forcing ppl to make a native app at least ensures
| some basic level of saneness and performance
|
| i think there's maybe two or three popular websites that work
| well on my phone, everything else is unuseable, while apps still
| work okay
| BlueTemplar wrote:
| Please stop making web apps, the web is for documents, not to be
| hijacked by Google in their attempt to wrestle personal computing
| from Microsoft.
|
| This issue becomes even worse if you try to make software that
| can both be used with keyboard & mouse and on a small
| touchscreen. With very few exceptions, you end up with something
| that works poorly with both interfaces, instead of working great
| on one of them. Trying to do that in a browser rather than the OS
| only makes the issue worse (what happens when you press "Alt" ?).
| superkuh wrote:
| Yep. And it gets worse.
|
| Websites are at least supposedly sandboxed so they are not as
| much of a risk as running native binaries. But this is getting
| worse and worse as browsers expose more and more of their host
| operating system's functionality. The benefits of using a
| website instead of a native app are quickly disappearing while
| the drawbacks have only been somewhat mitigated. We're getting
| to the point where browsers are worthy of the decades old
| criticism Emacs has received. They have eventually become an OS
| with many fine features - simply lacking a good web browser.
|
| The browser, and the web, has been destroyed by the insane
| security model of modern OS-Browsers: running every executable
| they're sent from anyone with not a care in the world as if it
| is normal. This one thing has made it so browsers cannot be in
| control of the user, made it so that CA TLS is pretty much
| required and so that browser devs write entirely for the
| security use cases of the insane corporate web applications
| instead of writing for human people looking at website
| documents.
|
| And this same security model makes it so that web apps
| basically cannot communicate with each other at all, unlike
| real applications where piping between small applications is
| the entire idea.
| watermelon0 wrote:
| Mobile operating systems have really good security models,
| and native apps are even more isolated compared to the
| websites.
|
| I really wish that we would have similar isolation options on
| desktop/laptop OSes.
| add-sub-mul-div wrote:
| It would be horrible if we lost desktop computing to a
| scenario where we need permission from one of the tech
| giants before running code.
|
| Those who sacrifice freedom for security deserve neither.
| superkuh wrote:
| You can use Qubes OS (a linux that relies heavily on
| virtualization) if you want that.
| qudat wrote:
| The browser is an operating system. This might be unsettling to
| this crowd but we can't just cover our eyes and hope it turns
| into the browser from 20 years ago.
|
| > Please stop making web apps
|
| No.
|
| > the web is for documents
|
| No it isn't.
| syndicatedjelly wrote:
| I think you're about 25 years late to the conclusion of the
| first war, and 10 years late to the second
| shahzaibmushtaq wrote:
| Users should educate themselves about when to use web apps and
| native apps.
| flax wrote:
| For my game, I do have a web version, but I also have native
| apps, because the web monetization path is just not as smooth as
| native.
|
| I chose Flutter because I like Dart far more than
| TypeScript/JavaScript. AdMob doesn't support web. Of course there
| is a Google Web ads solution, but Google's "significant content"
| evaluator doesn't see any Flutter content, so you have to add a
| bunch of useless text to use web ads. In-app purchases are fairly
| easy compared to getting Stripe set up, and for the user far more
| usable.
|
| I'd LOVE to stop dealing with app stores and the 15% tax, and iOS
| entirely, but it's not a good user experience.
|
| Of course, I could choose not to monetize at all, but I would
| like to get something for my efforts, at least enough to support
| its own running costs.
| parski wrote:
| The web is for hypertext. Simultaneously, lots of apps should be
| App Clips or whatever the Android fragment equivalent is called.
| pacifika wrote:
| The app can be installed only by tapping, but the web app
| requires typing in the url or into a search.
|
| I feel this is difficult for many more people with less motor
| skills, or that can't read.
| sumuyuda wrote:
| Do you not have to search for the app on the app stores? How
| else is the app found?
| dredmorbius wrote:
| Save bookmark to home screen.
| kyriakos wrote:
| I currently have 4 parking apps, and 2 ev charging apps on my
| phone. None of those have a Web version when you can clearly see
| that most of their ui is webview based. They could have been
| bookmarks indeed.
| jbombadil wrote:
| As a consumer, I understand the need of a native app for
| something that is performance intensive or that requires a level
| of OS access that the website doesn't provide.
|
| OTOH, in tired of everyone pushing apps that could easily be a
| website.
|
| I had an xfinity technician aggressively pushing me to install
| their xfi app when they came to install the service. They told me
| it was the only good way to configure the WiFi (!) and that they
| had to check a task in their technician to do list that they
| "walked the consumer through installing the app".
|
| Horrible consumer experience. Between the borderline lies and the
| nefarious push for the app, if I had had any other choice I would
| have rejected the installation on the spot. But alas xfinity was
| literally the only provider that could offer service with any
| decent speed.
| capitainenemo wrote:
| Definitely not necessary for internet service alone. You also
| don't need their modem. Just buy your own. Cheaper in the long
| run and a bit more control over the device. Never had a tech
| push me into installing anything either.
|
| But, I guess if you're paying for one for one of their all-in-
| one packages where the service is managing
| voip/streaming/tv/internet I guess I can see their equipment
| and management tool might be necessary. Wouldn't know, have
| avoided all that. Try to keep them just as an ISP.
| xemdetia wrote:
| It has been crazy since before apps were 'apps.' It is a simple
| flow chart to me: do I need to interact more than once a month?
| No? Should probably be a website. The only time I want an app
| is for things I check more than 50 or so times a day, but that
| is because the UI for phones is awful and it is more convenient
| to context switch. Needless to say I find messaging apps to be
| the only ones that qualify.
| ukoki wrote:
| I don't think it has anything to do with performance. Apps make
| it far easier to advertise to users.
|
| You can send the users a notification even when they aren't
| using the app
|
| It's much harder or impossible for users to block in-app
| advertising
|
| It's easier to track users via apps, and your tracking data
| will be richer, more accurate and therefore more valuable.
|
| Until this changes, we'll get stupid apps that should have been
| websites.
| chrisjj wrote:
| > Apps make it far easier to advertise to users.
|
| And to obstruct users e.g. from screenshotting content such
| as my bank transaction data.
| aeroghi wrote:
| Also, the majority of users are going to _search Google_ for
| the website they want, rather than enter a url directly. An
| app avoids exposing the user to competitor 's ads.
| kevincox wrote:
| Both major app stores have similar ads. I don't see the
| difference. Maybe they could provide a URL and QR code and
| go straight to the site without depending on third parties.
| glitcher wrote:
| This reminds me of aggressive technicians trying to convince me
| to install their bloatware on my computer in order to complete
| setting up internet connectivity 20+ years ago. One was
| completely baffled by my insistence that he was not going to be
| touching my computer, makes me laugh now.
| steelframe wrote:
| > aggressive technicians trying to convince me to install
| their bloatware on my computer
|
| I still remember the look on the tech's face back around 2002
| when he saw a text login prompt on my FreeBSD box.
| GoblinSlayer wrote:
| Android app? Then install amd64 Lineage OS in virtualbox, push
| app there, then restore a snapshot.
| etothet wrote:
| This argument has existed since native apps were first
| introduced. One of the problems I see now is how horrible and
| frankly broken browsing the web can feel, especially on a mobile
| device. With all of the cookie confirmations due to GDPA and
| other ways mobile websites try to engage you (such as popups to
| subscribe to a newsletter or for discounts off your first order),
| some websites become almost unusable on a mobile device. If
| that's the future where native apps don't exist, count me out.
| watermelon0 wrote:
| There is no difference regarding GDPR/newsletter/discount
| popups between website and application. It's up to the owner if
| they want to nag users, and on which platforms.
|
| _(as for the GDPR, consent must explicitly be given in app as
| on the website, if they are doing tracking and sharing the data
| with 3rd parties)_
| summermusic wrote:
| I generally agree, but not for any critical workflow. You can't
| easily archive copies of web software. One day any website you
| rely on could introduce user-hostile regressions or simply
| disappear. Apps in the mobile ecosystem also have this problem,
| but at least you can archive and sideload old APKs on Android
| (for now).
| bdcravens wrote:
| > you can archive and sideload old APKs
|
| Only as long as external dependencies (like APIs) are
| satisfied.
| summermusic wrote:
| Very true, but you can also keep around an old Android phone,
| or even emulate an old AOSP distribution if your really need
| to. Obviously this is not ideal, but if you're trusting your
| hobby or business to an app, it is in your best interest to
| make sure that it doesn't _poof_ out of existence randomly
| before you can upgrade.
| bdcravens wrote:
| I was thinking more about backend APIs managed by the
| company providing the app.
| tannedNerd wrote:
| Cool, but web apps still can't do location tracking in the
| background. So please do tell me how my fitness app should be a
| web app instead?
| bdcravens wrote:
| Does your app still function if the user disables location
| sharing?
| averageRoyalty wrote:
| Regardless of the answer, it's very common for people to wish
| to share their workouts, locations included.
| not_the_fda wrote:
| I'll take a native app over a web app every time.
|
| HTTP was not designed for apps, it was designed for serving HTML.
| We had a decent solution in Java applets and the tech giants
| could play nice so we couldn't have nice things.
|
| The work around has been a huge kludge of crap frameworks of the
| day trying to reinvent the OS and associated API in the browser.
| It sucks all the way down.
|
| Apps are:
|
| More powerful
|
| More efficient
|
| Have better tooling
|
| Have stable APIs
|
| Are easier to debug
| est wrote:
| > a decent solution in Java applets
|
| Uh!
| bdcravens wrote:
| When HTTP was designed, there also weren't any images, CSS, or
| Javascript.
| snakeyjake wrote:
| There was no support for images in the two pre-1.0 versions
| of HTTP.
|
| The two versions written by one man as experiments and used
| by (by reasonable interpretation) absolutely nobody.
|
| HTTP 1.0, the first "real" HTTP did indeed include support
| for images at some point prior to being finalized as RFC
| 1945.
| rpdillon wrote:
| Apps also:
|
| Require devs pay a tithe to the app store owner
|
| Are less able to be customized, reverse-engineered, and
| controlled by the user
|
| Are subject to arbitrary, vague, constantly shifting, opaque
| app store approval rules
|
| Require constant updates just to continue existing, since the
| platforms they target don't care for backwards compatibility,
| and are constantly releasing updates
|
| Are hostile to open source projects that have limited
| resources, as those represent a drain on the system, since they
| generate no revenue
| wiseowise wrote:
| > More powerful
|
| What does it even mean?
|
| > More efficient
|
| Debatable. Depends on implementation.
|
| > Have better tooling
|
| Absolutely no. I'm yet to see any native toolkit that has even
| feature parity and nice DX compared to web development.
|
| > Have stable APIs
|
| Ask Android developers about stable APIs. Also, which web APIs
| do you find unstable?
|
| > Are easier to debug
|
| Debatable.
| guzik wrote:
| I'd give anything to move our apps to the web. We're in the
| medical field (our apps connect to medical devices over
| Bluetooth), so publishing on Google Play is like a Kafkaesque
| fever dream. Two days ago they tell us our app fits into
| categories like:
|
| Activity and Fitness
|
| Nutrition and Weight Management
|
| Sleep Management
|
| Medical Device Apps
|
| So we gotta update our policies, but today they said something
| like: "Actually, jk, you don't qualify as a Medical Device App
| anymore - app update rejected."
|
| Meanwhile, Apple (who used to be the actual nightmare) has
| somehow turned into the reasonable one. They approve apps in
| minutes now. MINUTES.
|
| It's like Google saw Apple's approval process from 10 years ago
| and thought, "Let's do that, but make it a circus." At this
| point, I dream of ditching native apps entirely. Too bad
| Bluetooth on the web is still a bit... fragile.
| fidotron wrote:
| The Google Play update emails kill me with the level of
| irrelevant noise.
|
| "This is an important tax update for [country you didn't think
| existed anymore]." etc.
| Dig1t wrote:
| Good lord this is so true.
|
| I somehow got my personal email associated with the classroom
| Google Play account from back when I was at university, so
| every app uploaded by all students for each new semester I
| get emails for still. Every few months I get a batch of 30+
| emails telling my that my app is not in compliance and it's
| at risk of being removed.
| adastra22 wrote:
| We've wandered off topic, but there should be a safe harbor
| provision if your app has <500 installs or something.
| FredPret wrote:
| The web is just a beautiful publishing platform.
|
| - no permission needed (mostly)
|
| - built-in discoverability
|
| - you get to figure out whatever payment processing you want
|
| - works on every device
|
| - update code in seconds
|
| - no copy protection needed
| frereubu wrote:
| True except the part about "works on every device" is
| dependent on what part of the device you're trying to use, as
| the parent says about Bluetooth.
| Ajedi32 wrote:
| I'm a bit curious about what's wrong with Bluetooth on the
| web. Is it just because Safari and Firefox don't support it
| yet?
| leptons wrote:
| Not just Safari and Firefox, on iOS all browsers are
| forced to use Safari's web view, because Apple wants to
| force developers to write apps so they can make 30%
| revenue from the app should any money exchange hands.
| They can't force developers to write apps if web browsers
| on iOS are allowed to access bluetooth and other modern
| browser APIs.
| aeldidi wrote:
| It's important to note that it's not a matter of effort
| for Firefox. They've decided that the it's not something
| they want to implement[1]. The reasoning is that they
| think it allows low enough level access to potentially
| mess with devices who weren't made to be resilient to
| malicious input, and didn't like that the proposed method
| of allowing web Bluetooth is based on a default allow
| policy with a blocklist, which means as new Bluetooth
| device vulnerabilities are discovered, this blocklist has
| to be maintained.
|
| [1]: https://mozilla.github.io/standards-positions/#web-
| bluetooth
| mdaniel wrote:
| Wouldn't the correct time to raise those concerns be
| during the web bluetooth design process? The idea that a
| browser decides "nah" about a web standard because
| they're mad about it seems like the road to ruin
|
| Then again, almost every time a Firefox thread appears
| here it gets filled with comments pointing out how low
| its adoption is so I guess "well, yeah" sums it up _(he
| said, commenting from Firefox)_
| amelius wrote:
| Their devices should probably just include a different
| interface, such as one based on a secure internet
| connection. Or use bridging hardware.
| dotancohen wrote:
| > works on every device
|
| Assuming that the device has an up-to-date browser available
| for it. And today, that usually requires having a multi-MHz
| multi-core processor and GiBs of memory. No matter how lean
| your actual application/website is.
|
| I have a stack of E-Ink readers, all in terrific condition.
| My favorite is the B&N Nook Glowlight 3. When it was new just
| about five years ago, I could install a web browser on it via
| ADB and it would work reasonably well. Today, all the
| browsers are bloated beyond installable and usable.
| FredPret wrote:
| True, and regrettable; on the other hand, mobile compute is
| getting so much cheaper all the time. This is the driving
| force behind all that bloat.
| Y_Y wrote:
| I feel your pain, though I blame the websites more than the
| browsers. I can run full firefox on my OG pinephone as long
| as the sites I visit aren't running a pile of JS lunacy.
|
| My Onyx Boox runs Firefox happily too, but for that and the
| pinephone I'd recommend trying out a Gemini browser (there
| are several on fdroid). It's lacking plenty, but has an
| old-web feel, no sites are slow, and you can handily use it
| on old devices.
| dotancohen wrote:
| > I feel your pain, though I blame the websites more than
| the browsers.
|
| I blame the standards organizations.
|
| I love the Boox devices as well. My Note Air 2 Plus is
| almost two years old, it is a terrific machine. I'd love
| to know what your use cases are. I mostly use it for
| taking notes and reading - including on the web - but I'm
| rather unhappy with most browsers on it including
| Firefox. For one thing, Firefox on Android has almost no
| keyboard support.
| Y_Y wrote:
| Oh yes, I think the web standards orgs are culpable
| (especially W3C) for not making it fast and simple to
| implement the features PHBs demand. This is surely in
| spite of the good people working on their behalf, and
| more a sad molochian consequence of regulatory capture
| big big adtech.
|
| My Boox Color 7 was originally bought for terminal work
| and I connect it to my bluetooth keyboard and use
| tailscale and termux to make it a nice e-ink "dumb
| terminal". It's also nice for reading books on, and
| downloading said books (though I miss Kindle's email
| transfer method). I did try watching a YouTube video on
| it once, the result was almost watchable and far better
| than expected.
| mattgreenrocks wrote:
| Developing apps on it still seems really, really primitive.
| HTML alone is not sufficient for a decent looking UI.
| Tailwind directives gunk it up rapidly. Component frameworks
| help some but still don't seem quite as nice as something
| like SwiftUI. Server side functionality still requires a lot
| of manual serialization/deserialization (unless you use the
| newer crop of frameworks that have figured out this is pure
| noise).
|
| And then there's JS.
|
| Rails, htmx, and a few others seem like the only ones who
| really get that a simple web app should be 50-100loc.
| leptons wrote:
| >HTML alone is not sufficient for a decent looking UI
|
| Well that's some nonsense. HTML can absolutely achieve 1:1
| on any UI you care to mention. It isn't even difficult if
| you have any skill at all.
|
| >And then there's JS.
|
| And then there's another person who didn't take the time to
| learn JS and just hates it _for reasons_.
|
| >Rails, htmx, and a few others seem like the only ones who
| really get that a simple web app should be 50-100loc
|
| Show me a native app with a polished UI and any useful
| functionality in only 50-100loc.
| high_priest wrote:
| I have learned JS & used it extensively in many projects.
| Including modern SPAs. And I absolutely despise it & wish
| I could use something like recently trendy GO or RUST.
|
| JS has absolutely no rhyme or reason, single threaded
| nature makes it gunk up browsers crazy quickly & the
| insane bloat of "frameworks", which attempt to completely
| replace already great APIs, while working on top of
| them... IS CRAZY!
| leptons wrote:
| >JS has absolutely no rhyme or reason
|
| That's really false. The type coercion matrix does make
| sense for the job it is supposed to accomplish, even if
| you personally don't agree with it for whatever your
| reasons are.
|
| https://media.geeksforgeeks.org/wp-
| content/uploads/advanced-...
|
| If you haven't seen the info presented like this before,
| then I can understand why Javascript might seem "CRAZY"
| after reading so many blog posts by people who like to
| complain for clicks. If you think this chart doesn't have
| any "rhyme or reason", then please explain why.
|
| >single threaded nature makes it gunk up browsers crazy
| quickly
|
| That's one way to look at it. Another way is to learn how
| to work with the system you have, not the system you
| want. Improvements to the system can be slow, and can't
| be breaking changes. This is true about _every system_
| humans have ever devised.
|
| Webworkers are great, you can absolutely do multi-
| threaded Javascript, I've done it, it was easy. If that
| solves the problem in a reasonable amount of time, great,
| if not then I'll probably do it in C and run it from
| Javascript since it's so easy to write the rest of the
| application with Javascript.
|
| Not everything needs maximum performance. For some
| embedded systems I usually write 100% assembly language
| because every byte and clock cycle matters. But I know
| all of this really well, so maybe it seems easy for me.
| When I started with Javascript in Netscape in the early
| 90's, it wasn't as well documented and well supported as
| it is today. _That version of Javascript was a bit rough
| around the edges_. But today? Naaa. It 's easy, it's got
| a huge support system, a lot of progressive enhancements,
| thousands of videos, millions of developers and about a
| billion blog posts on medium.com.
|
| I switch back and forth from C to Javascript and it's a
| great combination. Less context switching, the syntax
| close to 1:1 as far as I'm concerned. But C is a pain in
| the ass in comparison to Javascript, and I know both
| languages extremely well. I've been writing software
| almost 50 years.
|
| >the insane bloat of "frameworks"
|
| I'm using Preact for my embedded IoT front-end and the
| complex web app it compiles is less than 50KB total
| gzipped. _Bloat is a choice, not a requirement._
|
| I have complex front-ends running "at web scale" based on
| jQuery (for business reasons). We decide every byte that
| gets included, and manage to score 100% on all page speed
| tests. No bloat.
|
| >which attempt to completely replace already great APIs,
|
| Citation needed.
|
| > IS CRAZY!
|
| People have been using Javascript successfully for
| decades. Sorry Javascript isn't _your favorite language_
| , but it's not as you describe it either.
| mattgreenrocks wrote:
| > about a billion blog posts on medium.com.
|
| Are you trying to sell JS or not? :)
|
| > When I started with Javascript in Netscape in the early
| 90's, it wasn't as well documented and well supported as
| it is today. That version of Javascript was a bit rough
| around the edges
|
| Best bug I saw there was how it would sometimes
| just...give up on running JS if you held it wrong
| (probably a Netscape thing) and you had to figure out
| why.
|
| > I'm using Preact for my embedded IoT front-end and the
| complex web app it compiles is less than 50KB total
| gzipped. Bloat is a choice, not a requirement.
|
| 50KB sent to the client in total? What UI libraries do
| you use? Happy to try out things; I'm currently a fan of
| Svelte but haven't tried Preact yet.
| leptons wrote:
| I started the project with create-react-app a long time
| ago. I've since updated it to latest versions of webpack
| and switched from React to Preact. It's not using any
| hooks or any modern React conventions, but I don't really
| need it. I've kept it simple, the only two libraries I
| include are preact-easy-state and preact-router.
| Everything else is components I wrote. All images used
| are SVG, I'm using LESS to compile to CSS, and everything
| is bundled into a single HTML file that gets gzipped down
| to about 48KB. I've tweaked the default Webpack configs
| to get exactly the payload I want. This gets compiled
| into my ESP32 firmware and served directly from flash.
| The web app handles all devices configs as well as wifi
| access point config, and it controls all kinds of device
| functions using custom sliders and buttons, etc.
| mattgreenrocks wrote:
| > It isn't even difficult if you have any skill at all.
|
| Very constructive, thank you.
|
| I'm talking about the defaults of HTML. There's no pit of
| success, just lots of div-wrapping and tweaking until
| things fall into place. Compare with SwiftUI, where you
| plop two controls and they're spaced sensibly from one
| another without you doing anything. This was also the
| case in VB6.
|
| > And then there's another person who didn't take the
| time to learn JS and just hates it for reasons.
|
| I've been writing TS for awhile now, it's mostly fine.
| Should've expanded further: npm is a bit of a madhouse,
| and JS culture basically consists of "we shove JS
| everywhere we can and say it is good because it is JS."
|
| > Show me a native app with a polished UI and any useful
| functionality in only 50-100loc.
|
| I'll concede that. At 50-100loc, you can have a decent
| looking native app for a simple task. Presentation layer
| for a webapp blows through that immediately. Some of that
| is accepting the medium as is and learning to work with
| it. Some of it is also the fundamental impedance mismatch
| of the web writ documents/apps.
| leptons wrote:
| >There's no pit of success, just lots of div-wrapping and
| tweaking until things fall into place.
|
| If you don't know what you're doing and plan things out,
| sure that is what you might expect - but that's a choice.
| And that's the same in any language or framework or
| platform. It's possible to write bloated unmaintainable
| UIs outside of JS/HTML.
|
| >npm is a bit of a madhouse, and JS culture basically
| consists of "we shove JS everywhere we can and say it is
| good because it is JS."
|
| Every package manager for every language is a bit of a
| "madhouse". It's the nature of free software. I'm not
| sure why you would expect JS programmers to not want to
| use JS packages, I'm not quite sure how you arrived at
| this sentiment.
|
| >At 50-100loc, you can have a decent looking native app
| for a simple task.
|
| Same with Javascript. You might be surprised what can be
| achieved in a few bytes of Javascript. Ever visit
| dwitter.net ? I think you're also leaving CSS out of the
| equation, which has very powerful styling capabilities.
| 10 or 20 lines of CSS can achieve a lot of UI styling for
| a simple app. The HTML/CSS/JS combination is very
| expressive, extremely powerful and easy to use. Not sure
| how you think it's somehow incapable of UI similar to
| native applications, without bloat, and easy to
| implement. I suppose it depends on your skill level with
| these tools, because I find it extremely easy to do.
| YMMV.
| ipaddr wrote:
| "Tailwind directives gunk it up rapidly"
|
| CSS classes are all of the rage these days.
| hgs3 wrote:
| Isn't some of what you're describing a critique of walled
| garden platforms rather than web vs native? e.g. When I self-
| publish a native desktop app, I can pick the DRM, code
| updater, and payment processor I use.
| Neywiny wrote:
| Looks like at least chromium has web Bluetooth. Could that
| work?
| bdcravens wrote:
| Meetings should be emails
|
| Youtube content should be a blog
|
| React websites should be static with sprinkles of vanilla JS
|
| etc
|
| These are all ideas that in many cases are true, though sometimes
| they aren't, but if you ask the right questions, usually those
| holding the line have a financial incentive.
| ndileas wrote:
| I look at these things as essentially aesthetic preferences.
| There's certainly cases where a certain medium is the
| objectively right one for a task, but there's many others where
| it really just a matter of taste.
| ilrwbwrkhv wrote:
| I actually think of them as more than just an aesthetic
| preference. It is fundamentally about proof of work.
| Something that will become more and more important as we move
| into a post AI world.
|
| Every single piece of art, music, game or any other creative
| piece, has three things to it. One, the actual artifact
| itself of the music, the art and the game. Second is who is
| making it. And the third is how much have they put into it.
|
| This last point I think matters a lot. As producing things
| gets easier and easier, just because almost all of creative
| art is a popularity contest, things will move towards who has
| put in most of their hearts / effort into it.
|
| And that is why still I think we will always remember a
| desktop game such as Stardew Valley but never a web game, no
| matter how good it is. I mean Roblox has been around for a
| while and maybe I can tell you one or two games in their
| entire history, which I even remember.
|
| The same with movies from Netflix which are becoming this
| data oriented, aesthetically pleasing, easy to watch things,
| but none of them are worth remembering. Will Netflix and
| these platforms keep growing and having more and more users?
| Sure.
|
| But therein lies the conundrum. We will have a lot of
| everything. We will own none of it and our lives will grow
| more and more shallow and meaningless.
| ndileas wrote:
| That's a interesting way of thinking of it, but a little
| limited. For most, the proof of work aspect becomes just
| another part of the the status competition. I think I'm a
| little more optimistic about the future.
|
| Also, there's definitely web games (paperclips, kittens)
| and art in every media that are memorable and excellent to
| someone. That's kind of the point that I was making; the
| medium is part of the message, but many things can be
| presented in different ways, and mostly this doesn't
| detract from anyone else.
|
| Fundamentally, I reject your model of art; I personally
| think the actual artifact should be the most important
| part. Anything else shouldn't even be considered as far as
| we're able, even though we are mostly status seeking
| monkeys who pay very close attention to every other
| monkey's status so as to increase our status.
| GoblinSlayer wrote:
| That's monopoly problem. Text retains quality, because it's
| more democratic, and AI can democratize visual art.
| hnthrowaway2376 wrote:
| How does AI democratize visual art? Anyone can pick up a
| pen and draw. Affording all the expensive hardware to
| train AI, on the other hand, is limited to a much smaller
| group of people, unless there's something I'm missing?
| autoexec wrote:
| What web game is as good as Stardew Valley and deserves to
| be just as remembered? Most web games are crap.
|
| That's just an argument about quality though. In the end
| it's quality that matters more than the amount of effort
| expended (which isn't something you can easily quantify or
| confirm). Technology promises to make things easier
| allowing for quality that wouldn't have been practical
| otherwise.
|
| Even when the quality is identical there are times when I
| can appreciate the effort that went into something just
| because the creator choose to make something in the most
| inefficient and painful way possible. That's kind of fun in
| its own way, but it's the exception, not the norm.
|
| As games, music, and other forms of art get easier to
| produce and distribute thanks to technology we'll have more
| to choose from. Having choice will always mean you have a
| lot of sifting through garbage to find things you like, but
| technology can make that easier too. I'd rather have an
| overabundance of options than be forced to select from only
| a few options because creation/distribution is reserved for
| a select few due to cost/difficultly
| deadbabe wrote:
| I actually don't think it's always financial.
|
| I understand better now that by forcing a more complex medium
| you will inherently attract a consumer who has greater
| commitment to your content.
|
| A person getting an email isn't as locked in as a person who is
| attending a zoom meeting. And a person in a zoom meeting isn't
| as locked in as a person forced to physically attend a meeting.
|
| You could make your YouTube channel a blog but now you'll
| mostly attract an audience that has a greater chance of getting
| their attention consumed by something shinier, like another
| YouTube channel.
|
| Therefore, you will always want to deliver a message through
| the most complicated medium that still lets you attract a
| suitable audience. It creates more hooks for people to latch
| onto.
| duxup wrote:
| Do individual consumer web apps get many sales when compared to
| smartphone apps in a store?
| fidotron wrote:
| The problem with web games is monetization. If you look at Poki,
| for example, the most popular games are those that simply drag
| the user into a sort of low level loop where they are not ever
| going to actually fail but also never really succeed, as the aim
| is just to keep them there long enough to show more and more ads.
|
| This makes casino games look almost virtuous because in those the
| possibility that you win and walk away actually exists.
|
| On reflection, since I also experimented and contributed to this
| mess, the whole Facebook game era of web games was the peak,
| because at least those games enabled strengthening connections
| between real people.
| mwest217 wrote:
| Strongly disagree that Facebook games were the peak. To me that
| was classic flash games like nitrome.com
| hahahacorn wrote:
| Agreed but on mobile, the native app still has a marginally nicer
| UX. For apps I use heavily, I appreciate that. (Funnily enough, I
| use the inverse as a means of controlling my screen time. Too
| much YouTube? Delete the app and suffer through using it on
| Safari.)
|
| This is exactly why I'm such a huge fan of Strada. I'm not
| married to Strada as the "best" solution, but it was early on
| trending towards the (seemingly) obvious solution.
| perons wrote:
| One comment that I haven't seen yet and that puts PWA for Games
| in jeopardy: the maximum caching allowed for Safari PWA's (thus
| the whole iOS ecossystem) is only 50mb. Most mid-core / hardcore
| mobile games are bigger than that after downloading remote assets
| when the app loads for the first time, and this means a player of
| a mid-core PWA game would have to redownload a good chunk of the
| assets everytime the game loads.
|
| I could be mistaken though, but I tried looking for how PWA's
| work with caching and it is a whole layer of uncertainties that
| depends on which browser/OS/ecosystem you are in, and if the user
| clears it's browser cache. In the end, it seems like PWA will
| only work reliably when the PWA is super light, and doesn't need
| a lot of caching, so for gaming that would mean only lightweight,
| casual and hypercasual games.
| streptomycin wrote:
| The 50mb limit no longer exists, it's much higher now
| https://bugs.webkit.org/show_bug.cgi?id=198133#c15
|
| Safari will delete your cached data if your app goes unused for
| a little while though. Native apps may do the same thing
| though... at least on Android I get notifications about it
| deleting cached data for native apps I haven't used recently.
| henriquelalves wrote:
| That's nice, thanks for correcting me! Although it's quite a
| nuisance that most PWA info I looked for before posting had
| the old 50mb (mis)information.
| nchmy wrote:
| If the app is added to the home screen, then it is exempted
| from having it's data wiped after 7 days without usage.
|
| https://webkit.org/tracking-prevention/#intelligent-
| tracking...
|
| And good docs on storage quotas on different browsers.
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Storage_API...
|
| I think there's also benefits of using persistent storage
| anderber wrote:
| Safari has always hampered PWAs, and probably for the reason
| that they want you to use the appstore instead ($$$).
| DrBenCarson wrote:
| Is Android dramatically better for PWAs?
| cosmic_cheese wrote:
| It's a bit better but I've still not found any PWAs that
| I'd want to use over a native Android app, if only because
| they're near-universally rough, quirky, and generally
| unpleasant in ways that modern Jetpack Compose apps aren't.
| Rohansi wrote:
| There are fewer walls, yes.
|
| Push notifications from PWAs are another area that is
| unnecessarily limited on iOS. They only work if the user
| has added your PWA to their home screen and Safari doesn't
| support the install prompts available in Chrome and
| similar.
|
| So your users will need to go out of their way to add the
| PWA to their home screen and then they can receive silent
| push notifications because Apple says sound and vibrations
| are only allowed for native apps.
| scarface_74 wrote:
| It came out in the Epic trial that 90% of App Store revenue
| comes from games. Those aren't going to be web apps anyway
| for monetization reasons.
|
| If PWAs are so bad on iOS and great on Android, why do
| companies bother with writing Android apps, web apps for
| computers and iOS apps instead of just telling Android users
| to use the web apps?
| alexpotato wrote:
| One of my kids recently started playing travel basketball and
| being a nerdy, into stats tech dad I wanted to take stats on the
| game.
|
| Instead of downloading an existing app, I decided to see if I
| could write my own web app with the following constraints:
|
| - no frameworks
|
| - just basic javascript
|
| - track multiple stats
|
| - be able to enter stats via phone and only using one hand
|
| - while also holding a 4 year old in my other arm
|
| It was a fun exercise and I actually got it working! It can track
| multiple players, multiple stats and even saves the data to a
| server for later viewing or more analysis.
|
| "You can just build things" also includes fully functional web
| apps using old school technologies to solve your own
| needs/constraints.
| CyberDildonics wrote:
| I don't understand what this has to do with the topic.
| alexpotato wrote:
| The general topic was web apps vs phone apps.
|
| I was pointing out that this applies to apps that you can
| build yourself.
| CyberDildonics wrote:
| This is about apps being easily simple enough to make into
| a web page.
|
| No one is saying a table with javascript can't be done in a
| web page, people have been doing it for 30 years.
| chrisjj wrote:
| Love this:
|
| > Important!! the Windows version might show a false warning, if
| it does, hit More Info and then Run Anyway.
|
| because recognising a _false_ warning is impossible.
| chrisjj wrote:
| > A Unity like environment to create web apps
|
| Spell check needed.
| chrisjj wrote:
| > To create an Audio Asset, you need to import your audio file
| (mp3, wav, ogg, mkv) into your project.
|
| Seriously? You can't have audio except precomputed in a file?
| jeena wrote:
| I'm playing https://www.twilightwars.com it's a turn based game.
| You get a notification once it's your turn. If you don't click on
| the notification but just open the browser, the browser thinks
| you don't want the notifications and stops them. There is no way
| of whitelisting the notifications.
| evanjrowley wrote:
| This reasoning is why I'm keen to try out RomM[0], a ROM library
| manager that has EmulatorJS[1] built in. Rather than having to
| setup emulation on each device where I want to play a simple
| game, I can instead use this combination to do it from any web
| browser on my local network.
|
| [0] https://github.com/rommapp/romm
|
| [1] https://github.com/EmulatorJS/EmulatorJS
| marxisttemp wrote:
| Lol no thanks, not everyone hates beautiful native design
| nox101 wrote:
| I'm also curious about apps vs native. Here on HN it seems people
| often hate on the web "you're the product, not the customer" vs
| native. But, half the websites I visit say "download the
| app!!!!". If all the spying on the web is so great for them but
| they're pushing you to an app, that to me suggests they get more
| spying on the app. Even if the app is just a webview, they get to
| set the policy so no blocking the 950+ companies they're letting
| spy on you. And, even better, the app will require you to login
| in so they can magically get even better data.
|
| It feels like we (the HN crowd?) should be pushing for more web
| (the one place where you can inject more control like ad
| blockers, etc), than native apps (where you have no control)
| yonatan8070 wrote:
| The modern web sucks, with all the tracking, etc.
|
| But it's still a lot better than apps, which give the developer
| more control without (in most cases) any tangible UX benefit.
| Just as an example, Reddit doesn't need to have an app, all
| they do is display text and images, along with some
| interaction, and they especially don't need to lock some
| content behind the app (I recently got a popup when trying to
| view a post saying that "unreviewed content" is only available
| in the app, despite the post clearly loading for a split second
| before the popup).
| rmac wrote:
| email me when y'all are upset enough to actually do something
| about this => e.g., create a newsgroup like app-store across iOS
| and Android using the new api's exposed by apple and google
|
| maceip@sina.com
| apitman wrote:
| > it's time to get back to what the web was always meant to be: a
| universal platform for everyone
|
| That is not what the web was always meant to be. The web is a
| document distribution platform. In its purest form, that should
| mean no bloat, no tracking, no JavaScript period. Browsers should
| be tiny, extremely secure programs.
|
| There's nothing wrong with having a universal app platform that
| embraces important lessons from the web like URIs, the security
| model, WebAssembly, etc, but it should be a separate program.
| idle_zealot wrote:
| That ship appears to have sailed. The more realistic proposal
| would be the converse: a stripped down browser that acts only
| to retrieve and display web pages that are documents, not apps.
| apitman wrote:
| I actually agree. I think that's the best way to achieve what
| I'm talking about. Compatibility with current browsers must
| be maintained for many years. But we split the web into two
| much simpler platforms. One for documents that includes HTML
| and a tiny subset of CSS, and the other that's basically
| WebAssembly + WebGPU and other APIs for networking etc.
|
| 90% of the web can be documents. If you're actually building
| an app use the app platform. People using legacy browsers
| don't need to know the difference, but over time they'll want
| to switch because of the benefits.
| furyofantares wrote:
| I'm working on a little niche puzzle game in Love2D. Well, I'm
| done, I just need to ship it. I currently have web, iOS, and
| Windows builds. I strongly prefer playing the native version.
|
| I'm not sure what I'm going to do about this. I think people will
| have a better experience with the native versions, but won't
| discover that if the web version exists. However there are also
| probably people who would play the web version who wouldn't
| install an app.
|
| Probably most of the attention I can drive to it will come from
| other daily web puzzle games I run. I suppose if that weren't the
| case, I wouldn't bother with the web version (unless I get
| rejected by app stores - which looks somewhat likely at the
| moment.)
| jbverschoor wrote:
| Nope.. HTML should've been just that, hyperlinked text.
|
| Friend should've been forms.
|
| Applications should've been apps.
|
| The thing is that html/http is such a great distribution model
| Devasta wrote:
| Referring to everything as "web" when they mean JavaScript has
| been such a feat of marketing.
|
| I'd rather not have stuff I pay for be websites, thanks. I have
| games from 2005 I can still play today. The flash games from back
| then on the other hand are gone forever.
| debugnik wrote:
| Plenty of flash games got archived in time as .swf files! And
| many can still be played with either Ruffle or the last build
| of the standalone Flash Player Projector (which is still
| available on Internet Archive).
|
| Games nowadays however have so many online-only features and
| content that it's getting much harder to keep them working no
| matter the platform.
| thot_experiment wrote:
| I man don't get me wrong, I love the idea of PWAs but this dude
| is out to lunch. It's so painful making anything complex work
| cross browser/cross platform. On iOS iirc they don't even support
| adding PWAs to the homescreen? You definitely can't Bluetooth
| outside of Chrome (probably only on Android and Windows too
| because nothing fun is ever allowed on Macs).
|
| Multiplayer games you kind of need UDP. You cannot UDP in the
| browser (WebRTC data channels technically use UDP but that stack
| is an abomination wrapped in SCTP and DTLS)
|
| This is by no means an exhaustive list, just issues I've dealt
| with recently. It's _better_ than it was with WebGPU and WASM,
| some of the gap between a native app and a website is
| surmountable, but unless you 're doing something extremely boring
| surmounting the gap is hard fucking work.
| coip wrote:
| I have several PWAs on my home screen on a iPhone that open in
| a window that doesn't appear as a browser.
| tshaddox wrote:
| > On iOS iirc they don't even support adding PWAs to the
| homescreen?
|
| You've been able to add websites to the home screen going back
| at least to the iPhone 5 in 2012. Is it the "PWA" part you're
| questioning? iOS definitely does have PWA support, although
| with a few notable limitations that may be deal-breakers for
| certain apps. Oh, and apparently Apple recently disabled PWAs
| entirely in the EU.
| xeromal wrote:
| One big missing piece is the inability for me to put an
| "Install" button like I can on android. I don't want to have
| to teach old people how to add to desktop
| below43 wrote:
| Yes, even Windows (Edge) prompts to install the PWA on the
| desktop. The "Add to Home Screen" process works well, but
| is obscure.
| Anechoic wrote:
| _Oh, and apparently Apple recently disabled PWAs entirely in
| the EU_
|
| Apple reversed that decision back in March [0] (expand "Why
| don't users in the EU have access to Home Screen web apps?")
|
| [0] https://developer.apple.com/support/dma-and-apps-in-the-
| eu
| moffkalast wrote:
| > The need to remove the capability was informed by the
| complex security and privacy concerns associated with web
| apps to support alternative browser engines that would
| require building a new integration architecture that does
| not currently exist in iOS and iPadOS.
|
| This rationalization makes zero sense, it's just opening a
| standalone browser window from a convenient icon shortcut.
| They could even ignore the manifest.json entirely like
| Android does half the time anyway cause the implementation
| is buggy as all hell.
|
| I think the real reason was some kind of retaliation worthy
| of a baby insanity wolf meme because they were forced to
| stop reskinning Safari for all other browsers on iOS which
| was absolutely ridiculous in the first place.
| brookst wrote:
| Shows why guessing and gut feel are bad basis for
| opinions.
|
| In fact, Apple's problem was that the PWA serviceworker
| runs as root, a bad decision made years ago. Enabling
| Chrome-hosted PWAs means Google gets root on those
| peoples' phones.
|
| We can still lambast Apple and go all ad hom, but let's
| stay factual?
| moffkalast wrote:
| Ok running something like that as root by design is
| enough of a self own from Apple that I really don't need
| to say anything more, hahaha
| andrewflnr wrote:
| Factual ad hom indeed.
| urbandw311er wrote:
| Not doubting you but care to share some links to back
| this up? I'd be interested to read more.
| theK wrote:
| Sounds like something very fixable though. Why is it so
| difficult for apple to fix the "engineering mistake" and
| move the PWA process to a less privileged user or even a
| jail?
| rejhgadellaa wrote:
| Service Workers do not require an installed PWA. Every
| regular website can have a PWA. I'm not sure who came up
| with this explanation for Apple trying to kill PWAs in
| Europe, but it makes zero sense.
| 6510 wrote:
| It is really quite complicated to do. Since you get some
| interesting functionality I had considered it but writing
| the page how to add the website to the home screen I
| couldn't imagine users doing this.
|
| My least favorite dark pattern is that you first have to
| change the share menu and add the option. That way it seems
| less inconvenient to people who've done it before.
|
| To share a fun perspective: Desktop desktops and phone home
| screens are really revolutionary compared to the browser
| bookmark menus and app stores are really web directories
| that are both glamorous and horrible at the same time.
|
| There is sabotage along the way but we are clearly moving
| forwards.
|
| Imagine an AI starting a thread or a sub forum for each
| application it can find online. Then have it gather
| articles about the application and post them as replies or
| topics. Divide everything neatly over categories (like a
| web directory) and have it gather usable icons/logos for
| navigation. By default it only displays software for the
| users platform or browser but a few check boxes in advanced
| search settings can change the selection.
| panic wrote:
| In fact, home-screen web apps on iPhone OS predate third-
| party apps on the platform. Originally all third-party
| software was going to be installed this way.
| madeofpalk wrote:
| > Originally all third-party software was going to be
| installed this way.
|
| It's off topic, but I don't think this was true once the
| HTML Weather and Stocks 'widgets' failed on iOS. Anything
| Apple said publicly was just saving face until their SDK
| was ready for public consumption.
| reaperducer wrote:
| It was true. I developed iPhone OS web apps during that
| time.
| voxic11 wrote:
| WebTransport is now supported in most common browsers (just
| missing safari support) and provides a nice API for
| sending/receiving messages via UDP.
| https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...
| thot_experiment wrote:
| Thanks for pointing this out! I wasn't aware this had more or
| less landed. (though I think my broader point about cross
| platform support unfortunately still stands, I personally
| don't care about supporting iOS on my side projects and I'm
| excited to mess with this)
| chris_pie wrote:
| Support is getting there on the browsers' side, but you
| need a backend that supports HTTP3+WebTransport - barely
| any out there
| thot_experiment wrote:
| Yup, as I have found out over the last 5 hours. I managed
| to get a handshake but it's nowhere near the convenience
| of something like WebSockets. The security circus you
| have to go through to get even a handshake working is
| absolutely absurd, all sorts of extremely poorly
| documented certificate requirements and you'll be lucky
| to get an error message that helps you in any way. I'm
| getting ready to give up for the day, I will definitely
| make a top level HN post if I get a solution working and
| documented.
|
| Meanwhile https://github.com/achingbrain/webtransport-
| echo-server this is the best we have for a minimal
| working node example.
| wruza wrote:
| _I wasn 't aware this had more or less landed._
|
| That's usually a sign nobody uses it because it has at
| least one large issue. Personally I stopped falling for
| "there's now X" advices long ago because if it worked, it
| would already be mainstream very much heard of by everyone.
| Sorry for your five hours.
| thot_experiment wrote:
| I disagree at least a little bit, the fact that there's
| support on the browser side is much much more important
| than support on the server. I can write a server of
| arbitrary complexity given enough time, the scope of the
| problem is now one that I can fix.
|
| I also found the following in my research yesterday,
| which looks like a very promising set of abstractions for
| WebRTC data channels.
|
| https://github.com/geckosio/geckos.io
| pjmlp wrote:
| Most of the time a PWA isn't needed at all, a mobile Web
| friendly website suffices.
| brookst wrote:
| For offline use?
| pjmlp wrote:
| Depends on the application, naturally.
|
| Most of them, even if native don't really work without the
| API based backend.
|
| If we take out the garbage apps, copycats, and games
| without DLCs, most stuff is some variation of form over
| data.
|
| And those that are really special, needing native APIs,
| working offline by default, can probably be reduced to
| about 10% of apps.
| codazoda wrote:
| You can add PWAs to the Home Screen on iOS; Share, Add to Home
| Screen. This is how I build apps to scratch my own itches.
|
| Edit: Err, sorry to pile on. I see others have already
| mentioned this.
| hot_gril wrote:
| iPhones support PWAs on homescreen. However, there's no way to
| trigger the "install the PWA?" prompt. The user has to do it,
| which very few know about, and maybe that's what you were
| thinking of.
| CharlesW wrote:
| I haven't looked at this lately and so don't have a specific
| recommendation, but there are small libraries for helping iOS
| learn how to add PWAs using the standard Share - Add to Home
| Screen mechanism.
|
| https://github.com/khmyznikov/pwa-install (Try on device:
| https://khmyznikov.com/pwa-install/)
| leptons wrote:
| Apple is currently being sued by the DOJ for a variety of
| abusive business practices, including forcing all web browser
| apps on iOS to use the Safari browser engine, which limits the
| usefuleness of all web browsers on iOS, so that developers are
| forced to develop an app which Apple can then take a 30% cut of
| all revenue generated by the app. It's a pure money-grab by
| Apple, and they deserve this legal action against them.
| bdangubic wrote:
| buy android
| acheron wrote:
| Is the only alternative still Google? Yeah I'm good with
| Apple, thanks.
| wat10000 wrote:
| That's all the more reason good regulation is essential. If
| there were a dozen viable competitors then you could just
| step back and let the market decide.
| steelframe wrote:
| Point taken about preferring Apple over Google. I buy Pixel
| phones and immediately install GrapheneOS, which does a
| pretty good job of keeping Google at arms' length. So I
| guess the answer to your question is that there is another
| alternative.
| paxys wrote:
| I can't say about gaming, but a huge chunk of popular apps out
| there are PWAs with a native wrapper. If built well people
| aren't even going to notice.
| lurking_swe wrote:
| oh i notice. But im a picky user. You're probably right that
| _well designed_ apps are indistinguishable to most users.
| segfaltnh wrote:
| I think the part where he calls out airline apps is spot on
| though. They don't need any of that tech.
| brookst wrote:
| As a frequent user of both web and phone airline apps, the
| phone apps are just _nicer_. UI idioms that are appropriate
| for the platform, etc.
| urbandw311er wrote:
| Only if they're designed that way. Many aren't.
| wruza wrote:
| Ready to use (or buy/download) controls in appdev usually
| pack some ui wisdom into themselves for free, borrowing
| most of it from the base system.
|
| Webdev is constant reinvention of a wheel in all sorts of
| wrong ways, with "components" on the same level of ui
| quality.
|
| Many apps are just electron apps or vb-like (x,y,w,h)
| forms slapped together by someone barely familiar with a
| platform IDE. But the rest is absolutely superior to the
| "web".
| debarshri wrote:
| Point the author is trying to make is that there are certain
| usecases you really don't need to deliver it via app, it is
| cheaper and better to serve via web. For eg. The Itaki app
| mentioned in the article.
|
| Of course there are use cases that you mentioned are better
| served via native app. For eg. Apps that need compute or
| location. That's not the argument author is making.
|
| The downside of delivering everything via app is your device
| ends up with app sprawl that eats up the resources.
| Aaargh20318 wrote:
| > On iOS iirc they don't even support adding PWAs to the
| homescreen?
|
| They literally supported this since iPhone OS 1.0 (it wasn't
| even called iOS yet). In fact, it was supposed to be the only
| way to add apps to the iPhone until people complained and
| started jailbreaking to install their own apps. Apple didn't
| release the App Store and the iOS SDK until iPhone OS 2.0
| larusso wrote:
| I don't think parent means the same or maybe he does. On
| chrome and edge on macOS one can choose to install the PWA as
| a native app. It gets an app icon and everything. It's
| similar to a web bookmark on the HomeScreen. But it's a
| sandboxed app. Don't know if this is the exact same behavior
| though. PWAs are also a bit different to normal websites.
| They have a manifest and what not to describe the app in a
| standardized way.
| codetrotter wrote:
| PWAs on iOS get their own local storage, for example. And
| deleting the PWA from your Home Screen will delete its
| data, just like deleting an app would delete the data of
| the app.
|
| I got a basic offline-capable TODO list (the hello world of
| web apps) working as a PWA for my iPhone. Almost all of it
| handed to me by ChatGPT.
|
| https://ctsrc.github.io/todo/
|
| If I exit the PWA, turn off WiFi and open the PWA again,
| the PWA still works.
|
| The only annoying thing is that the way you add a PWA to
| your Home Screen on iOS is too convoluted to realistically
| get most people to do it, if you were to make a PWA that
| you actually wanted people to "install". Although the JS
| solution that someone else posted ITT with a small pop-over
| that explains the steps is pretty near to ok. Certainly
| helps the situation a bit at least.
| nox101 wrote:
| Do you need UDP? I see lots of multiplayer browser games.
| Here's a few
|
| https://browsergames.gg/
|
| Google shows me a bunch of RPGs
|
| https://www.google.com/search?q=browser+based+rpg
|
| FPSes here
|
| https://poki.com/en/shooting
|
| or maybe better a video showing some
|
| https://www.youtube.com/watch?v=9ad5jcXPbNw
|
| I know none of them are Edlin Ring, Skyrim, or Call of Duty.
| One issue with Web games is users's expect them to start
| quickly so no downloading 80gig of assets like 102gig for CoD
| Black Ops 6
| joshribakoff wrote:
| Yes and no. UDP objectively performs better because it
| prioritizes sending relevant (in the context of real time
| application) data rather than retrying no longer relevant
| data (and all the overhead that entails).
| thot_experiment wrote:
| No you don't _need_ UDP to make _a_ game, but for the sorts
| of games that I enjoy playing you need UDP.
| p2detar wrote:
| https://nightpoint.io has been around for a long time, it's a
| fast-paced 2D shooter, uses web sockets and it does quite
| good actually.
|
| I think the same dev created https://battledudes.io later on,
| again based on web sockets. It has/had (haven't played
| recently) a pretty big player community.
| Intermernet wrote:
| I know it was a typo, but I want to play edlin ring. The most
| frustrating text mode adventure ever.
| felbane wrote:
| And its sequel, Vimborne.
| theK wrote:
| Agreed. But I would like to add that there are also numerous UX
| pitfalls that apps fall into that are trivially solvable on the
| web.
|
| Broadly:
|
| - deeplinking (while technically doable it is still a pita to
| set up cross platform and require just way too much engineering
| in the long run)
|
| - branching out UX (it is interesting how many seemingly
| straightforward processes turn out to be better if you can
| branch out into something like a tab)
| j45 wrote:
| WebOS had quietly solved this years ahead of its time.
|
| All apps and the OS are JavaScript based.
|
| The timing of the hardware missed or maybe it could have stuck
| more.
| MattHeard wrote:
| One thing I haven't seen addressed in the post or comments (sorry
| if it's there and I just missed it) is for apps and websites that
| sell non-digital goods to customers.
|
| For returning customers, a customer with an app installed is
| simply going to have a lot less friction to open the installed
| app and place an order than a customer who has to open their
| browser, log in again, and then place the order.
|
| That alone is worth the investment for many companies in making
| an app, even if a minority of customers actually choose to
| install the app and keep it installed.
| la_fayette wrote:
| There are definitely apps, which could be websites, e.g., using
| the coinmarkecap app doesn't make any sense in comparison to the
| website.
|
| But there are many things which cannot be done sufficiently on
| the web, e.g., augmented reality, tracking gps in the background,
| accessing a users calendar or phonebook, Bluetooth, scheduled
| notifications, etc...
|
| In general there is something called app fatigue. Convincing
| somebody to install an app is difficult these days, even if it's
| free... Let's see what the future brings for app development.
| KTibow wrote:
| The web tries to do a lot of things, even some of the stuff you
| named. There's a Bluetooth API in Chrome, server-sent
| notifications via service workers, and some attempts at VR
| support.
| Animats wrote:
| > Thanks to HTML5, WebGL, and WebAssembly, browser games are
| catching up to native ones in ways we couldn't have imagined just
| a few years ago. Meta's Oculus browser already delivers web games
| that rival native apps in performance. And once WebGPU becomes
| standard, the differences will be practically invisible.
|
| If only. Have you tried Google Earth on Firefox lately? You can't
| even zoom in and out any more without waiting many seconds. It's
| CPU bound, not I/O or graphics bound. Anyone know what went wrong
| in there? Is it a deliberate attempt by Google to force people to
| Chrome?
|
| As for games, the browser environment is still rather limited.
| WebGPU is (mostly) single thread. (You can share memory between
| processes, which is something else.) It's a subset of Vulkan -
| one command queue, and no bindless mode. Google proposes to fix
| that around December 2026.
|
| On the other hand, there is absolutely no reason that Uber or
| Waymo needs to have an "app".
| pjmlp wrote:
| Also, after a decade, browser vendors still don't provide any
| usable 3D developer tooling better than SpectorJS.
| debugnik wrote:
| > Is it a deliberate attempt by Google to force people to
| Chrome?
|
| For the last several months, the YouTube player takes me
| several seconds to load on Firefox and freezes on me for a
| couple of seconds every other time I press play/pause...
|
| And changing the user agent fixed it! So I say yes. But I found
| the extensions to do so quite clunky so I gave up.
| Animats wrote:
| > And changing the user agent fixed it!
|
| Send a note about that to the legal team at the Department of
| Justice managing the Google antitrust lawsuit.[1]
|
| [1] https://apnews.com/article/google-search-antitrust-
| case-5911...
| recursive wrote:
| This is really annoying when it happens. Next time it starts,
| I'll definitely try the user agent thing. When loading
| youtube, when this is happening, (and sometimes it doesn't)
| the whole page locks up for a few seconds half-way through
| loading/rendering/hydrating. After that, it seems to do a CSS
| recalc/reflow. While waiting, it's impossible to do anything.
| adastra22 wrote:
| > On the other hand, there is absolutely no reason that Uber or
| Waymo needs to have an "app".
|
| Here's one: I don't give websites my location or the ability to
| interrupt me with notifications. Ever. I've blocked the browser
| from doing this entirely.
|
| I have Uber and Lyft apps installed and granted those
| permissions though.
| ipaddr wrote:
| You could give only them location access then they wouldn't
| be able to see what apps are installed, contacts and family
| photos or listen on the mic.
|
| You are afraid of a browser so you give system access?
| SllX wrote:
| What kind of phone are you running and how old is it? Apps
| don't get any of that other information either unless you
| specifically approve it. If you want to give Uber just
| notifications and just location, you can do that.
| fragmede wrote:
| And even then, it only gets location access while it's
| running (if that's the access that's set). And doesn't
| get to run in the background either (if you say it's not
| allowed to).
| Asmod4n wrote:
| "When it's running" also means when it runs in the
| background, and apps can wake themselves up any time they
| want when you allow them to send you notifications.
| SllX wrote:
| Running location triggers an icon in the UI which puts it
| in a list of apps that have run location recently. An app
| abusing this in the background will eventually cause the
| operating system to ask you "hey, are you okay with
| this?" alongside a map of your current location as your
| phone sees it.
| adastra22 wrote:
| What you describe hasn't been the case for almost a decade.
| On iOS and Android apps need to explicitly request and be
| granted one-by-one permission for all those items.
|
| Which is exactly the problem I'm encountering for web apps
| --typically the browser is granted all those privileges and
| then there is a per-site restriction in place. (1) I don't
| trust this sub-level restriction as much as I do the native
| per-app restrictions, and (2) it's often more difficult to
| configure and stay on top of (e.g. iOS will nag me if an
| app has been using my location in the background, the
| browser will not).
|
| For these reasons, I restrict my browser to NOT be allowed
| access to bluetooth, location information, etc. _Nobody_
| gets to track me through the browser. If a site I use needs
| those capabilities, I install their app.
| urbandw311er wrote:
| Here's an example of how large companies abuse their
| power to push back against these privacy guards.
|
| iOS has the ability to share your photos with an app in a
| special "picker" where you select the pics you want to
| share and then they're sent to the app. The app can't see
| the picker so it only has access to the photos you
| explicitly share.
|
| WhatsApp deliberately ignores this integration path and
| gives you a choice of either manually choosing more
| photos to share each time, then selecting them a second
| time. Or sharing all photos forever, which most users
| will eventually choose because the friction of the first
| one is so massive. It's done cynically and deliberately
| so they can have access to all your photographs. I
| shudder to think for what purpose.
| sgustard wrote:
| Uber is almost the canonical example of something that should
| be an app! I need to do a frequent task, I punch up the app,
| I'm always logged in with my location pinpointed, I get a
| little live-updating widget on my phone with my ride
| location, plus notifications and Apple Pay and so on. When my
| ride's over I'm done with the app. Much more useful than say
| the "Hilton Honors" or "Ann Arbor News" apps which are
| literally website wrappers that I use once a year.
| bloppe wrote:
| literally each of those things is also totally possible and
| easy with a PWA, except maybe the widget.
| lurking_swe wrote:
| which approach would use less battery though? rendering a
| web view is always more expensive than native rendering.
|
| What about older smartphones that may not work well with
| bloated web frontend frameworks?
|
| I agree that most of it is possible but in this case I
| agree with parent, uber makes more sense as a native app.
| bloppe wrote:
| Is there a reason why you think location access is OK for the
| Uber app but not ok for the uber.com website?
| adastra22 wrote:
| That's not what I was saying. Granting the permission to
| uber.com requires granting the permission first to the
| browser, then configuring and trusting the browser's own
| internal per-site restrictions. I don't trust this as much
| as the more fine grained and configurable OS-level
| restrictions.
| urbandw311er wrote:
| Uber are the worst for abusing this kind of stuff and for
| dark UX patterns to get you to subscribe to Uber One. I'm
| repeatedly asked SEVERAL TIMES EVERY TIME I USE THE APP.
| and there is no way to pause or opt out from this
| nagging. They even abuse the push notifications to try
| and sell me stuff as well.
| steelframe wrote:
| > I'm repeatedly asked SEVERAL TIMES EVERY TIME I USE THE
| APP.
|
| You know what doesn't do that? The local cab company when
| I call them to ask for a pick up.
| high_priest wrote:
| I feel like I have much more control over "when" I share my
| location, if permission is granted to "uber app" not "uber
| domain".
|
| All the reasons I come up with, can be easily argued "you
| can do the same thing in a browser". But still, it is not
| the same.
| wat10000 wrote:
| Funny, I blocked notifications from the Uber and Lyft apps
| because they kept spamming me. And the notifications aren't
| all that useful, since I'm actively checking the app whenever
| something time sensitive is happening anyway.
|
| Location is super useful here, of course.
| adastra22 wrote:
| I was referring to lock-screen notifications (time-
| sensitive notifications on iOS?), which are quite useful in
| this context. It was a feature basically designed for apps
| like Uber, and I do t think it's available for web apps.
| serial_dev wrote:
| > Anyone know what went wrong in there?
|
| Knowing, I don't know, could be related though...
|
| Google Earth uses Flutter on web, too, which is in my opinion,
| the platform where Flutter is giving its users the worst
| experience.
|
| Though the root cause of the bug could also be non-Flutter
| related, because in Google Earth's case, Flutter mainly just
| wraps the interesting bits (maps stuff in c++???) with a
| unified UI skin.
|
| And does Google break Firefox all the time on purpose? Good
| question...
|
| https://medium.com/flutter/extreme-ui-adaptability-in-flutte...
| nostromo wrote:
| Yes, Google has adopted lots of dark patterns.
|
| I use YouTube via browser (Safari or Brave) on mobile and it's
| clear they don't care about the mobile web experience at all -
| to the point it seems like they are deliberately trying to
| force you to use the app.
|
| I assume it's because they know the browsers support adblocking
| and limitations on tracking and notifications.
| marxisttemp wrote:
| If you're in the Apple ecosystem, I highly recommend the
| Vinegar extension which replaces the awful custom player with
| a standard HTML5 <video> element
| hot_gril wrote:
| For multiple reasons outside of devs' control, PWAs basically
| don't fly on iPhones. They don't go to all that extra effort of
| packing a webapp into a "native" app just for fun.
| al_borland wrote:
| This was the original plan for the iPhone. The web just needed to
| catch up. But now that everything is app based, it's hard for
| companies to want to give up space on a user's home screen. Web
| apps can be added to the home screen, but it's not the default
| state, like an app is.
| ssz wrote:
| I completely agree with the sentiment of the article but the
| general user behavior is changing. Young people are always asking
| for an app. It's what they're used to. My nephew never even opens
| his web browser on his phone.
| boohoo123 wrote:
| there's even a worse option that his article doesnt include. and
| thats apps that have limited functionality compared to the web
| app. My bank is one of them. Heres your account and here's your
| most recent bank statement. You want to see more bank statements
| or add/remove a auto bill or change your password, you need to go
| to the website for that. What the f** why do you even have an
| app?
| r33b33 wrote:
| No. Websites are more laggy, cookie disclaimers, weird
| dimensions, needless UX, choppy. Apps are almost always way
| smoother.
| purple-leafy wrote:
| And here I am making unportable C projects. Actually, I'm quite
| happy being away from the web, its a pain
| ghjfrdghibt wrote:
| There's a clear agenda with this article. I'm all for website
| wrapping apps being websites again. But I'm definitely sick of
| websites that should be apps. And I'd use a native app any day
| over a bloated website masquerading as an app, especially on
| desktop.
| ToucanLoucan wrote:
| Hard agree on all that.
|
| And to be honest, none of these things solve the actual issue
| which is tons of these apps are software that is built by
| companies who do not build good software, and no framework or
| methodology is going to overcome that fact.
|
| My banking app, Chase, is terrific. It is either native or such
| a well optimized web wrapped one that I can't tell the
| difference, which would be a first-of-kind. It has quirks but
| for every daily driver task I need, it's great. In fact the app
| being so good was actually part of why I decided to pull the
| trigger on changing banks, because my last was anything but.
|
| That said, other apps I use (and websites, for that matter) are
| TRASH on mobile. Slow to load, slow to respond, and make my
| damn phone hot in my hand while I try and use them. And like,
| maybe they'd be better running native code, from a technical
| perspective at least, but that doesn't change that the
| usability is still awful, which is not a technical problem:
| it's a design problem, that probably originated far above the
| heads of any of the developers actually building them.
| prmph wrote:
| Kind of off-topic, but I always wonder why Chase bank's tech
| is so good. I seldom use the app, preferring instead to use
| the website, but no matter which way I interact with Chase,
| they seems to know what they are doing.
|
| This is all the more surprising considering how other other
| banks, let alone other large companies, seem to blunder all
| the time with their services, especially online banking.
|
| I returned to my country Ghana from the US a few years back,
| and more time passes, the more I realize just how valuable my
| account with them is. Never have I felt I needed to visit a
| physical branch for anything. Everything just works. In my
| view, they are arguably the best bank in the world.
| soerxpso wrote:
| > Yet businesses still push native apps as if it's 2010, and
| we're left downloading apps for things that should just work on
| the web.
|
| The app icon acts as free marketing. If it were just a website,
| you wouldn't have a little picture of their logo on your phone to
| be reminded that they exist every now and then. They know that it
| could just be a website (usually it IS just a website, packed
| inside an "app"), but they don't want that for a reason.
| haikuya wrote:
| There's a dichotomy between web and native apps. I don't feel
| like I'm leaving my OS when using an app that's parked on my
| dock. For subscriptions and pricing web is great but even the
| notifications are sub-par to native, I need user retention not
| another tab in my browser.
| simlan wrote:
| Just to add another perspective:
|
| Native apps are sticky. As an example a Webshop has no reason to
| have a native app (likely it is a browser wrapper anyway).
|
| However, being installed puts you right in front of the users
| noses everytime the unlock the phone. Just look at the discounts
| that are offered for installing Native apps or shops that are app
| only to begin with.
| kristianp wrote:
| For many businesses an app also has a web version for those users
| who refuse to install the app. I'm thinking my local supermarket,
| or kmart, they want me to install their app for some reason. I
| suppose it's so they can send me advertising as notifications?
| Many business that aren't "app only" have to have both web app
| and mobiles apps. App development studios love them.
| jongjong wrote:
| I never understood why anyone bothered with native apps. It
| defies reason why consumers would prefer to download some clunky
| app instead of just using it in their mobile browser with no
| strings attached. The main excuse I keep hearing are UI/UX
| differences but web UI/UX is excellent these days, it really
| doesn't offset the huge negative hurdle of having to download an
| untrusted app which takes up your time and uses up space on your
| phone before you can use it. How do consumers even know they will
| like the app before they tried it? Why would they download an app
| they don't know? It makes no sense to me. WTF! The user will only
| ever download the native app if they've been conditioned to
| believe that it's worth their time and disk space. But how do you
| get that conditioning effect going when you're just starting out?
| Massive chicken-and-egg problem.
|
| I think it's probably a remnant of a very successful corporate
| PsyOp. I can see why big tech wants to be able to covertly access
| people's cameras, microphones and location data. In most cases,
| there is literally nothing positive for the consumer. It's a
| story of leveraging user apathy to manufacture consent. Most
| people fell for it. Personally, I hate being forced to download
| native apps when the web version of the app already works
| perfectly.
|
| Sometimes I feel like the push against web tech is partly the
| product of a spiteful group of developers who hate JavaScript
| because they had a bad experience with it back in 2010 and
| they've stubbornly refused to re-evaluate their position in spite
| of the language showing extreme resilience and adaptability.
|
| The HTML + CSS + JavaScript combo is a marvel of software
| engineering. The ECMAScript standard is surely one of the most
| impressive accomplishment that bureaucracy has ever produced. It
| has progressed with both speed and quality, picking the best
| parts of many different languages.
| leeoniya wrote:
| meanwhile, huge shout out to FiiO for their web based eq control
| and firmware updater (via WebHID)
|
| https://fiiocontrol.fiio.com/
| mmis1000 wrote:
| I would if there aren't silly restrictions like rotation lock and
| fullscreen in safari. You can't even make a app that stay at one
| direction properly. And fullscreen is limited to video (without
| any ui control).
|
| Even worse that it limit memory to damn 1gb. So any slightly
| complex operations will CRASH and restart the whole page.
|
| These basically work in any browser except safari (Not even ie
| crash and restart your page so often)
|
| These aren't really fancy features only a few people used. It's
| the bare minimum for anything that is considered "properly
| working"
| ertucetin wrote:
| > WebGPU and web games are said to be catching up to native-level
| performance, and some argue they're already there.
|
| I can't agree with that, sorry. I'm developing 3D games for the
| web, and the limitations are asset size, memory size, and CPU/GPU
| constraints feel like developing games with 2001-era resources.
| The web isn't there yet, and I'm not sure it will be anytime
| soon. There are some impressive apps leveraging the web's fast
| distribution, but 3D games are harder in that regard. You can
| create content-rich, visually appealing 3D games, but then you
| severely limit your audience. I'm considering moving to native
| game development because the web's limitations are daunting.
| steelframe wrote:
| When an app rots you're left completely helpless. When a website
| rots at least you can try with multiple browsers until one of
| them works.
|
| In 2015 Robin Hutcheson partnered with a vendor, ParkSLC, to
| deploy an iOS and Android app that is the only possible way to
| pay for street parking in many areas of downtown SLC. She seemed
| awfully proud of herself in this announcement, bragging about how
| it hasn't really fallen over much in the first few months in the
| field:
|
| https://archive.org/details/Press_Conference_-_ParkSLC_Mobil...
|
| But that's not the bar. For public infrastructure it needs to
| continue to function for the life of the system. So let's fast-
| forward to Kubecon 2024 in SLC. I'm staying with a friend further
| south, so I had to rent a car. I pull up to a restaurant where
| I'm meeting some business partners and park right here:
|
| https://www.google.com/maps/@40.7647761,-111.8938564,3a,75y,...
|
| In a past life there would be a parking meter right there at the
| stall where I could drop in some coins and be on my way. Now
| let's talk about how Robin's fancy new parking system is going
| now that we're in the app-infested future.
|
| It's November in the early evening, so it's not exactly warm and
| cozy. The first problem is that the little blue post you see in
| the Google Streetview back in Oct 2022 isn't there now. So I have
| no idea what the stall number is. Fortunately the blue post for
| the spot behind it is there, and I determine it's counting up
| going north. I guess the stall number is one higher than the one
| behind it, and that's all I have to go with.
|
| I walk up to the super-advanced new fancy kiosk and hit the
| button to turn on the screen. Icons on the screen invite me to
| start tapping away to register. No response. The touchscreen
| functionality is completely broken.
|
| There's a sticker with a QR code and a website, parkslc.com.
| Okay, maybe I'm not being phished here. Better do a quick web
| search to make sure. Yup, ParkSLC appears to be The Thing. So I
| go to parkslc.com to get the link to the app and discover that
| it's only distributed via Google Play. But I'm running GrapheneOS
| because I don't want Google spying on me. So it looks like the
| only way I can park on W Temple in downtown Salt Lake City is to
| allow Google to spy on me?
|
| Great. Well, I do have another dummy account on the phone with a
| sandboxed install of Google Play with a temporary account I
| created just for that user on that phone, so I was able to
| attempt to install the app. It still "phones home" to Google but
| maybe without enough information for Google to determine who I
| am. But at that point I'm greeted with an error like, "This app
| was designed for an older version of Android. Go pound sand."
|
| Great. So this app isn't even being updated, I guess. I wonder if
| other people with newer Android devices are getting this same
| error. Regardless, by then it's been about 7 minutes while I've
| been sitting on a concrete bench in the cold trying to pay to
| park so I can go to my business meeting. So far both the kiosk
| and the app have been dead ends.
|
| My last option, it seems, is to browse to parkslc.com and see if
| there's a way to pay via Firefox. After scrolling around more
| than I should have had to I finally find a "Pay Online" link and
| follow it. It asks me for a phone number, so I punch that in. I
| get an SMS. I have to create a pin. It asks me for a "Zone
| Number." I punch in what I guess it's supposed to me. Then it
| prompts me for my credit card. I start punching that in, but when
| I get to the drop-down menu to select the year of expiration...
| nothing. No response to my taps. No ability to just type in the
| year.
|
| Great. So the website doesn't work with Firefox. Another 3 or 4
| minutes wasted on another dead end. Okay, so I launch Vanadium
| and restart the whole process again. This time around the drop-
| down menu worked, and I was finally able to complete the process,
| after futzing around with a broken kiosk, a broken app, and a
| broken website for 12-13 minutes out in the cold night air of
| Salt Lake City.
|
| As the app-based system she deployed in SLC fell into ruin behind
| her, Robin has since flown on to be the administrator of the
| Federal Motor Carrier Safety Administration. Good for her! I'm
| sure there's blame to be passed around here, as it's in the
| current transportation administration in SLC to maintain the
| system in working order. I just wonder how many spare kiosk
| touchscreens they have lying around from a system built in 2015.
| And I wonder if anyone still has the source code for the app that
| doesn't work with newer versions of Android. Or if there's anyone
| around who can even push an update any more. Obviously Robin
| didn't seem to do enough to ensure the system she deployed would
| end up being robust and reliable public infrastructure just 10
| short years down the road.
|
| And not to pick on Robin too much, this is endemic in our
| institutions everywhere. As an industry we need to do much, much
| better. One lesson from my anecdote is that there should always
| be a website, and it should be as simple and compatible as
| possible, especially if it serves as public infrastructure.
___________________________________________________________________
(page generated 2025-01-01 23:02 UTC)