Betting on the Web – Why I Build PWAs - <AUTHOR> https://joreteg.com/blog/betting-on-the-web <comment><USER2> So it sounds like PWAs now make this true:

> You don't have to create a native app because PWAs now offer all the > functionality of a native app.

That's cool. But _this_ has been true for a while:

> You don't have to create a native app because a mobile-friendly website > offers all the functionality you need.

I use (reluctantly) a bunch of apps that really should be just websites. They don't make use of my phone's camera or microphone or do anything fancy to my phone's user experience. They don't need any special permissions, aside from web access. They're really just websites in disguise.

And yet, for some reason, they're apps.

Some were even built as websites (e.g. using PhoneGap) and then compiled into native apps.

So before we convince people that PWAs are the answer for all of their fancy, highly integrated apps that previously could only be achieved as native apps, I think it's going to be an uphill battle just to convince them that in many cases, you don't even need an app. You just need a mobile website.

<comment><USER3> Being able to use the 'app' offline is a pretty important feature tho. I almost always have web access, but most apps also almost never need it (for me to do what I want to do).

<comment><USER4> This really depends on what the app _is_. A few of my friends use apps to look up when the next bus is coming. I use the official website. There's zero need for their apps to be available offline, they _only_ thing they're for is looking up the next bus, which requires an internet connection. The app in this case gives absolutely no advantage to the website. I find that's the case for a lot of phone apps

<comment><USER5> > look up when the next bus is coming

That's ridiculous argument against offline use - bus schedules are small enough data that we print them out and carry them in our pockets.

Sure, if the bus company socks, it might be nice to know about changes due to roadwork, real-time updates (ie look up the next _bus_ via it's gps location and speed) - but doing off-line route planning would be a great feature...

<comment><USER6> It sounds like you're not a daily bus rider. The printed bus schedules are useless due to delays. I take transit into work everyday and you need to know when the next bus is coming or you risk waiting at a station for twenty minutes.

<comment><USER7> Yeah, they're majorly helpful for transit commuters - you can avoid extended wait times, know when you can take a walk to the convenience store or even know when there's another or a bigger bus coming so you can decide whether it's worth getting on the packed bus or waiting for the next one. It really does change the transit game a lot.

</comment></comment></comment></comment></comment></comment><comment><USER8> I think one of the uphill battles you're going to have to fight with PWAs is end-user habit. If Joe consumer is looking for a great way to see a weather forecast he's going to look for an app. Jane wants to play podcasts - she's looking for an app. Ezra wants a Jewish calendar - app store.

99 times out of a hundred for the smartphone carrying crowd, the app store has become a replacement for google searches when it comes to tools/games/toys for their slab-o-glass...

<comment><USER9> You don't have to change users, you have to get Google and Apple to change. There's no technical reason they couldn't include web apps in their app stores. In the article the author speculates that both Google and Apple are working on this. I could see Google embracing web apps, but I'd be surprised if Apple does.

<comment><USER10> I would be seriously surprised if any smartphone company added PWA's to their app stores. Web apps inherently can't take advantage of many platform/model specific features. Even thing like UI elements, fonts, gestures etc. OS manufacturers want their feature sets used because it adds value to their ecosystem. As a consumer of smartphone apps, I tend to agree with them.

<comment><USER11> Microsoft announced at BUILD this year that PWAs would be ingested by the Bing crawler directly into the Windows Store, with tools for sites to opt out or further control their listings (including monetizing them).

The Windows Store has supported server-hosted web apps [1] for some time now, and provides a large subsection of the platform-specific libraries to hosted web apps. Hosted Web Apps are based on earlier drafts of PWA standards, but the expectation from BUILD and other Microsoft talks is that they will bring platform-specific libraries along for the ride as the converge to more recent PWA standards.

[1] [https://developer.microsoft.com/en- us/windows/bridges/hosted...](https://developer.microsoft.com/en- us/windows/bridges/hosted-web-apps)

</comment></comment></comment></comment><comment><USER12> I'm really sick and tired of going to a site on my phone, and getting inundated with popups and banners and crap telling me to install the app (Reddit, I'm looking at you).

I just want to view the same fricking website that I view on my desktop, but on my phone. You'd think that would be a simple and obvious way of working that would be supported by every single website in existence without any special effort on the part of web developers. And you'd be right, except web developers these days GO OUT OF THEIR WAY TO MAKE IT NOT WORK THAT WAY.

You'd think the simple and obvious fact, that phones these days generally have web browsers just as capable as desktop browsers, would have penetrated people's thick skulls by now. But for some reason everyone wants their own app, I darkly suspect so they can use the email, contacts, camera, microphone etc. for God knows what creepy spying and data harvesting purposes.

So if this guy's figured out that the way to convince The Powers That Be, who've already been convinced by someone else that You Need To Have An App Even If The App Is Literally The Same As Your Website, that it's actually okay to Not Have An App And Just Have People On Your Phones Go To Your Website, by simply re-naming your website from "a website" to "a Progressive Web Application," more power to him.

Me, I just want to look at websites, and occasionally look at them on my phone, and I'd like a web that allows me to have the experience I'm used to from my desktop, on my phone.

<comment><USER13> I work at a small business, and our customers are constantly asking that we make an app. We have a fully functional website that is completely responsive, and we do more mobile sales than desktop. But they keep asking for an app. I have no idea why- I guess it feels more "legitimate" than a website. I try to politely explain that I'm our sole developer, and I'd have to support the website, AND an iphone app, AND an android app, and they pretend to understand, and say "yeah, but an app would be nice...".

I mean, do you want the app so you can have an app, or do you want the app so you can make a purchase? I don't understand.

<comment><USER14> Same here, except I had someone make native apps. They were bad and unmaintained for a long time (solo dev here as well, running a small business). But still, people used this Android app that didn't receive updates for 4 years(!) over a mobile website where I put a lot of effort into.

At some point, I gave up. If apps is what people want, I make apps. After a looong process of deciding between native and hybrid (build with Ionic), I finally settled on Ionic. The result is actually quite okay. People love it. I can maintain two platforms with a single code base and will probably rewrite parts of the web app with Node so that I can share core code between 3 platforms.

How all of this will turn out in the long run, I don't know. Maybe I'll outsource app development at some point again in the future, now that I have a working product that is exactly as I want it to be.

Seriously, consider releasing a Cordova-based app. Slap some functionality on top so that it won't be rejected by Apple (Website-only wrappers aren't allowed). Maybe an offline storage or whatnot. This shouldn't take too much effort and you might be surprised that new customers find their way to your business.

</comment></comment></comment><comment><USER15> Just be aware that ionic3 is full of bugs. You can use angular 4 which is absolutely ready now. Ionic is full of promises (literally and figuratively), but it is not even ready as a beta.

\- I spent days to make workaround for making it work. Even basic things like routers.

\- I suffered a lot with its build process. Transpiling my typescript is a so much pain for my mac. That is even worse than when I compiled java years ago.

\- The need to wait 2 minutes for the live reload (when it actually reloads the change like expected) is a big loss for the web development process.

Anyway for me the point is totally true. I was only on natives and now only what you call "PWA"

<comment><USER16> Interesting that you had so many pain points. I like Ionic, don't love it but I find it to be very very easy to work with.

I don't mean to flame, I just want to provide a counter example as I was using Ionic on the day to day basis for about 5 months.

\- I find the router to be very easy to use, requiring no work arounds, you call the nav controller and push / set a view, nothing crazy here.

\- The build process, specifically for the TypeScript? Are you using the CLI? There's just about nothing you need to do

-I was able to start fresh on a mac and have everything up and running for both Android and iOS within 2 hours (this is mostly installing the Android SDKS).

\- And the live reloading will reload your entire app within 20 seconds, and this was on a pretty large Banking application using most of the plugins that are available (Camera, fingerprint, maps, etc etc etc).

Note that this is all done through using the Ionic CLI, which really eases the development process. I personally wouldn't try it without the CLI.

<comment><USER15> I use "ionic-app-scripts" (@ionic/app-scripts) for watching the change. It's what is used by ionic cli I think. Since the recent update to webpack 3 things are better but I still loss my focus on each build :) In fact I just checked and it's around 1 minute to finish the watch process, but many time consecutively, it become worse.

When I only update scss that is very quick indeed. The start process is very quick also.

For the router, things have became messy when I tried nested ion-nav. A method is deprecated (getRootNav) and the new is not even ready to use! (getRootNavById)

I post many issues on github. Still using ionic router (no other choices now, but by using tricks like events), and ionic cli for building, some buttons also, and I avoid anything else.

ion-menu was too buggy on ios, I had to make a menu by myself

The general quality on ios is very poor

Some plugins are great but I have bizarre issues... Keyboard plugin for exemple, I had to "ngZone" it to make it work.

Using the grid was too verbose and too buggy also. I design everything in flexbox now. It fells that ionic is trying to build a good WYSIWYGs editor with ionic creator but making developpers "beta-testing" their frameworks (sorry to complain after a open source project)

<comment><USER16> Hmm, definitely hop on the entire CLI, you won't regret it.

As far as live reload goes, it definitely is faster than 1 minute, are you connected via USB? For live reload I would stay connected via USB and then obviously you need to be on the same Wi-Fi, (For iOS, I've only used the simulator for development, but we test on a real iPhone all the time)

What kind of issues are you having with the menu? The only bugs that I've found had to do with animations, I had to use CSS animations as opposed to the Angular way of doing animations for iOS.

Other than that though, I've found the iOS to be the most stable version of the application, even though I developed it almost exclusively on Android (with some spurts on iOS to ensure everything worked).

As for the router, yeah I see what you're saying, our app is pretty straight forward as far as navigation goes.

The grid, I agree, it's annoying, it's like they threw bootstrap grid system and flexbox into one, and it's a bit strange.

</comment></comment></comment></comment><comment><USER17> > It is now possible to build PWAs that are indistinguishable from their > native counter parts

It's not now possible, but even if it were, it would only be because the native app does not in fact use native components.

The Starbucks app already doesn't feel native, with its custom casing, fonts, navigation and behaviors.

<comment><USER18> It's reasonably doable to get a PWA looking and feeling like a native Android app if you opt to use Material.io or Polymer's Paper Elements. Some behavior isn't 1:1 though, which can be frustrating.

<comment><USER19> What about iOS and others? Are we going to have to make multi versions of an app to make them look native?

For that matter, what does a native android app look like? I've never seen any consistency between apps at all, let alone the sort of consistency you can get with gnome, KDE or older windows.

</comment></comment></comment><comment><USER20> PWA = progressive web app. Took me a while to figure out what that acronym was. [https://pwa.rocks/](https://pwa.rocks/)

<comment><USER21> He finally touches that point about 50% through the story, but to be fair it's not in his title of the blog post.

</comment></comment><comment><USER9> The author spends some time talking about platform stability as a big part of why web apps are great. But for web apps, is the platform actually stable?

I run some applications on my PC that are older than the iPhone and they work just fine. Will the Starbucks web app still work a decade from now? Is any non-trivial web app ever actually _done_?

<comment><USER22> The platform has been stable for a while now. 20 year old web pages still render just fine. Its exceptionally backward compatible.

Web apps being "done/not-done" is a different question altogether, and it depends on the ever-changing goals of the app/business behind it.

<comment><USER23> Doe 20 year old web apps using java applets or framesets and Netscape 4 DOM still render just fine?

<comment><USER24> If you have a browser with a Java plugin, then yes.

</comment></comment></comment></comment><comment><USER25> Here's what I've realized lately. Our product is for teachers (K-6 mostly) who tend to not be very techy. They use phones, tablets, etc. to the extent that they need to. We spent TONS of time optimizing our website for mobile. At one point it was a PWA that was very optimized and had like a 95 lighthouse score (not anymore because of finicky SW behavior). They didn't care one bit. Like, not even one little bit. To them, it was annoying that it wasn't "an app".

I don't think this battle is one of "build good enough mobile web experiences", it's more "convince non-techy users that a good mobile web experience is good enough for you in x% of cases." For us who read HN, we're jaded on apps, installs, 100mb of storage wasted. For the less techy world, they don't feel the pain we do, and that will continue to be a problem.

<comment><USER26> This doesn't match my experience. I've recently built an "intranet" website for some consukting agency. They had an IOS app already, but no android app. I built them a SPA based on create-react-app with a material design look and feel, making sure it worked fine both on desktops and on phones (which also means changing how certain things are presented, not just scaling the same screens). I told them to try the "add to start screen" link on chrome mobile (or the equivalent in IOS safari)... they ended up ditching the IOS app altogether.

All in all, it depends hugely on the functionalities your app/web provides, and whether you can build an experience that is app-like enough or not...

<comment><USER25> I guess probably just fundamentally different experiences. We couldn't have afforded to put any more time into optimizing for mobile, but most users I talked to didn't even care to look at the mobile site before insisting they couldn't use it unless it was an app. No need for push notifications, camera, anything like that—heck we even put in the iOS add to home screen stuff to try to get them to see it as more "app" like—but still, they just insisted an app straight from the App Store was necessary.

</comment></comment></comment><comment><USER27> I've been experimenting with turning a work application into a PWA, but ran into a problem - all the stuff that would be great to cache was behind an authentication wall. None of the PWA examples covered this. Also, the service worker examples all had "Don't use this in production" warnings. :D

<comment><USER24> You can encrypt the cacheable content.

</comment></comment><comment><USER28> I had to CTRL+F through the article to learn that PWA == "Progressive Web App".

Am I missing a trend?

<comment><USER29> I had to do the same, looks like it was coined about a year ago.

[https://en.wikipedia.org/w/index.php?title=Progressive_web_a...](https://en.wikipedia.org/w/index.php?title=Progressive_web_app&action=history)

This article gives a solid overview: [https://alistapart.com/article/yes-that- web-project-should-b...](https://alistapart.com/article/yes-that-web-project- should-be-a-pwa)

</comment></comment><comment><USER30> Deciding to bet on the web is fine, but shouldn't the immediate next thought be like 'wait, why did the web win?' I think that's a far more interesting topic. It would be hard to argue that it didn't win, and it certainly wouldn't have been easy to see it coming. Someone designed a system for static hyperlinked document presentation... then years later others start shoehorning in broken bits of application-like functionality... years more along, the shoehorning continued with vigorous earnest, subverting every attempt by the W3C to prevent the web from turning into an application platform and remain a static document presentation system.

With so many hurdles to cross, so many things holding it back, why on earth did it win? Clearly not just because it was cross-platform, lots of things did that. Certainly not because it followed any even REMOTE sense of reasonable development. Remember when people used to talk about the utility of standard user interface widgets? I imagine all those people are dead now.

Personally I think it was the ability to search. That trumped absolutely every single other consideration across the board. What users wanted was to vaguely indicate what they wanted and be using that application moments later. There's no reason that HAS to be only how the web works, but it mostly is now. If something comes around that enables that elsewise... maybe consider putting a chip down on that as well.

<comment> david-cako To add on to this, the centralization factor of your webapp being a google search away is just one token of the overarching theme of "write once, run anywhere" \-- this translates to value for the user. Web apps are quite literally the only thing that can be run on essentially any device that is or can be connected to the internet. Nothing else achieved this because nothing else had an interpreter which was the most essential foundation of browsing the internet.

From a user perspective, being able to instantly download any "app" you need (i.e. visit a website) has been the logical conclusion of high speed mobile data. It's low investment, takes up a miniscule amount of ephemeral storage, and works on anything.

From a developer perspective, you can be assured that your single codebase will run on virtually any device, with minimal adaptations to it. You have enough performance to run mildly resource intensive 3D games, some basic concurrency, and an ecosystem that fixes all of the most important faults in the language (typescript is the biggest one IMO). You also increasingly have APIs that allow you to do everything that you could otherwise do with a proper desktop/mobile app.

Literally the ONLY reason webapps are not the first choice for most companies is because they're not as sticky (obnoxious). Users aren't forced to look at your icon and receive your notifications until they disable them. That's it.

<comment><USER30> Well there's also some other factors I would think... as soon as you want that fancy web app of yours to convert a 10GB video file you're going to be sad. Or if you want to have control of your data. Or if you don't want someone ELSE to have control of your data. Or if you don't want them listening to everything you say, profiling everything you do, and lacing everything with advertising... Much is done remotely which has absolutely no need to be. Voice recognition is the perfect example now. Sure you need a gigantic corpus and a datacenter full of GPUs to train the recognizer... but once its trained, you could use it on a raspberry pi without a problem. But the company wouldn't get the data that way.

There's no reason a similar system couldn't be built to deliver platform- native applications that run with full access to data you control and which call out to corporate servers only for situations where those corporations are going to provide actual VALUE that couldn't be had locally couldn't be made. It just hasn't been.

<comment> david-cako >There's no reason a similar system couldn't be built to deliver platform- native applications

I'm very into the idea of HTML/CSS/JS on the desktop (and by extension, things like react native), even if simply as a frontend to a heavier duty application running on localhost. I feel like the OSs should be shipping runtimes for it instead of having insane 120MB hello world electron apps.

Web apps also don't necessarily mean someone else has control over your data -- it is technically easier to determine whether they do. You can inspect web requests in your browser, you can't in most native apps. There are plenty of silly things like Dark Souls stat calculators that make so much more sense as a webapp, and are 100% client side.

<comment><USER23> > I'm very into the idea of HTML/CSS/JS on the desktop

Why? there are better languages, platforms and layout engines. HTML/CSS/JS was meant to be a document markup sharing platform, not a rich application one. Use the best tool for the job.

<comment> david-cako Graphical frameworks -- GTK? QT?

These are intertwined with the language and GTK especially does not look attractive on macOS and Windows.

The appeal to HTML/CSS/JS is it's 100% agnostic to the platform, and can even be used as a front-end to a program written in a different language.

<comment><USER23> Sure, but Java made that claim as a platform in 1995, and it was free and open source.

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> This is something I feel quite strongly about, and I too favour PWAs. I think native apps have their place for now, as a few key APIs are not fully exposed via browsers yet, but the API landscape continues to improve. Apple has even started dev on service workers for Safari, and their IndexedDB implementation is not as buggy as it used to be.

If I'm honest, apps never really made sense to me; they seem to be part of an intrinsically closed eco-system, which feels completely at odds with the initial premise of the internet, and dare I say, computing in general. If you have an Apple product, you must go to the App Store, if you have an Android product, then it's the Play Store etc. The feeling of openness that I became accustomed to (probably from a time before "apps") seems to have taken a step backward with mobile apps, and replaced with an endless need for vendor lock in. It's great for business, but as a user, it feels really restrictive. As a developer, it's not great either.

I believe that as browsers become more standardised (i.e. you don't need rubbish like if(IS_IOS) { ... } else { ... } in your JavaScript), and they start to expose more and more functionality via well-defined APIs, developers will favour the browser as a deployment platform, simply because it'll be more ubuquitous, will be easier to deploy and manage, and will have a lower barrier to entry. Till then, native apps will maintain their position, as they will be the more polished product.

A personal anecdote: I gave my latest app (a PWA - [https://usebx.com](https://usebx.com)) to a few small business owners in my home town to use for free. I pointed them to the website, and the first question they asked me was "why can't I find it on the app/play store?". I told them that they needn't go to the app store - just add the webpage to your homescreen, and you're good to go! They much preferred that method, as compared to "faffing around on t'app store" (imagine that said in a Yorkshire accent)! They even loved the app, and as far as I'm aware, found it on par with a native app. My point is, even the fairly long winded process of searching the app store to find an app, then waiting for it to install, was the first thing that came to mind for these non-techy guys. Once they knew about "Add to homescreen", they liked it. I think much of the transition to PWAs will be like this - people struggling free from their habitual need to use vendor specific app stores and eventually embracing the simpler, more open, web-based app paradigm.

<comment><USER32> > ... seems to have taken a step backward with mobile apps, and replaced with > an endless need for vendor lock in. It's great for business, but as a user, > it feels really restrictive. As a developer, it's not great either.

But isn't using a web app that stores its data to a remote server and handles upgrades a method of vendor (in this case developer) lock in? As a user you are 100% reliant on the developer, both for your data but also in their mercy when it comes to upgrades (imagine developers changing how their UI works to a way you dislike - my aunt every now and then calls me because something went wrong but what really went wrong was Google making slight changes to Gmail or the Google home page that confused her - or, even worse, starting to require more resources than your computer can handle but you cannot do something as simple - with native apps - as to just keep using the older version).

<comment><USER31> I don't disagree with what you're saying, but the issue I have is with the monopolistic aspect of an app store... Basically, it's one or two monolithic companies that control everything and determine the rules because they make the base operating systems. With regards to updates etc, I think similar issues apply to native apps - e.g. devs can change the backend, which can break older front ends. I'm sure you can eventually have the concept of a versioned web app as well, much like versioned APIs, and users can decide if they wish to upgrade.

<comment><USER32> TBH i was mainly thinking about desktop applications where app stores are not really a thing (beyond Steam) and - at least in Windows - you can still use applications written a couple of decades ago while the companies that made them have long dissolved.

I agree about the gatekeeperness aspect of app stores too :-). At least with Android there is the ability to install APK files, though it isn't very user friendly.

</comment></comment></comment></comment><comment> norea-armozel I'm not sure I understand the motive behind progressive web apps. Some apps I can see being web-only. But apps that require extensive storage, low latency, and much more traditional computing resources isn't going to work in the mold of a PWA. A calendar, a chat room, or some games I can see fitting the PWA mold automatically. But like I said, PWA to me isn't a universal replacement for good native app development. It fits many lightweight problems but anything else that better fits native should stay native. I really wish web developers would acknowledge this much and stop trying to say "why can't you make that a web app?"

</comment><comment><USER14> I want PWAs to succeed, because I would love to publish close-to-native apps without an app store. I think PWAs are a great thing for the open web. However, hyping PWAs with unrealistic expectations doesn't do any good. The Ionic team talks in the same vein. I like Ionic, I don't like hype. Here are a few reasons why PWAs aren't there yet and probably won't replace most apps in the near future:

\- No native APIs. Yeah sure, you can order a coffee at Starbucks, but the underyling hardware isn't exposed to JS. You won't be able to make a camera app with PWAs.

\- Input controls suck. Same as with every mobile browser and every Cordova- based app: You cannot control how the keyboard behaves and I suspect that it's not even in Apple's interest to make Mobile Safari super-great. Sure, they're working on PWAs, but that doesn't mean anything. Just see how bad Mobile Safari's <select> looks like. Or bugs in multi-selects that have been there forever.

\- They still run in a browser. It shows an address bar and whatever else your browser is always showing. Try Twitter's PWA right now: [https://lite.twitter.com](https://lite.twitter.com) It's way too easy to accidentally swipe back. And then, Twitter being a shitty Single-Page-App, the browser loses its scroll position.

\- PWAs suffer from the same problems like all SPAs [1]

And finally:

\- A PWA is just a proxy to download and cache responses from a server. It enables offline support (kinda) for single-page apps. It's not a magical something. The problem is that most users go to the App or Play Store first (like djrogers pointed out here: [https://news.ycombinator.com/item?id=15219682](https://news.ycombinator.com/item?id=15219682)). They COULD be using PWAs – or at least good mobile webistes – right now, but they aren't.

I think PWAs will find their places and I'm betting on them, too, to a certain extend. But over-hyping PWAs without addressing these issues is just naive.

[1]: Great read on this topic: [https://adamsilver.io/articles/the- disadvantages-of-single-p...](https://adamsilver.io/articles/the- disadvantages-of-single-page-applications/)

<comment><USER31> One mobile safari bug that really irritates me is not being able to move the cursor on a text input element. Basically, if the text in there is longer than the element, you won't be able to move the cursor left or right. You can only work with the visible part of the input element. Try it - it's really quite terrible!

<comment><USER14> I know. Same with textareas, especially if they're wrapped in some kind of scrollable container. It is a mess. I don't know why it's not being fixed.

The only reason I can think of is that Apple intentionally keeps the mobile experience slightly crappy so that people perceive native apps having higher quality.

Of all companies, Apple should be the one with the best usability in a browser, no? But hardly so.

</comment></comment></comment><comment><USER33> "4\. PWAs everywhere"

Yeah, yeah, I read that many times while I researched about it. But everywhere seams to mean today, everywhere except for the old-school Desktop (!)

I mean I understand, that the implementation and development of a new standard takes time and since mobile is hip, everyone focus there first. Makes sense. But I feel a bit ridicouled(and annoyed) with all the PWA, don't worry about plattform talk - and then there are no signs at all, that the traditional desktop is a target in the near future, if it is at all. At least I could not find further informations.

[https://developer.mozilla.org/en- US/docs/Web/Manifest](https://developer.mozilla.org/en-US/docs/Web/Manifest)

And I am building a webapp, which does a bit more than turning on a lightbulb, so I also like it to run on a real PC. To work with it. With a screen and keyboard - and yes, whenever I want, easily switch to mobile and still be able to work with it, ... this is what would make me excited. True plattform- independence, where I don't have to worry about clumsy plattform details. What I have to worry about is adjusting to the screensize, etc. and if there is a keyboard, mouse, gps, device orientation, battery maybe(so the app knows to save urgent data, before, the power goes off), pressure sensitive pen, multitouch, etc. etc.

I'd like to have all this information and then present the user the best UI I can master with the given conditions and don't worry what happens behind the scene.

I just target the WebAPI's.

And they get more and more powerful. Mozilla tried to build and market their OS around them, which failed comercially, but helped the basic idea a lot. And this basic idea I like because of the simplicity. So I am excited and looking forward for further improvements ... but please don't forget the desktop as a plattform!

</comment><comment><USER34> I think buildings sites as PWAs is a good idea but it'll take some time for them to actually replace apps. As other commenters have said, user habits go straight to apps. And until Apple decides to support service worker in iOS Safari, it won't have the same functionality as on Android.

<comment><USER35> Worth noting that Apple (WebKit) set Service Workers from 'Under discussion' to 'in development'

</comment></comment><comment><USER36> "With the original iPhone, there was no App Store, and no third party apps. At least not at first..."

[https://www.imore.com/history-app-store-year- zero](https://www.imore.com/history-app-store-year-zero)

I think this section sums it up well why there became a demand for apps, and the points are still valid today.

"But back then, the limitations of web apps, their lack of access to core functionality, their relatively poor performance compared to native apps, and the difficulties involved in charging for them proved to be insurmountable problems.

As a solution, web apps were more sour than sweet."

</comment><comment><USER37> the author doesn't seem to discuss Android's "instant app" feature [https://developer.android.com/topic/instant- apps/index.html](https://developer.android.com/topic/instant-apps/index.html)

 _Android Instant Apps allows Android users to run your apps instantly, without installation_

</comment><comment><USER38> This is pretty cool and was actually my reasoning behind creating my side project as a PWA.

It's a gym workout logging app and you can try the UI without needing an account -> [https://ewol.fitness](https://ewol.fitness)

</comment><comment><USER39> I sure hope history will repeat itself. Just like Desktop, web apps are taking over. Hopefully, PWAs will do the same in mobile.

No one wants to install/update apps anymore. They are not exciting. They are chore.

</comment><comment><USER40> PWA = Progressive Web Apps

</comment><comment> pablo-massa It's possible to sell a PWA like sell a $5 app on the App Store/Play Store? The author doesn't address this topic and it's important to make a transition imho.

<comment><USER41> Well, since the trend goes towards In-App-Purchaes, you could simply paywall some functionality and slap Stripe or PayPal on your website. That should give users a relatively similar experience. Don't even have to share 30% that way. It's up to you.

</comment></comment><comment><USER42> This is the most congruent argument advocating web apps and indirectly the most clear career advice that I've read for a long time.

A sincere thank you.

</comment><comment><USER43> I don't think writing a web extension thingy on Safari/Chrome mobile can be achieved with a PWA. Would love to be corrected.

</comment><comment><USER44> Thank you SO MUCH!!

Speaking of BlackBerry, I now have a functional Starbucks app on my BlackBerry10 phone (and not a laggy Android sideload).

You rock.

</comment><comment> unkown-unknowns I'd not heard of PWA before. After reading the OP I did an additional search on Google. Found a course on udemy that claims to be on sale.

[https://www.udemy.com/progressive-web-app-pwa-the- complete-g...](https://www.udemy.com/progressive-web-app-pwa-the-complete- guide)

I've seen three of the videos in it so far. Seems like an ok course for the ~25 USD I paid for it.

</comment><comment><USER45> > You don't have to create a native app because PWAs now offer all the > functionality of a native app

This is a blatant lie

> Starbucks PWA: ~600KB

2.1 MB just the initial page, with no cards. The preview.js file is 751 K

I do agree, however, that it's much smaller than an iOS app.

<comment><USER46> > 2.1 MB just the initial page, with no cards

650 KB for me: [https://i.imgur.com/eVoZtWQ.png](https://i.imgur.com/eVoZtWQ.png)

<comment><USER45> preview.js 752 KB

vendor.js 614 KB

[https://dmitriid.com/i/gm2tmobrgeydcnbt.png](https://dmitriid.com/i/gm2tmobrgeydcnbt.png)

<comment><USER14> Wrong column. Transferred counts. Not the actual file size.

<comment><USER45> Well, the actual file size is what is going to be parsed and run on my computer. <something ... something.. google...google..parse sizes for javascript etc.>

</comment></comment></comment></comment></comment><comment><USER47> Apple is the only problem they keep dragging their feet on modern web features to try to force developers into native iOS

<comment><USER31> Lol, yes! Safari can sometimes feel like the new Internet Explorer. Having said that, they have started work on service workers now!

</comment></comment><comment><USER48> Android's answer to this guy's "app for this right now" thing:

[https://www.theregister.co.uk/AMP/2017/01/25/google_testing_...](https://www.theregister.co.uk/AMP/2017/01/25/google_testing_android_instant_apps/)

</comment><comment><USER49> So, a PWA is a massively bloated web page? Yeah, that is exactly the kind of thing I want to run on a browser in my phone.

Sure, a decade with Moore and it might actually become usable - but do we really want to set the bar that low?

Installing an app is cumbersome, but when going to his example I'm forced to create an account just to see what it is.</comment>


Why Microsoft killed Courier - j-g-faustus http://www.dailytech.com/article.aspx?newsid=23176

<comment><AUTHOR> In the old days, when competitors were afraid to even say Bill's name, Microsoft would have hedged their bets.

Microsoft sold some crazy UNIX thing called Xenix, DOS, and ported their software to OS/2 and Mac OS.

Microsoft did not care who won, as long as they were positioned to get their foot in the door, make a huge profit, kill off all the competition, start displacing their upstream and downstream dependencies, and cement their position by extend-embrace-extinguish.

They have one offering on the mobile, nothing to speak of in the tablet space, and very few apps / trojan horses for iOS / Android. It's like watching Ulysses stick to the Marquess of Queensberry rules.

<comment><USER2> The difference being, of course, that in the old days Microsoft was not a convicted monopolist.

</comment></comment><comment><USER3> > According to Courier team members, the 130+ team had several finished > prototypes and could have brought the device to market in mid-2010 with a > bit of extra manpower.

A bit? They had some prototypes with just the industrial design, some with just the software, some with just the performance - but none with all the aspects of the finished product. And they say they were a few months away?

The hubris behind this kind of thinking is astonishing. It would take nothing short of a miracle to pull together all these elements in such a short timeframe. There are so many inter-related aspects that would prevent this. Performance, battery life, weight, heat dissipation, software drivers, power management - must all be designed and working in concert for a successful product.

And that says nothing about the product positioning. Are there seriously millions of architects out there who have been saying: "Boy, I wish I had a small, portable computer screen I could sketch my ideas out on." ? There's a reason they have huge drafting boards - they think big, and need big spaces to sketch out their big ideas.

I love the way they were thinking outside the square, and there were some seriously cool ideas in Courier. But it seems much more like a groovy concept than a nearly shipping product.

</comment><comment> D-Coder But that's one of my favorite fonts!

Wait, what?

</comment><comment><USER4> Not politics. Because it couldn't do email.

<comment><USER5> I don't understand why they chose to kill it instead of improve it.</comment></comment>


Four common mistakes in audio development (2016) - <AUTHOR> http://atastypixel.com/blog/four-common-mistakes-in-audio-development/ <comment><USER2> For less Apple-centric guidelines : [http://www.rossbencina.com/code/real- time-audio-programming-...](http://www.rossbencina.com/code/real-time-audio- programming-101-time-waits-for-nothing)

<comment><USER3> Name me a working professional musician who doesn't use Apple gear (assuming they use computers at all to make music).

<comment><USER4> I worked in a studio (with 8 work spaces and a Dante network) and there was no single Apple machine. Of all the musicians I know maybe two use Apple, most use Windows.

The whole "musicians use Apple"-thing is really not true — at least in my subjective sample size.

<comment><USER5> I used to work for a well-known audio plugins company (if you're a musician, you've heard of this company) and 70% of our customers were Mac users (that was back in 2016).

</comment></comment></comment></comment><comment><USER6> As an Audiobus user since pretty much day 1 (and also a Loopy app user), I'd just like to shout out to the author of this article with a "Thank You" for revolutionising music creation on Apple's small devices.

I still remember the first time I managed to combine some of my favourite sound generator & synth apps and create a mix all on my iPad without having to export things to Garageband/Logic [0], and it was a real game changer on that platform.

If anyone knows about audio development on iOS devices, this author is the 'go to' guy!

[0] - [https://soundcloud.com/cyberferret/industrial-ants- wav](https://soundcloud.com/cyberferret/industrial-ants-wav)

<comment><USER7> > _favourite sound generator & synth apps_

Any you'd specifically recommend?

<comment><AUTHOR> AudioKit Synth One is fantastic, and it's all open-source too.

<comment><USER8> Thanks for the link. To close the loop the audio kernel documentation in AudioKit Synth One references the OP.

[https://github.com/AudioKit/AudioKitSynthOne/blob/master/Aud...](https://github.com/AudioKit/AudioKitSynthOne/blob/master/AudioKitSynthOne/DSP/README.md)

It's interesting in that it's written in Objective-C++ which in xcode are suffixed with .mm - This is for performance reasons I assume.

I didn't know about Objective-C++ and here is a link about it. Is it kind of pushed into a dusty closet? Because I only found an archive.org link.

[https://web.archive.org/web/20101203170217/http://developer....](https://web.archive.org/web/20101203170217/http://developer.apple.com/library/mac/#/web/20101204020949/http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html)

</comment></comment></comment></comment><comment><USER9> _Let's say your GUI thread is holding a shared lock when the audio callback runs. In order for your audio callback to return the buffer on time it first needs to wait for your GUI thread to release the lock. Your GUI thread will be running with a much lower priority than the audio thread, so it could be interrupted by pretty much any other process on the system, and the callback will have to first wait for this other process, and then the GUI thread to finish and release the lock before the audio callback can finish computing the buffer — even though the audio thread may have the highest priority on the system. This is called priority inversion._

I guess I fundamentally don't understand priority inversion. I've done a lot of realtime programming but have never had to confront that particular buzzword.

If my realtime-priority I/O completion routine tries to take a lock that might be held by an idle-priority GUI thread, why is that a problem? If I'm waiting on a lock, then _by definition_ I'm not running at realtime priority while I'm doing so. Thread priorities should apply only to threads that are actually doing stuff. It would be crazy for the kernel to fail to schedule any other threads while I'm waiting for one of them to release the lock I need. My realtime thread is effectively suspended during that wait, so it can't keep any others from running.

Yes, I might have to wait for other threads and even other processes to be scheduled. Too bad. If I didn't want that to happen, I shouldn't have tried to take a lock in a realtime thread. What exactly should I have expected to happen?

<comment><USER10> Something else might start running instead of your realtime-priority thread or GUI thread.

<comment><USER9> Yes, that's an occupational hazard when you're waiting on a lock. Someone else might do something. In fact, someone else had _better_ do something, or you won't get your lock.

IMHO, if your system is designed such that a GUI or other low-priority thread is contending for the same resources as a realtime I/O thread, in a situation where the lock might be held for so long that the I/O thread starves, then you have made a really elementary mistake... one so fundamental that it doesn't deserve an abstract-sounding term like "priority inversion." I still feel like there's something I'm missing here.

I mean, I understand that the GUI thread in question might be heavily pre- empted by medium-priority threads, but eventually the GUI thread _is_ going to be given enough time to finish whatever it was doing with my lock, and life will go on. Is this behavior somehow unexpected or counterintuitive?

If kernels are designed such that lower-priority threads _never_ get a time slice until higher-priority threads block on something or explicitly sleep or yield, well, that seems like a really foolish call on the part of the kernel designer. You literally might as well have a cooperative-multitasking OS at that point.

<comment><USER11> > I mean, I understand that the GUI thread in question might be heavily pre- > empted by medium-priority threads, but eventually the GUI thread is going to > be given enough time to finish whatever it was doing with my lock, and life > will go on. Is this behavior somehow unexpected or counterintuitive?

The mistake people make is, they think "my high-priority thread has to be active every 10ms, and the low-priority thread doesn't do much work with the lock held, 1ms max, so I'm totally fine, there's 9ms of safety factor there". Priority inversion is why that logic is wrong.

</comment></comment></comment></comment><comment><USER12> Previous discussion: [https://news.ycombinator.com/item?id=11907887](https://news.ycombinator.com/item?id=11907887)

</comment><comment><USER10> > Behind Objective-C's message sending system (i.e. calling Obj-C methods) is > some code that does a whole lot of stuff — including holding locks.

Only if your method is not found in the IMP cache. Trying to acquire a lock for every objc_msgSend would be quite slow.

> I decided not to mount an expedition into the source code because I didn't > know what to look for, or where to look for it, and I wasn't even sure I'd > even find it given that iOS and OS X are both pretty closed-off systems. So, > we'll have to take the word of those more knowledgeable than us, at least > for now.

macOS's libmalloc is open source (if not updated very often): [https://opensource.apple.com/source/libmalloc/libmalloc-166....](https://opensource.apple.com/source/libmalloc/libmalloc-166.251.2/)

<comment><USER13> The post is about chasing the long tail of latency risk. A high -- even very high -- probability of not acquiring a lock is not good enough. Investigating libmalloc and discovering that somehow it had strictly bounded, suitable execution time wouldn't be good enough either, because it could plausibly change without notice.

<comment><USER14> To get an idea of the length of the tail:

Suppose a deadline of 6ms to produce an audio buffer. If 0.01% of the callbacks choke on a lock, we get a dropout once a minute, which is quite a lot. This means we're interested in the 99.99th percentile.

</comment></comment></comment><comment><USER15> > It can be helpful to know that, on all modern processors, you can safety > assign a value to a int, double, float, bool, BOOL or pointer variable on > one thread, and read it on a different thread without worrying about > tearing, where only a portion of the value has been assigned by the time you > read it.

What? NO! This is only relevant when you're writing assembly. In C, you _have to_ use atomic (or possibly volatile, I'm not sure), or this just undefined behavior.

<comment><USER16> If you are assigning something that fits in a single register, how would you get tearing? (Probably shouldn't have double in that list, in case it's in the special FPU registers)

<comment><USER17> The compiler is smarter than you think. Suppose one thread alternates between writing 32 and 33 to a 4-byte variable, while another thread alternates between writing 1024 and 1025 to the same 4-byte variable. You might think that the only possible values are 32, 33, 1024, 1025; but then you read the variable and find a 1056 or 1057 there. Why? Because the compiler noticed that the first thread, after its initial write of 32 or 33, only modifies the least significant byte of the value; so it generated a single-byte write to overwrite only the modified part of the value.

<comment><USER18> There's zero benefit to just writing one byte. I'm having a hard time believing that a compiler capable of such analysis would use it for this purpose.

<comment><USER19> I think the point is that unless the language guarantees atomicity (and the compiler implements the guarantee correctly), counterintuitive behavior is permissible and somewhat common, and compiler behavior varies across and within CPU architectures.

<comment><USER18> Actually I agree with the general point, OP is right that you should use volatile. I was just a bit taken back by the specific example above.

However, as PeCaN has pointed out, I'm probably suffering from tunnel vision from x86 monoculture.

<comment><USER14> Volatile is, well, volatile. You can basically only rely on the fact that the compiler respects source order and keeps all reads and writes (instead of hoisting and reordering).

I believe msvc used to put in memory barriers. Not sure if it still does. These days you are better off ignoring the entire keyword and using the properly specified atomic stuff.

<comment><USER2> > I believe msvc used to put in memory barriers. Not sure if it still does.

it does but now there's a flag to disable them : /volatile:iso ([https://docs.microsoft.com/en- us/cpp/build/reference/volatil...](https://docs.microsoft.com/en- us/cpp/build/reference/volatile-volatile-keyword- interpretation?view=vs-2019)).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Wow, is all this really necessary now? Decades ago I recall programmers being immensely proud of their Z80 queue functions that didn't disable interrupts. They were needed for the same reasons the article spells out: dealing with hard real time events. But all it took to break it was another programmer leaving interrupts off we a wee bit too long in another piece of code, so we replaced these things with hardware queues that grew bigger and bigger over time - even UARTS had them.

I am sort of amazed that audio recording hardware doesn't provide at least 100 milliseconds worth of buffering. It's all of 600 bytes of memory on a 48k bit/sec stream, so it would cost them nothing.

<comment><USER21> The main problem with audio is that in many cases 100ms of latency is unacceptable. Having a large queue is a fine solution when latency isn't a big problem, but in a lot of cases for audio you want to get as close to no latency as possible.

<comment><USER20> That's true in things like phone calls, but I did read the article looking for cases like that and didn't see any. It is all about post processing, where latency isn't an issue. All you need for that case is an accurate clock embedded in the stream.

It really isn't rocket science, whereas here we have an entire article on keeping latency down in multithreaded code which should tell you it's both time consuming and requires an pretty skill full programmer. The rocket science bit starts after it's been written, and someone who doesn't have the big picture on where all the latencies are starts touching the code. The program doesn't break in an obvious way, or even deterministically. Instead the first symptom you are likely to notice is heisenbugs occurring in production and the frequency is gradually increasing as the code ages. Tracking that down and fixing it _is_ rocket science.

Compared to that the price of adding a buffer plus a clock in the next re- design is less than peanuts. We've been doing this stuff for decades now and gone through plenty of re-designs, which is why I'm amazed it hasn't happened.

<comment><USER21> But what makes you think sound cards _don 't_ have buffers? They do, plenty of it. You can easily cause any modern OS to have multiple seconds of audio lag by cranking the buffer size. People just generally don't want that from their system which is makes all this somewhat tricky.

Of course if you're doing batch processing you hardly care about latency and the problem is trivial except for the fact that if you hit the play button in your post processing software you _still_ expect instant audio output, especially for deciding cut points and whatnot.

</comment></comment></comment></comment><comment><USER22> > Don't use Objective-C/Swift on the audio thread.

His argumentation is that Objective-C uses locks internally.

But isn't it possible that those locks (as opposed to _application-level_ locks) cause just negligible pauses, because there's no contention on them?

I guess those internal locks exist to make ObjC's runtime dynamism feasible. One would expect the typical application to not leverage that dynamism (how many apps continously redefine methods under normal operation?).

<comment><USER23> The problem with locks on a non real time os is that the OS may decide to interrupt your thread while it's holding the lock. No matter how short that is. I do embedded I've had similar things happen when the 'lock' is held for just a few instructions.

Tip: If you suspect crap like this, adding spin delays will make it happen often enough to debug.

<comment><USER24> By any chance do you have any references or information on how to do this (adding a spin delay)? It sounds interesting. -thanks :)

<comment><USER23> In C it's very simple

       volatile int cnt = 0x1000;
       while(cnt--)
         ;

<comment><USER25> I've grown so paranoid of optimizing compilers this wouldn't even cross my mind. But it is correct, right?

<comment><USER26> Not OP, but the "volatile" qualifier should prevent the compiler from optimizing it out.

<comment><USER23> Yeah should.

Multicore super scalar processors make me nervous about my assumptions. I wouldn't put it past one of them to realize that the result is unused and nop it.

It's always good to check.

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> Let's say you are recording and processing audio in realtime. You have one function available which runs on a separate thread and provides you with the samples (fixed number every call). As I understand this article (and similar ones), you are not supposed to malloc on that thread (as that thread hanging could result in dropped samples). But if you want to save the audio, how else are you going to save it without appending to some array (for which you need to malloc)?

<comment><USER28> > But if you want to save the audio, how else are you going to save it without > appending to some array (for which you need to malloc)?

I don't know why everybody is making this so hard: You use a lock-free statically allocated circular buffer for all communication to or from a real- time audio thread. Period. Full stop. The audio thread wins under all contention scenarios. The audio thread _ONLY_ ships data from the circular buffer to the hardware system or vice versa-- _IT DOES NO OTHER TASK_. Everything else talks to the circular buffers.

Nothing else works.

The big questions are even if you do that--1) how do you keep the circular buffer from starving even with your other threads working to fill the circular buffer? and 2) if the circular buffer starves, what do you do?

<comment><USER29> _The audio thread ONLY ships data from the circular buffer to the hardware system or vice versa--IT DOES NO OTHER TASK._

All you have done in this case is push the problem up one level. The interface with the hardware already works this way.

The interesting problem is actually doing something more substantial - eg. deciding which audio to play, or processing it in some way - in a way that lets you keep feeding that circular buffer on time, every time.

<comment><USER28> > All you have done in this case is push the problem up one level.

Actually, using a circular buffer has transferred a "hard, real time" problem into a "soft real time" problem. As long as what you want to do has an average time shorter than the time between audio packets and you have enough audio packets buffered, you can ride across the occasional schedule miss because the system was off doing something else (like GC).

For example, VoIP quite often uses a "jitter buffer" for exactly this task.

Now, you still need to keep the circular buffer fed and that may not be easy. However, it's a _lot_ easier than being 1:1 with a hard audio thread.

> The interface with the hardware already works this way.

Most of the time when I'm interacting with low-latency audio threads, they generally don't allow me to specify the buffer semantics with very much flexibility.

</comment></comment></comment></comment><comment><USER30> I'm wondering if anyone here does embedded audio synthesis. Is a Teensy the way to go?

<comment><USER31> It's a little slow. I've used a Mega, but all around prefer the Adafruit Feather line.

<comment><USER30> That's what I bought the first time, but unfortunately there don't seem to be good audio libraries for the Feather line, and the Teensy Audio library looks quite sophisticated. Or did I miss something?

<comment><USER31> They should be compatible. It's all Wiring at the end of the day. But IDK, I just write my own.

</comment></comment></comment></comment><comment><USER32> Current OS's are fundamentally unsuitable for audiowork. macOS < Windows < Linux < other OS. None of them really do real-time processing.

It's really bad, I want a new OS where I can actually tell the scheduler what to do.

Also, check out this music composition app I'm launching soon [http://ngrid.io](http://ngrid.io).

<comment><USER33> Why is the realtime Linux patchset + Jack audio server insuffecient for what you do?

<comment><USER32> A patchset is not an OS. Like I can make it work for myself but good luck making it work for users.

<comment><USER34> I thought you wanted it for yourself, though?

If you wanted something that lots of other people could use, in principle you could make your own Linux distribution with a particular set of patches.

<comment><USER32> You can't expect people to use your os.

</comment></comment></comment></comment></comment><comment><USER35> Excellent article. Great explanation. Thanks Michael!

</comment><comment><USER36> > Rendering live audio is quite demanding: the system has to deliver n seconds > of audio data every n seconds to the audio hardware. If it doesn't, the > buffer runs dry, and the user hears a nasty glitch or crackle: that's the > hard transition from audio, to silence.

I think you can do better when a buffer runs dry. Instead of outputting silence, you could output the same frequency spectrum as you were right before the event. That way you will not hear any cracks or pops.

And of course you can fade out the effect when the buffer stays dry for more than a few seconds.

Obviously, you'd have to do some filtering when the audio continues because that too can introduce cracks.

<comment><USER37> There is really no such thing as 'instantaneous frequency response'. For any frequency to meaningfully exist, you need data for the corresponding period. e.g. If the audio contains content to 20hz, you need at least 1/40th to 1/20th of a second of data for that to materialize.

Put another way - what you are proposing it looping the buffer which is what some devices do, portable CD players were kinda notorious for it and it doesn't sound much better than cracks or pops. Computers also have a tendency to fall into buffer looping when the system hangs (which is likely the result of the failure mode of realtek codecs).

<comment><USER36> > There is really no such thing as 'instantaneous frequency response'

Yes that's true, I'm proposing something that uses an approximation of it.

Consider it from a different angle: the inner ear essentially performs a Fourier transform. At every moment the "instantaneous" spectrum determines which hair cells are triggered. Now what I propose is to keep triggering those same hair cells (and not any others) when the buffer runs dry. The exact way of accomplishing this is left as an exercise (though using short windows where you take a FFT could be a good approximation).

<comment><USER38> > The exact way of accomplishing this is left as an exercise

Perhaps you should undertake this exercise and let us know how it sounds :)

EDIT: In my experience with audio, when I have a bug that introduces even the slightest discontinuity (or even just a cusp) in the audio, well short of a pop to silence, I can still hear a "weirdness". Ears are pretty attuned to things that sound unnatural. I'm not confident that essentially "forging" the audio is going to sound natural.

<comment><USER39> What if you train a deep neural network on the song so far, so it can generate plausible-sounding music whenever the buffer drops?

You can even hang intentionally to generate original music!

(/s, please don't)</comment></comment></comment></comment></comment>


Show HN: GoBelle. Like our mission? - <AUTHOR> http://gobelle.me/mission <comment><USER2> A few notes:

After spending 5 seconds reading I can't tell what your mission is. It works best to first write out the mission statement in a one sentence.

Do you sell photovoltaics? Jewlery? Bitcoin services? My mind jumps around with the current page.

The mission statement may also read better if it talks about what the company wants to do -- not what the visitor wants.

Now I visited the main page, it is jewelry. It's a beautiful page. I would suggest making the subscribe button taller so people will be more likely to press it. I also wish I knew how the stones are sourced, which perhaps is was what you tried to touch on in the mission.

<comment><AUTHOR> Thank you so much for your feedback. We'll be doing these changes.</comment></comment>


OpenID Connect spec is now there - <AUTHOR> http://openidconnect.com/

<comment><USER2> This is my old first draft from last year. Others have been working on making it real over the past few months but the site hasn't been updated yet.

<comment><USER3> It definitely needs some big picture explanation up front.

</comment></comment><comment><USER4> Hasn't this been around for a while now? It says (c) 2010, and I could have sworn I've read this spec before.

</comment><comment><AUTHOR> This is where the final spec apparently lives, but seems to be down now: <http://openid.net/specs/openid-connect-core-1_0.html></comment>