[HN Gopher] Show HN: Red Goose - Convert your website to mobile app
___________________________________________________________________
Show HN: Red Goose - Convert your website to mobile app
Hi HN! We're Sonica, Marvin, and Satie, and we are building Red
Goose (https://goose.red). Red Goose is a web app to mobile app
conversion engine that produces ready-to-publish apps for the app
stores using GitHub repos. 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
and is hosted on AWS within Docker. Our web-to-mobile app
conversion pipeline uses NodeGit for app delivery, and the freshly
minted mobile apps are written in Swift or Kotlin and shared
directly over GitHub. We believe that the opportunity to reduce
app development and distribution cost using the newfangled powers
of the web is massive--we've already helped a few teams to cut back
on their expenses by as much as 80%. At the same time, we're still
early and would love to hear what you think about what we're
building with Red Goose. We look forward to your comments and
experiences, especially if you have been on this path before on
your own. Thanks! Relevant links: HN Discussion: [1]
https://news.ycombinator.com/item?id=30442529 [2]
https://news.ycombinator.com/item?id=30443310 [3]
https://news.ycombinator.com/item?id=30444202 Leading web
examples: [4] https://www.figma.com/blog/webassembly-cut-figmas-
load-time-... [5] https://web.dev/clipchamp/ [6]
https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
[7] https://developer.chrome.com/blog/fugu-status/ Tooling: [8]
https://www.toucaan.com/blog/mobile-apps-with-red-goose [9]
https://toucaan.com The end.
Author : satie
Score : 76 points
Date : 2022-09-30 10:28 UTC (12 hours ago)
| danpalmer wrote:
| Do you have any example app repos?
|
| As an engineer, I'd probably want to see what the generated code
| looks like before paying. I'm also probably not the target
| market, but as someone who is regularly asked by non-engineers
| for tech advice about websites and apps, it would be great to be
| able to recommend with confidence.
| wazoox wrote:
| On the https://goose.red/pricing page, it tells me that " Your
| app is expected to be ready by 04:05PM today." But it's 17:55
| where I am, what does it means exactly? Is this server time? Will
| I get my app in 10 minutes, 70 minutes, tomorrow afternoon?
| teddy85 wrote:
| Website doesn't have any CSS on Android after 2 secs?
| turnsout wrote:
| Honest question, but what is the advantage of having your website
| as an app? Isn't it easier for people to just go to the mobile
| site if it's exactly the same?
| bilalq wrote:
| Distribution and discoverability are big factors. You may have
| built a great webapp for managing a todo list, but you'll never
| be found by the people who just open the app store on their
| phone and search for "Todo list" there.
| turnsout wrote:
| Another honest question: is App Store SEO easier than Google
| SEO?
| memorable wrote:
| Yes, but some people prefer to have a website as a mobile app,
| because it's then more convinient to access and to use. Mobile
| apps of a website can also be easily optimized to suit for
| using on a phone, compared to using the mobile version of a
| website (take Gmail for example).
| rglover wrote:
| Do you have any docs for how an app would talk to native/OS-level
| functionality? I saw push notifications mentioned in the order
| form...would that just use the web notifications API?
| xigoi wrote:
| What's the advantage of a webview app over a bookmark?
| manmal wrote:
| I'm surprised to see the claim that the App Store approval rate
| is high for this sort of app. From the review guidelines:
|
| > 4.2 Minimum Functionality
|
| > Your app should include features, content, and UI that elevate
| it beyond a repackaged website. If your app is not particularly
| useful, unique, or "app-like," it doesn't belong on the App
| Store. If your App doesn't provide some sort of lasting
| entertainment value or adequate utility, it may not be accepted.
| robalfonso wrote:
| I have to think that in this case they mean "website" in the
| historical form as content vs "app-like" meaning like a web
| application. If you already have a web application and it works
| well on mobile, what more could they expect really?
|
| If you are local news site, then this probably is going to be
| an issue. If your app allows someone to track how many package
| deliveries they have, then it likely already in a format they
| are happy with.
| numlock86 wrote:
| Hug of death?
|
| Edit: Yes, application seems down/hugged. Getting 504 from their
| nginx.
| satie wrote:
| Ha! Back up now.
| pwillia7 wrote:
| Your tools sound like a really good base for a PWA framework too
| -- have you considered that? I know there are 1 zillion web/ecomm
| agencies of all sizes that know they need to push into
| PWA/headless in the next ~5 years and only those with strong tech
| chops can really do that well and without risk today.
|
| 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.
| marvindanig wrote:
| wow. that's a great insight! indeed, pushing the PWA adoption
| forward is one of the main goals of Red Goose and its sub-
| tooling.
| [deleted]
| andybak wrote:
| Completely broken for me in Firefox. Tried disabling uBlock.
| thrownaway561 wrote:
| Good luck with it... I put in my site and it didn't give me a
| preview, but wanted me to pay the $189 anyways. I'm not going to
| pay for something I can see. Honestly... instead of a preview,
| you might want just want to pull up the rendered mobile app in a
| simulator from browserstack or something so the customer can
| actually interact with it. Having people pay for something only
| to ask for refunds later is going to kill your credit rating.
| satie wrote:
| Sorry to hear that. Please send me your website's address to
| s@goose.red and I will take a look at what's happening.
| StuckDuck wrote:
| > 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 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.
| carlosdp wrote:
| You're totally right about startup times with apps like VSCode,
| but there's a reason that never gets worked on really: the most
| active users startup those pro apps (VSCode, Photoshop, etc.)
| and _simply don 't close them_.
|
| 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.
| FinalBriefing wrote:
| Agreed. I do like how it shows the impact that each extension
| has on startup time, but memory is the real issue I care
| about.
| LunaSea wrote:
| > 10 years ago you could have productively used your computer
| and software without ever needing to touch an internet
| connection
|
| 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.
| StuckDuck wrote:
| I never did.
| LunaSea wrote:
| But a lot did.
|
| Microsoft Word still exists but somehow lots of people
| prefer using Google Docs because it has those cool
| features.
| nawgz wrote:
| > 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.
|
| 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...
| StuckDuck wrote:
| > Have you considered that your computer is the problem?
|
| 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
| nawgz wrote:
| > your app is still an overly complex .html page, doing
| things the DOM was never meant to do or programmed for
|
| 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.
| MatthiasPortzel wrote:
| Arguing that web technologies weren't originally intended
| to be used to develop apps is completely orthogonal to the
| discussion. The fact of the matter is that web technologies
| are the best tool for the job. They're one of the only
| tools that allow you to build an identical cross-platform
| application; not to mention the host of other advantages,
| like code-sharing with a website, an extensive JS
| ecosystem, (in the case of a PWA) fully sandboxed, etc.
|
| 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.
| StuckDuck wrote:
| > 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.
| agloeregrets wrote:
| I would note that VSCode is instantaneous on my M1 Pro..but
| yeah.
| whizzter wrote:
| The blame is on the mobile vendors (and desktop platform
| vendors) just trying to "out-innovate" each other (also
| building propietary security/signing solutions) with their
| propietary stacks (SwiftUI/ObjC, Java/Kotlin, C#,etc) at the
| same time as there's been an explosion of apps/services that
| just needs basic functionality. The budgets/manpower isn't
| there to support everything... apart from if it's just a
| webview.
|
| 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?)
| bityard wrote:
| > That takes 30 seconds to start up on my i5-8250U
|
| 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.
| divan wrote:
| On my Apple M1 it takes ~33 seconds for cold-start. I use
| only vim and flutter extention. That said, my biggest
| complaint is that on this _extremely_ fast computer, the lag
| between a keypress and a symbol is too big. I 'm typing
| faster than VSCode renders characters. With vim mode enabled
| it sometimes goes super slow, with 1-2 sec between characters
| (but that's not always).
|
| 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.
| _nhh wrote:
| See, this is where the misconception comes from.
|
| 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.
| WA wrote:
| Same here. My offline-first Capacitor/Ionic app feels a lot
| more snappy than the native competitor, which requires an
| internet connection and has a lag of a second when saving a
| data item.
|
| Point is: just because it's native, doesn't mean it's well-
| designed.
| wooque wrote:
| VS Code is not slow, it launches in second or two, you probably
| installed bunch of shitty extensions that slowed Code to crawl.
| Kiro wrote:
| VSCode launches instantly for me.
| ugjka wrote:
| Yes, it launches instantly, but depending on the dev env and
| plugins you have it may take a while before it is fully
| usable
| antihero wrote:
| Yeah but Notepad++ as far as I know doesn't even have the
| level of functionality that those plugins provide?
| StuckDuck wrote:
| Yes and loads more. I don't use notepad++ on the daily
| but it is a far superior experience than whatever VSCode
| gave me
| chasd00 wrote:
| Launch time doesn't matter. The only time I launch vscode is
| when I have to reboot to apply updates. Even that is getting
| more and more rare.
| _Algernon_ wrote:
| I wouldn't call it _instant_ , but it takes roughly 1s for
| me. That's acceptable in my eyes.
| throw10920 wrote:
| Do you have the same system (or strictly lower-spec) than GP?
| If not, your comment is irrevelant.
| aabajian wrote:
| I put my website in and all it says is, " Is that site live yet?"
| satie wrote:
| Sorry to hear that. Please send me your website's address on
| s@goose.red and I will take a look at what's happening.
| gukov wrote:
| This wouldn't get past the app store review stage, would it (no
| webview apps)?
| scarface74 wrote:
| Now you can have all of the fun of the clusterfuck of modern web
| development in app form!
|
| (Not criticizing your effort. Red Goose isn't the problem.)
| rglover wrote:
| I'm working on fixing that clusterfuck (which paired with
| something like Red Goose would restore sanity):
| https://github.com/cheatcode/joystick.
| scarface74 wrote:
| So now you just have to fix the clusterfuck of Node
| dependency hell ;).
|
| I haven't actually looked at your framework or the dependency
| chain. It's more of a joke
| rglover wrote:
| Only by choice (i.e., if you as a developer add a bunch of
| packages to Joystick).
|
| 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.
| niblettc wrote:
| Very interested in using this as a short term solution for
| launching on Android. Is there a way to see a preview of the app,
| interact with it, etc. before we pay? Want to verify everything
| works.
| scottydelta wrote:
| By default, webview in iOS doesn't persist the user
| session(android does). Does generating the app via Red Goose
| solves this problem?
|
| 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.
| ghiculescu wrote:
| This isn't true with WKWebView. You might need a WKProcessPool
| but it's certainly not a lot of code you have to write
| yourself.
| scottydelta wrote:
| _> You might need a WKProcessPool_
|
| That's what I said, by default it doesn't retain session, you
| need to use some way or the other to do it.
| bambax wrote:
| Sounds interesting. Two questions:
|
| 1. 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?
| marvindanig wrote:
| Great questions! I'm Marvin, one of the founders of Red Goose
| and the maker of the Toucaan CSS framework.
|
| 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. :-)
| TheDesolate0 wrote:
| WA wrote:
| What is the difference between your product and Capacitor as a
| WebView wrapper (which supports most PhoneGap plugins) plus Ionic
| as a UI framework?
|
| 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.
| jamil7 wrote:
| I downloaded an example from the gallery page and as far as I
| can tell it doesn't bring anything to the table over Capacitor
| or a simple WebView. Proper navigation UX and gestures are
| missing on iOS so it immediately feels weird, every page
| transition is slow and throws up a spinner (which makes it feel
| slower than a normal website), any disruption or intermittence
| in internet connection and the app will stop working, state is
| not preserved etc. Kinda everything you'd expect to see if you
| just pointed WKWebView at a url and shipped it. So I'm
| struggling to see who this is for exactly when we have capable
| websites, Capacitor and all manner of cross-platform solutions
| in between those and native apps.
| kitsunesoba wrote:
| The missing or badly implemented navigation UX and associated
| gestures are probably one of the most immediately evident
| tells that an app isn't native, and probably one of the most
| frustrating. When I instinctively swipe from the left with my
| thumb to go back to the previous screen and nothing happens I
| immediately feel an impulse to go find a different app on the
| store.
| boxed wrote:
| You are missing a ton of screenshots to show what the result
| would be on mobile platforms.
| nmcfarl wrote:
| It took a little while but I found a page with a side nav bar,
| and thus a link to the gallery: https://goose.red/gallery
| boxed wrote:
| The iPhone screenshots are very bad fakes. So that's not
| encouraging :/
| Meph504 wrote:
| I'm sorry the pricing here is offputting to say the least, you
| think that pinch controls is worth an additional $400. and push
| notifications another $200 and your fastlane deployment $1000
|
| I think you are drastically over estimating your value add.
| AndrewVos wrote:
| When I focus the text input on your website all your CSS
| disappears. Chrome on Android.
|
| Not even sure how that's possible.
| wingerlang wrote:
| This service does not seem like something that needs pressure
| tactics. Naming it "fomo" is a bit on the nose as well. And I
| assume they are all BS as well, unless google ordered one 1 hour
| ago (or was it 33 minutes ago? who knows... it's randomized).
|
| https://goose.red/fomo
| doodlesdev wrote:
| Just opened the link, and...
|
| 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_modul
| es/express/lib/router/layer.js:95:5) at trim_prefix (/var/www/r
| ed.goose/node_modules/express/lib/router/index.js:323:13) at /v
| ar/www/red.goose/node_modules/express/lib/router/index.js:284:7
| at Function.process_params (/var/www/red.goose/node_modules/exp
| ress/lib/router/index.js:341:12) at next (/var/www/red.goose/no
| de_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/expres
| s/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).
| z3t4 wrote:
| Nothing seem to happen when I click "preview my app!"
| hbcondo714 wrote:
| This reminds me of manifold.js from a few years ago:
|
| https://news.ycombinator.com/item?id=9487941
| masukomi wrote:
| obligatory PWA comment:
|
| 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.
| memorable wrote:
| The website UI is broken on mobile.
|
| https://postimg.cc/gn3X2K1W
| AkshatJ27 wrote:
| The irony...
___________________________________________________________________
(page generated 2022-09-30 23:01 UTC)