Google's AMP Project - January 2016

Hilarious. Publishers need to rely on other companies to serve fast web pages on mobile. That's because publishers create some of the worst designed and most bloated websites on the internet.

Here's how to speed up an article page:

• use no javascript
• cache the page

I'll have to see if AMP speeds up an article page that is produced by my Grebe, Scaup, and Veery web publishing apps.

• http://toledowinter.com - built with Grebe
• http://babyutoledo.com - built with Grebe
• http://crochet.soupmode.com - built with Scaup
• http://veeryclientperl.soupmode.com - built with Veery

I use memcached to cache article pages and page one of the home page stream. That means that a user will interact only with Nginx and memcached.

If the page is not cached, or the user hits page 2 or higher of the home page stream, or the user conducts a search, then my apps pull the content from a database, such as MySQL or CouchDB.

If it's an article page that is not cached, then my code knows that and places the article into cache. A refresh would get the article from memcached.

Veery and maybe Scaup will cache page one of the home page stream if it was not cached. For Grebe, page one of the home page stream gets cached when an article page is created or updated.

When I'm logged into one of my web publishing apps, then each article page is dynamically created by being retrieved from the database.

And when I'm logged in, I access JavaScript only when I use the browser-based JavaScript editor, which is what I'm using right now to create this post in my Junco app.

Junco does not cache content.

I love, actually thoroughly enjoy writing on the web by using this JavaScript editor that I "created" by downloading someone else's code and greatly modifying it.

The editor that I downloaded was a Textile live preview split-screen editor. I disliked the distracting live preview. Plus, my apps support Markdown/MultiMarkdown and my own custom formatting commands, and I didn't want all of that smarts in the client-side JavaScript. I have no problem with using the server to render content. It only takes about one second. What's the issue with server-side rendering?

I modified the JavaScript editor to support an optional single-screen mode. I added buttons to the top to support these options. I added keyboard shortcut commands for previewing, saving, and switching screen modes.

I added a true full-screen mode. I added a narrow, five-line screen mode.

I added the ability to change from dark on light to light on dark, regarding text color and background color.

I added autosave to the editor. By default, the editor saves the markup every five minutes. I can change that time by using the autosave= command and then specify the seconds. Autosave kicks in when an addition or deletion is made. If no changes, then no autosave.

I used the minified.js framework to implement most of my changes to the original JavaScript editor.

I should someday rewrite the editor to use only one JavaScript framework and to eliminate code from the original editor that I no longer need.

I mainly write in splitscreen mode, which allows me to preview the page in the right pane. But at times, I also write in single-screen mode but not in full, single-screen mode.

The nice thing about the editor is that I can use it on my iPhone 5c to create and edit pages. On the phone, I write in single-screen mode. Split-screen is too small on the phone.

And I enjoy using a database. It makes for easy searching. I tag heavily. I often use string and tag searches to find my content.

Using a database makes it easy to create and edit content from any device. I don't need to be tied to only one machine, such as a laptop/desktop.

The database makes it easy to store versions and conduct differences and revert to old versions. This exists in my Junco and Grebe apps. I should add versioning to Scaup and/or Veery, which use CouchDB and Elasticsearch.

Grebe and Veery store markup to the file system. That's another backup option.

I use memcached to speed up page display and to make access as fast or as nearly as fast as accessing a static HTML page.

Geeks love using web publishing apps that write pages to the file system and do not use a database. I think that they like to use complicated things.

Using an SQL or a NoSQL database makes life much easier for me. I'm about designing to make things easier to use.

I wonder if accessing a memcached page is faster than accessing a static HTML page on the file system.

Wouldn't the web be significantly better if publishers created simpler article pages by using text as a design technique?

Progressive enhancement. Responsive design. No JavaScript for users who are not logged into the site. Simple CSS. Simple HTML. A lot of negative space to allow the article to breathe. Comfortable line width, line height, paragraph spacing, and font size on ALL devices. This all ends in the trash can if the publisher uses a microscopic font size on phones, which many responsively-designed sites do use for some idiotic reason.

It's as if designers/publishers follow some nutjob paradigm that believes that the smaller the device, then the smaller the font size. Why? No, don't do that. Not everyone that reads a site is 20-years-old with perfect vision.

I use a large-ish font size at http://babyutoledo.com to make it read easily and comfortably on phones.

AMP-related Links

• https://amphtml.wordpress.com/2015/12/09/continued-momentum-for-the-amp-project/
• https://engineering.pinterest.com/blog/building-faster-mobile-web-experience-amp - pinterest is possibly the worst website that i have encountered. it's broken, in my opinion, intentionally to encourage people to user their native apps. why in the hell would pinterest be interested in AMP?
• https://www.ampproject.org/
• https://www.ampproject.org/docs/get_started/create_page.html
• https://amphtml.wordpress.com/2015/11/24/bringing-you-up-to-speed-on-amp/

---

https://news.ycombinator.com/item?id=10929970