Show HN: Red Goose – Convert your website to mobile app
There was a discussion on HN a few weeks ago about how a developer shaved off almost half of their native app's code without losing functionality [1]. Our launch today is a direct outcome of that thread and, moreso, in the context of this comment [2] and this one [3]. Paraphrasing the context below:
> "Fastmail is the only email/calendar app with a reasonable size (just 20MB)."
Followed by:
> "… EDIT: just realized the app is a web view. Sigh."
As someone who has been into mobile app development since 2010, the comments above read like a punch to the gut. We grew up believing that the native experience was better than the web!
It took a while to admit, but the web, it appears, has genuinely caught on. It has matured to a point where the four pillars of web development—HTML, CSS, JavaScript, and WebAssembly—are likely enough for universal distribution.
We already host compute-heavy environments for graphic designers [4], video editors [5], and rich document editing [6] on the web. And there is still more capability [7] in the works, if you will.
So the question we asked ourselves was: Could the modern web become the "native stack" of mobile app development?
With Red Goose, we want developers to be able to do just that. Create web applications that double up as mobile apps for the app stores. But this isn't always easy. Historically, native mobile apps have differed from (outdone?) the mobile web in three broad ways:
An app-specific design language, Smooth and fancy screen transitions and, Solving compute-heavy processes that scaled to millions of users.
However, at the same time, building and maintaining native mobile apps is super expensive, and it requires hiring separate teams of experienced developers whose sole job is to focus on mobile APIs.
Even with the newest alternatives like React Native, Flutter, Cordova, Xamarin, Ionic, or any other similar framework, there is a quantum increase in the amount of boilerplate code. Over time, as many of us have experienced in the industry, the web and native teams grow distant, leading to a less than optimum situation and bloat.
Red Goose puts the webview back in the ring. This step alone removes all the duplicated code from the equation. Red Goose then offers an alternate strategy [8], using the webview as the main leverage over your web app. And solve for native experience in the following three ways:
First—Intrinsic Design: we have built a new css framework called Toucaan [9] to tackle the gaps between mobile app design and mobile web. It allows the development of "app-like" interfaces using new css standards and the intrinsic qualities of the medium.
Second—Screen Transitions and Animations: Not all apps need this, but smooth transitions and performant animations are already possible with the new web APIs. With a strongly cached webpage using a service worker (PWA) and a better understanding of initial containing blocks (ICBs) pertaining to your front end, one can easily take steps to take the experience to the next level.
Third—Webassembly: The best thing about webassembly is that the wasm functions return immediately and synchronously. So one can easily offload compute-heavy transactions to a locally installed wasm utility and benefit from performance gains instantly on both web and mobile apps.
It appears that many apps wouldn't need to sprinkle webassembly into the mix to reach the level of performance expected of mobile apps, and just caching with a service worker and an app-like layout would do the trick.
Red Goose itself uses vanilla javascript and an experimental version of Toucaan for its frontend. Its backend is made with Node.js, Express, and MongoDB...
87 comments
[ 7.4 ms ] story [ 488 ms ] thread1. Is a new CSS framework really necessary? Smooth transitions have existed for a long time, it's unclear to me what is meant by "new css standards" and "take steps to take the experience to the next level". Corollary: can an existing webapp use Red Goose right away or does it need to be recoded?
2. There's this rumor that Apple fights webapps disguised as native apps with fury; yet Cordova & Ionic exist and prosper; what's true and what isn't, and what's your take on this? Is a Red Goose app at risk of being jacked from the appstore down the road for the sole reason that it's a web view?
1. We gravitated towards a new css framework following some initial work with existing web apps that were responsively designed. While some well-designed responsive web apps might make it to a level where they genuinely feel like mobile apps, we figured most websites reduce responsiveness to the idea of just shrinking the desktop UI to fit the handheld format. That isn't enough and those are the folks who are going to need the new CSS framework.
And yes, one would have to recode their website or plan a separate stylesheet for app-in-webview using parts of Toucaan.
2. I agree that Apple has fought the web and the web standards for a long time, but they do not reject wrapped web apps that meet their app store guidelines. Besides, it doesn't have to be a pure web-view if that is what it takes to get your app through the door. I'd say much of this depends on case to case basis, and it is in the interest of every business owner to go in with the cheapest web-view option first.
A Red Goose app is a web-view, but it also a starter app in Swift and Kotlin. So you can choose to get into native development should there be a need to. And get the best of both the worlds. I don't know, the likelihood of Apple booting the entire web-view based ecosystem from the app stores is fairly low. Even their Safari is a web-view based app. :-)
Apple launched iOS with first class HTML5 apps downloadable to home screen to run offline, and continues to support those, adding capability and access to native APIs with every release while striving to maintain security.
If Xbox Cloud Gaming can run on iPad/iPhone as a web app outside the app store, so probably can yours.
// What Apple does not like is when you take what is effectively an HTML5 app and pretend it's a native app. And anyway, why do that? For all the whining about Apple's app store not being worth it, almost nobody wants to distribute outside of it even when they can. They value the discovery too much, just don't want to pay for it.
Edit: Yes, application seems down/hugged. Getting 504 from their nginx.
It is
With the transition to web apps, we have lost some excellent quality standards, integration, and availablity. 10 years ago you could have productively used your computer and software without ever needing to touch an internet connection. Nowadays it's either: - the browser is the portal to everything - apps are just slow, unresponsive, ugly looking WebViews
It's sad that the bar is so low these days that VSCode is considered acceptable. That takes 30 seconds to start up on my i5-8250U with MX150 graphics.
Notepad++ launches instantly on a 10 year old 32 bit computer with a *low end CPU.
Not criticizing your service btw, I'm sure it's well developed. I hate the general concept at the base tho.
Have you considered that your computer is the problem? I am running a dual-core MacBook Pro that usually hosts a docker-compose file running Postgres and Mongo, a few NodeJS services, and a React hot-reload server, and I can open a fresh or additional VSCode window in 5s.
Or on my i7-6700k/1070 I was pulling it up within 2s
I don't disagree with the idea you express about the internet connection though - it's frustrating to find all the things that should be locally cached and aren't, and all the places offline-first tech isn't applied that it would be beneficial.
Fortunately airplanes have more and more wifi these days...
I wouldn't say so, Elementary OS's built in code editor takes a few seconds at most to open a file
Then again, Electron is really slow (among other things), but anyways, regardless of the toolkit you're using, your app is still an overly complex .html page, doing things the DOM was never meant to do or programmed for, e.g. DOM traversal becomes slow. (Unless you use something like React Native, which is 'truly native', but mobile only)
Honestly the idea of web apps sounds a whole lot like trying to make a video editor app in MS Word
I mean, maybe it was true when browsers were hypertext-only applications, but now they are performant app-delivery toolkits.
Native might get higher performance, but at a fairly steep cost of coupling and distribution difficulty. I can deliver insanely powerful apps to many OSs and form factors on a 512kB bundle, meanwhile native mobile apps come in at 60-500MB for 1 platform. It's also not really that hard to have smooth 60fps display on big datasets & visualizations, which means I contest what "slow" really means for DOM traversal.
Seems to me like you're hell bent on discounting this one platform instead of arguing the tradeoffs are not worth it, which is a shallow take from my view.
And, I agree with you that today Electron apps are a worse user-experience a lot of the times. But just brushing off anything made with web technologies because “it wasn’t designed for this” feels very shortsighted in my opinion.
That's more of an ideological reason for me. But even setting that aside, you can't ignore the practical downsides I listed
> The fact of the matter is that web technologies are the best tool for the job
As a former app developer, I can assure you that creating truly native apps with the OS's toolkit has been way easier than any web application framework I have ever used, ever.
For example, here are some side projects I built for Windows:
- a web browser, but kind of forgot about it - a web page editor with live HTML preview, finished but never really released it
On the other hand, it took me hours to get started making a simple react project (setting up the project, styling it, making the basic navigation components), and never finished it.
Sure, my experience is no empirical evidence of anything. But it seems to be a common misconception that building with web technologies is easier than native toolkits.
I understand that the main problem is having to write everything from scratch for every platform, assuming you're not targeting a specific one (then you should definitely go native).
But trust me, outside the Windows world the app dev's life is a lot easier (see GTK, Qt, etc. that work on any OS as long as the DE implements it)
For more complex projects porting is often an option, and for those cases I still think cross platform TKs are much better than web apps. And you usually don't need a web version if the software works natively everywhere possible.
20 years ago a Windows program was enough (guess why Visual Basic was so popular?).
There's also a flip-side to the equation, the web-platform is damn capable thanks to the relentless pacing (both in features and JIT improvements in JS engines) after IE died off and catching up to it is becoming harder every day.
Looking today the only real choices for cross-platform dev seems to be: WebView, React Native (using Expo is a damn smooth experience almost to the level of webviews) and finally Xamarin/C#. (Yeah, I'm aware of Dart/Flutter but isn't it already long overdue to be killed by Google?)
Alright, so it works for you, but not GP. That still means that it's poorly optimized.
> even if I had monster computer "instant vs 30 seconds" wouldn't be irrelevant
You're stating the negation without providing any argument, so I guess I should explicitly clarify why it's irrelevant: because the topic of this thread is about medium-to-low-end machines, and not about high-spec ones.
To be even more clear, the difference between "instant" and "30 seconds" is categorical in almost every situation, let alone the specific context of interactive software tools.
I am happily creating great offline experiences with static html apps embedded into every platform I want. (pc, ios, android, xbox)
All with the exact same code base.
A browser not implies online connectivity.
Point is: just because it’s native, doesn’t mean it’s well-designed.
Optimizing for startup time probably doesn't end up being much of a gain, better to make sure the experience stays solid once it's already running, and for long periods of time.
And then users wanted collaboration features, weren't keeping their software up to date (so it had to be done for them), wanted to share their data across their device on the cloud, etc, etc.
Microsoft Word still exists but somehow lots of people prefer using Google Docs because it has those cool features.
I never had a problem with the former, and appreciate their capabilities. Many cloud apps are also web apps, but not necessarily (see Sketch)
I run VSCode (on Linux) on a number of different low- to mid-end machines between a 5 and 10 years old and it starts within 2-3 seconds on all of them. New windows/tabs open basically instantly. I ran it once on a Raspberry Pi just for fun and even then it was entirely bearable.
I can only imagine you are loading a bunch of extensions, or maybe one or two extremely heavy ones. It's never anywhere near as snappy as plain Vim, of course. And I am not easy to please nor a fan of Electron apps in general but VSCode has been fairly tolerable for me over the years.
Anyway, agree with the author. Everytime I use web- or electron-app I'm just expecting sluggishness, ugliness and weird behaviors and refresh the page (=restart the app) all the time. It's just a norm. I guess no matter how people pretend that typesetting engine from 80-s is a good UI stack, they still have to pay huge price in usability, performance and orders of magnitude higher memory usage.
For me, with Code completely exited (i.e., not in the dock at all), it takes about 1 second to start drawing and about 4 or 5 to finish rendering all the icons and such and be fully usable. Even IntelliJ (now THAT's slow) only takes about 6 or 7 seconds to fully load. On a M1 too.
Do you have some weird antivirus or similar scanning all your apps...?
No, I don't have any antivirus, and generally very concerned about what's running in the background (I delete apps from LaunchAgents dir, avoid keeping hungry Electron apps in the background unless really needed, etc).
It's never taken more than a few seconds to load... whether on M1 or x86 Macs or Windows. How weird.
Meanwhile, NeoVim is consistently starting under 500ms for me, even being heavy loaded with plugins and offering all the same functionality (NeoVim is pretty awesome as an IDE these days).
(Not criticizing your effort. Red Goose isn’t the problem.)
I haven’t actually looked at your framework or the dependency chain. It’s more of a joke
I built Joystick to be fairly lightweight on the dependency side (for the exact frustration your joke is pointing at). The core stuff is using long-term stable dependencies. Anything else I built directly into the framework by hand so it would last long-term and not turn into the goose chase that is the JS world.
I refer to it as the "Honda Civic of JavaScript frameworks" for that very reason.
Currently when developing webView for iOS, you need to store the session before app is closed and reload it the next time so that user doesn't have to log in again.
That's what I said, by default it doesn't retain session, you need to use some way or the other to do it.
I can see a really strong prop at replatform to say hey just build a PWA with this and for phase 2 click this button and it's in the app store. That plays nicely with all the composable stuff going on and the want to not have 20 systems that do 20 different, overlapping things.
In ecommerce, there's a few people that have built headless/composable 'low-code' PWA offerings and I haven't really seen anything I think will win the lower end of the market as all that matures, but I'm confident SOMEONE will appear to mop that up in the near future.
https://goose.red/fomo
Error: Not Found at exports.notFound (/var/www/red.goose/handlers/errorHandlers.js:21:17) at Layer.handle [as handle_request] (/var/www/red.goose/node_modules/express/lib/router/layer.js:95:5) at trim_prefix (/var/www/red.goose/node_modules/express/lib/router/index.js:323:13) at /var/www/red.goose/node_modules/express/lib/router/index.js:284:7 at Function.process_params (/var/www/red.goose/node_modules/express/lib/router/index.js:341:12) at next (/var/www/red.goose/node_modules/express/lib/router/index.js:275:10) at /var/www/red.goose/node_modules/express/lib/router/index.js:641:15 at next (/var/www/red.goose/node_modules/express/lib/router/index.js:260:14) at Function.handle (/var/www/red.goose/node_modules/express/lib/router/index.js:174:3) at router (/var/www/red.goose/node_modules/express/lib/router/index.js:47:12)
Doesn't really inspire much confidence, does it?
Honestly I'm impressed they are asking money for this product. I see literally no advantage whatsoever of this over competitors (which are open source and free).
https://postimg.cc/gn3X2K1W
Not even sure how that's possible.
I’m trying to be positive here, but your post sends off an incredible odd vibe. You drop names of successful web companies and make it sound like you just invented "mobile apps based on WebViews", which is a thing since, well forever.
Also, you claim Ionic comes with a lot of boilerplate, which is simply not true. Ionic 6 is web-components only with zero overhead. You can use them in vanilla JS no problem.
I don’t see what this brings to the table.
I think you are drastically over estimating your value add.
Progressive Web Apps bypass the need for tools like this BUT Apple's support of PWAs has been suboptimal (hobbling). Of course, you can't get a PWA on the app store (or Google Play store?), but you can get it on your home screen.
If your site is fairly simple and you just don't want to deal with the app store, a PWA may be a decent solution for you. They're not hard to make.
https://news.ycombinator.com/item?id=9487941