Show HN: Pep – Turn Your Website into a Progressive Web App
pep.dev
pep.dev
I'm assuming this is targeted at a non-technical audience (although posting to HN would suggest otherwise), but I suppose it could provide some benefit under ideal conditions.
Including a 24kb font for the three "pep" letters in the heading just tops off the eternal face-palming. Incredible.
[0] https://developers.google.com/speed/pagespeed/insights/?url=...
Lighthouse score is now 91%.
* https://www.webpagetest.org/result/200227_RM_75b0bc807f4fc90...
Seeing the service in action would really help both technical and non-technical audiences, I need to know it's not going to be a liability and my clients would want to see pretty colours / improvements.
Something like "before.pep.dev" and "after.pep.dev" would be great.
Call my cynical but having made a few progressive webapps myself I'm very dubious that a "single line of code" is going to result in a great, performant PWA. How is the service worker installed? Or the manifest.json? How do you decide the user behavior that triggers a page precache? How does that precache deal with things like user logins when it has no visibility into your system? Where do the app icons come from? And so on. pep.dev's own service worker is just a Workbox cache and little more.
I'll openly admit I'm a cynic. Prove me wrong!
I don't want to build native apps. So I built Pep. It turns your website into a Progressive Web App (PWA) with one line of code. It's kind of like Workbox (https://developers.google.com/web/tools/workbox), but with adaptive pre-fetching, CDN, and responsive asset batteries included.
I'd love your input; feedback is how good products become great.
Lighthouse score is now 91%.
* https://www.webpagetest.org/result/200227_RM_75b0bc807f4fc90...
Did any of them use Pep? Doesn’t look like it.
I’d say this is deceptive marketing. Not sure if it’s trademark violation.
As for whether it’s actually deceptive...
Ex how do you define the installable icon for the Add to home screen icon ? Or how do you choose what gets in the cache for offline access ?
PS : this is your score https://www.webpagetest.org/result/200227_PT_b799b0e13e0417b...
* https://www.webpagetest.org/result/200227_RM_75b0bc807f4fc90...
Great questions.
> Ex how do you define the installable icon for the Add to home screen > icon ?
Pep tries to source the default icon from the site itself, eg a high resolution favicon, if possible.
If unavailable, or a different icon is preferred, the user is prompted for one. But by default, Pep tries to source such data and information the best it can.
> Or how do you choose what gets in the cache for offline access ?
Requests are observed, in the ServiceWorker, to determine which assets are requested on different pages and across the whole site. Those observations are turned into confidence scores, per asset, to determine which assets should be cached (and pre-fetched if not already cached).
You can, of course, pin certain assets for offline caching 100% of the time. But, by default, Pep does its best to cache requisite resources as determined by observed site activity.
There is absolutely nothing here. Just marketing fluff.
Are you coding on PowerPoint?
One worse: Emacs. =]
All I can find on the OP's link is marketing copy about how much PWAs are than standard web sites.
Will be good to see how this affects / slows down site performance.
On a separate note, how many users know about or bother to “Add to screen”? Can the number of users launching from the home screen be tracked?
Thank you!
> On a separate note, how many users know about or bother to “Add to > screen”?
PWAs are relatively new. Not many users know about installing them yet. But that's changing. See the install flow videos here
http://i.imgur.com/vVoDtbW.png
to see what installing a PWA looks like from the users perspective.> Can the number of users launching from the home screen be tracked?
Definitely.
In the PWA's manifest, you can specify the `start_url`. This can include a sentinel to differentiate a PWA launch vs a browser session, eg
"start_url": "/?launch=pwa"
That's actually a great idea to add to Pep. Kudos.That's a non-starter for me. Google screwed me hard years ago when I was using their Adwords. I can't forgive or forget that.
If Google precludes certain users, we'll switch to something that doesn't.
Pep's not married to Google's CDN. Which other CDN(s) do you, or would you prefer to, use over Google's?
Thank you for weighing in.
I suspected it was a competitor paying some bogus group or bot network to run up my clicks and asked Google to look into it. They asked for my log files, which I sent them, but then told me "no problem found".
It cost me several thousand dollars before I realized what was going on. I shut the ad down for a few months and then turned it back on but the same thing happened again right away. I tried again to get them to look into it but got the same response. I refused to pay for those ads and they buried my site in their rankings afterwards.
There is a real beauty of using native apps. I don't like this move towards PWAs(from what I understand) - its like the developer has to put up with 3 different dists (macOS, Windows and Linux) so let's make the entire app extremely bloated, fuck the user experience and native integration and lets all go full wild wild west in the Javascript land. Developer's laziness has lead to Electron and Javascript spaghetti world we live in. I have noticed this and its controversial but everytime I see anything done in Javascript, 9/10 times it is awful and convoluted. Slow. Javascript developers appear to be a lot more inexperienced in software engineering than say a C++ developer. BootCamp courses teach you how to make bloat. Don't get me wrong - there are some good Javascript libraries but they're rare. I am sure there are a lot of good Javascript developers out there, but the general observation I've got is not very positive.
Ever used Sublime Text? Instantly different than any web app or electron app. I kind of want us to go back to old ways of doing things.
PWAs have two ways of deploying, either via the standard Web, where they get to use only Web APIs and via the manifest and service workers, get promoted to have some OS light integration with removal of the browser frame.
However, you missed the second way of deploying them, if you package the application URL alongside a signed package on app stores (Android/Windows/ChromeOS), then the PWA gets upgraded and has access to the native APIs just like any other native app.
Here is how it is done for UWP with the old Edge, the new one will eventually catch up.
https://docs.microsoft.com/en-us/microsoft-edge/progressive-...
Similar approach on Android,
https://developers.google.com/web/updates/2019/02/using-twa
If you want C++, then PWAs can also enjoy WebAssembly + WebGL (and eventually WebGPU).
https://www.qt.io/qt-examples-for-webassembly
Or just package them into the store format from above and call the native versions of GL/DirectX directly.
Progressive web app (PWA) just means that it use feature detection to enhance itself. The most notably features are "add2desktop" and "service workers". "add2desktop" lets you add the app to the app drawer, and service workers lets you manage the cache and, listen for push notifications, and acts like a proxy in front of the app, making it possible to serve from the cache while the user is offline.
Do you have a source for this? Mail content may very well be rendered in a web view (which is unsurprising given rich text and HTML are underpinnings of email), but I’d be surprised if the UI and widgets aren’t native.
> ...software engineering than say a C++ developer. BootCamp courses teach you how to make bloat...
Reeks of elitism
One would think all these companies use Pep.
But the page doesn't make it easy to understand exactly what is provided.
e.g. go grab one of the many TodoMVC[1] implementations, fork it, use your tool to turn it into a PWA, publish your changes to your fork, and let us all see the results.
[1]: http://todomvc.com