
Show HN: Building a zero-latency WordPress front-end - chungleong
https://github.com/trambarhq/relaks-wordpress-example
======
chatmasta
This is cool, but the end result is you are basically using WordPress as a
document store. Because you need to implement an entirely custom frontend, you
lose various wordpress templating abilities. Granted, that might be a
worthwhile tradeoff.

~~~
lukifer
Honestly, the sophistication, usability, and hackability* of modern wp-admin
makes it worth the price of admission alone (even considering the performance
hit from awkward wp_posts schema). I once used a siteless WP as a CMS for a
lean CodeIgniter mobile app JSON API.

* Hackable in the positive sense; WP has its security reputation for a reason, but the majority of vulnerabilities are attributable to third-party plugins and themes.

------
Theodores
It serves div soup rather than modern HTML5. I am a stuck record on this topic
but I think your document structure needs to come first. Simplicity always
trumps complexity when it comes to speed, no matter what the discipline.

~~~
zamadatix
Does it matter what it serves considering it's written in something completely
different and the output is generated by a server not a human?

~~~
Theodores
Yes if the benchmark is speed. The new browser layout engines are quicker than
the old floats and divs with billions of class tags. Plus the quickest
download is always no download.

Then there is the matter of maintaining the content. Div soup has to get
chucked down the drain for the new agency or developer to make more div soup.
It is worthless.

Meanwhile, a document with proper markup and judicious use of semantic HTML5
tags is content with value that can be easily re-styled.

SEO matters too, pure speed matters but so does document structure. Hiding
your content in div soup does not impress the Googlebot.

Next?

~~~
dangerface
> The new browser layout engines are quicker than the old floats and divs with
> billions of class tags.

Can you back that up with benchmarks?

------
martin_a
Interesting, but somehow missing a point for me. You can have quite fast
WordPress pages without rolling out this big of a tech stack.

It all comes down to a good theme (most themes are not good) and utilizing a
little bit of tech, most of which is already integrated into WP.

For example, I love the Transients API. You can easily cache database calls
for posts with the Transients API and save lots of lookup/query time for
complex datasets. One could argue that the Transients API is not meant to be
used this way but I've build large sites which run fine (and fast) with that.

In the end it comes down to making smart choices: No tracking, few
dependencies, minify all your assets, use browser caching, use scaled images,
the whole toolset of good practices.

This will get you fast WordPress pages without worrying much about the tech
stack you have to build around it.

~~~
chungleong
The setup is more useful in a mobile situation, where latency is high and
connectivity isn't so certain. Imagine you're travelling by metro and reading
something on your phone.

~~~
martin_a
That doesn't make sense. You have to deliver the whole markup and assets in
one way or another. Keep it small so it gets transfered quickly, even on a
slow connection. Once it has been transferred, you're done.

------
pushedx
Live demo is hosed at the moment. I think you should host the one that allows
cache purges on a separate instance.

~~~
chung-leong
The server might be hitting the open file limit or something. A lot of sockets
get opened when the server generates an HTML page.

~~~
chungleong
Forgot to close file handle. JavaScript-induced rotting of the brain :-p

------
edpichler
This is beautiful. It is an example that how good are fast web pages.

------
oreuveni
What magic is this? I've never seen a WP site comes close to these speeds.
Incredible.

