Static site, using no server side scripts, just a .htaccess file #43

merged 15 commits into from Oct 13, 2011


None yet
4 participants

SvenDowideit commented Oct 11, 2011

need the

It shows up that in local edit mode, we still expect that there is a server to talk to - will fix that later maybe.

this is an offshoot of the simplification I was doing to make a Smaller-than-Smallest-Federated-Wiki

the node.js code begs a couple of questions:

  1. are you wedded to haml and sass? neither work well in node.js - scss (sass v2) is likely to be better supported, but I wasted the better part of a day trying to get them working before giving up.
  2. how important do you feel the non-javascript html output is? if we can discard it, we won't be maintaining the same functionality across client, ruby, arduino, node.js and (though it will become plausible to make callable from the node.js

asolove commented Oct 11, 2011

It seems fairly important to be able to render static pages, for the benefit of users who don't have javascript. I would like to suggest moving the page rendering into a template format (perhaps Handlebars?) that can be run on both client and server.


SvenDowideit commented Oct 11, 2011

I strongly agreed that html output was important between 1990 and 2006, even killing some of my research projects in TWiki for this reason, but in 2011, I would like to ask honestly, can you be specific wrt seems fairly important .. for users who don't have javascript?

I'm not sure about it for several reasons -

  1. imo it will slow our development & learning down at this early stage to have json->html rendering in every server and client codebase - ok, clearly, its going to slow my efforts (but if there's a clear we must have server side rendered html then I will cope
  2. is the set of non-js users sufficiently non-trivial? (i ask because i have no data - links will help me)
  3. does non-javascript federated wiki actually work as a consistent and useful UI right now (or should we remove it, and bring it back at a later stage)

yes, I am conflicted, but after 20 years of writing web renderers (eeeek), I've leaned heavily into leveraging client side js.

leto commented Oct 11, 2011

Just as a data point, I disable javascript on my phone for security purposes and to increase battery life. I assume many others do as well.


SvenDowideit commented Oct 11, 2011

fair enough, but what do you expect a client js heavy federated wiki UI to work like in that environment?

and as per 3. does it function now, or are there issues.

I also turn off javascript at times, but i also don't expect the entire web to work..

(leto - I'm asking for specific datums as applied to federated wiki development now, so that we can make a reasoned decision)

I'm biased by the fact that implements a read only federated wiki using just apache rewrite rules - so there's an index.html, a style.css, client.js and jquery, and a pile of json files in /data/pages... (I'll do more to simplify our codebase for that and the node.js server)


asolove commented Oct 11, 2011

If you think that this is going to slow down your work, you should feel free to make everything work without server-side rendering and I will be happy to spend the time making the server rendering work.

  1. If we write the template in Handlebars or some other DOM-independent js templating library, we can very easily run it both on the client and server.
  2. About 2% of visitors to Yahoo have javascript disabled:
  3. There is an important difference between functioning as an editable wiki (which perhaps should require js) and functioning as a static web page. If I run a wiki that becomes as important as Ward's patterns wiki, and someone links to a page on it, visitors should be able to at least read the linked-to article without javascript, though they won't be able to edit it or use any of the advanced javascript features.

SvenDowideit commented Oct 11, 2011

mmm, one thing - will Handlebars help with the ruby and C based servers?

the thing i may not have emphasised enough is that the pain I had in doing the node.js implementation is because it is not the only backend (and i really want them all to use the same templates/html/css)... (and the static file one, is a really nice example of how far we could go)

even so - everyone seems to think that having html output is important, so there we go - its easier to design and architect with one goal, and at cross purposes - I'll just have to think harder on how

if Handlebars works for the C, ruby, Perl (that i might need to write for other reasons), node.js, .NET, and java, then its a very good fit... HAML seems to be mostly ruby :/

SvenDowideit added some commits Oct 11, 2011

@SvenDowideit SvenDowideit use a jquery UI Dialog to show the json source for a topic, rather th…
…an navigating away - in the process update to jqueryUI 1.8.16, and add all the pre-req's for UI Dialog - including icons that we might not need
@SvenDowideit SvenDowideit update static.html to use new jquery.ui-1.8.16 f57b269
@SvenDowideit SvenDowideit update static 'server' to use the source popup dialog 79f616e

WardCunningham commented Oct 12, 2011

My thought is that items of type paragraph and type image should be rendered in html so that search engines can see them. I don't bother with even this when its inconvenient. Also, I'm not wedded to haml and sass since they seem to play a small part.

@WardCunningham WardCunningham merged commit 79f616e into WardCunningham:master Oct 13, 2011


WardCunningham commented on eed98da Sep 10, 2012

The client code now does the right thing for a 404. Can we get rid of missing-page and revise the rewrite rules accordingly? Or is this code completely obsolete?

Here is what I've been doing to serve static json only with apache:

paul90 referenced this pull request in fedwiki/wiki-client Jun 18, 2015


Using the client without a server #123

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment