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 Gre