NOLOH (not one line of html) Beta Program
noloh.com
noloh.com
Applications where the UI is always dynamically generated based on the user, the state of the application and data, etc. are probably far more comfortable using JavaScript generated by code. Obviously others are going this route, as well. GWT uses programmatic generation of UI elements, for example, though it does so by compiling Java down to JavaScript (kinda).
I'm not going to rush right out and start using nohloh (I don't enjoy working in PHP, and most of my work is on existing apps), but I certainly see value in the idea. And, in fact, most of my work lately has been on converting a huge application to be friendly to using almost nothing but JavaScript for the front-end (it's an installable systems management app, so I don't have to worry about spiders at all, and the UI was never template based as it is dynamically generated based on all of the criteria mentioned above).
Anyway, looks pretty neat.
I find this site seems to be more trafficked than it was previously, but the noise to signal ratio has gone through the roof.
The part of non-technology related stories has increased trendemously, when some people point it as "non-HN", there are answered the Community Card (they forget Community and Common are two very close words). PG is non-existent has a spoken moderator who tells the rules when it's appropriate to do so (his absence is eminently suspect).
More importantly, a lot of the old users keep their mouth shut now, some have completly disappeared for obvious reasons. Most of them are prolly still reading HN but the idea of posting a comment has become tiring for them. The battle is already lost, but not for everybody.
Two minor quirks: Back and forward button cause an ugly sort of refresh. And I forgot what the other one was because it just looks and feels so nice.
I hope this type of stuff gets more widespread. I also hope that browsers don't screw it up, as they're likely to. (Works well in Firefox 3 for me)
Any chance you could show the PHP source to the doc viewer page http://www.noloh.com/Docs/#/section=apireference ? I'm assuming that's a NOLOH application which would give everyone a more substancial idea of what it's really like to work with your class hierarchy.
Throughout this month you'll see it evolve into what we think will be the most easy and intutive developer documentation experience, at which point it will be open for all to see and use.
Constructive comment: I can't middle click links to open them in new tabs.
P.S. You're not getting too much enthusiasm for it here because of the choice of PHP. I can assure you, though, if this takes off, a lot of those "can someone build me a Joomla or Drupal site?" on eLance will rapidly turn into "can someone build me a Noloh app?"
You're right about the tabs, that will be implemented in the next update to the website. We're planning to release Ruby and Python versions of NOLOH at some point.
Also, the crawler-friendly URLs are different from the URLs the search engines will see reported by users' toolbars or discover on inlinks from other sites. So various link- and traffic- based contributions to rankings are likely to suffer on Noloh-style sites.
I browsed a few clicks in as 'Googlebot'. Rather than typical website links with many targets, and useful anchor-text, each page had only one substantive link, with minimal query-string-like anchor-text (like "section=features").
If a bot reached the URL "http://www.noloh.com/index.php?section=features", and then that URL appeared as a search result, and then users visited by that URL, they would then (upon navigation) find themselves at odd composite URLs like "http://www.noloh.com/index.php?section=features#/section=bet...".
Meanwhile, if crawlers discover inlinks from other sites that users have copied and pasted, like "http://www.noloh.com/#/section=whoweare", a crawler will only see this as a link to the root page.
Your pagerank is going to be diluted over these arbitrarily different URLs, and traffic analysis via toolbar reports is not going to boost key target pages as strongly as in an application with traditional stable URLs.
So I was pretty excited to try it until I realised that if that is the case - this is probably the worst SEOed site I have ever seen, it literally has no SEO.
Its a good idea, but personally after the usability of a site, it being nicely SEOed is really, really important.
You don't need to commit to any type of support, you'll probably get a lot of useful feedback and, if it's good, some free publicity too.
If it's the former, please ignore my comments :) If the latter, I for one would be playing around with the code right now if there was a download link... A few examples in a README file would do fine for now. Release early and often, as they say ;)
It would be hard for users to do significant work with NOLOH when the code is hosted on your own server and updated automatically, possibly breaking code they added.
The Beta Program is setup to allow us to work closely with a small group of developers so that we can help them develop their applications in NOLOH. If any updates during the beta program break an application we will work with the developer at our cost to fix the problems.
We have lots of documentation, articles, videos, etc, to put together before we can offer it to non-commercial users which is what we hope the beta program will help us accomplish.
Btw, i prefer haXe (haxe.org) as a true unified web language ;-)
haXe is only unified in the sense that it has support for JS, Flash, and a few other languages. But going through their tutorials (for example, http://www.haxe.org/doc/js/ajax) you still see that you have to write mark-up. So all of the traditional problems that NOLOH is designed to address still persist in haXe. Mark-up is static, error-prone, not intuitive for application development, interpreted by browsers differently, and the list goes on and on...
Well... it would benefit Google (and its users), because they could detect and punish cloaking. How would Google detect cloaking? A clerk examining the two served versions, or automagically comparing the two versions of served content? How smart would their comparing algorithm be? Could it determine that your site was not being deceptive? How would you write such a algorithm (and it better be generic, and difficult to exploit)?
Basically, I have no idea what the hell Google does and does not do, but I am scared (and ignorant) enough to always serve search engines exactly what I serve users.
NOLOH == Not One Link Opens Happily?
Tried viewing traffic in Live Headers and script in FireBug to see what was going wrong; attempting a direct fetch of one JS URL fetched came back with a script that was just a comment: "/~NScript~/".
Do you use NoScript?
Add-ons installed there are Firebug, Live HTTP Headers, Tree Style Tab, and User Agent Switcher.