Solving this is pretty simple, forget about disabling Javascript, uninstalling fonts and other complications: just change the User Agent string ( http://is.gd/7db0G ) to something random (or your fullname).

If you want to do it in Chrome forget about hex editing files nonsense. Just run Chrome like this: chrome –user-agent=”Mario Valente User Agent”

Result: “Your browser fingerprint appears to be unique among the 77,330 tested so far.”

“mvalente: Pq Flash vai morrer: acessibilidade, UI diferente, SEO, -speed. E pq js+css faz tudo”

“mvalente: Nao discuto :)… Em 5 anos o Flash vai estar no mm “nicho” em q estao as Java applets (ie. +- nulo)”

“mvalente: Who needs AIR, Flash, Silverlight, JavaFX and other crap http://is.gd/bKQb JS + Canvas, baby”

Feel free to search for Flash in my twitter archive (starts in March 2007 ends in February 2009; I dont chat on twitter anymore) http://mvalente.eu/Files/mvalentetwitterhistory.html

Aditionally, 2 years ago I hinted at the need and possibility that Javascript should be used at in all of the tiers of aplication development. And 1 year ago, at Codebits, I restated the need for a totally Javascript-based, REST-accessible, JSON-formatted web development framework. I tried to challenge people at Codebits to work in it, but no such luck. I also tried to start developing it but it was a no go: I dont have as much patience for coding as I used to (age is a bitch) and the context for serverside Javascript development just wasnt right (lack of standards, lack of OS API access, etc). And even having some Javascript interpreters (like jslibs which is what I was using at the time) with access to stuff like files and sockets wasnt much of a help: its not very much fun to try and reinvent the wheel writing a webserver from the (socket) ground up.

Well, things have changed a lot in this past year. The ServerJS/CommonJS group has been doing a lot of work on standardising a unified JS API. And there’s been a lot of work done on top of several Javascript interpreters/compilers/VMs (like Spidermonkey, Rhino, V8, etc) to provide for basic system level functionality. Plus a lot of Javascript-based basic blocks have been developed (like Narwhal, Nitro, Node, Awesome, Lawnchair, DjangoDE, PURE, etc) that allows us to get more concrete about what is needed and what can be done.

So its time to once again tell the Lazyweb what I think is needed or (better yet) what I want in a new web development framework that lasts for 10 years. Here goes:

• I want it to be Javascript based. All of it. No Erlang, Python, Ruby, etc in sight. I want the frontend/View/presentation in Javascript. I want the appserver/Controller/logic in Javascript. I want to program the appserver in Javascript. I want the DBserver/Model/data in Javascript.
• I want all the Javascript code to be compliant with the CommonJS standards. The code should be portable to any of the existing engines (Spidermonkey, Rhino, V8, flusspferd, Jaxer, Helma, etc) although I would touch anything Java-based with a long pole, so please make it work on Spidermonkey or V8.
• I want all the data to be JSON formatted and REST-accessible. The data on the database should be stored as JSON data and accessible via REST. The appserver API should be REST-based, accept JSON-formatted parameters and return JSON-formatted results. The templating system should accept JSON-formatted data for rendering the view and make REST JSON-formatted calls to the appserver.

If this isnt clear enough, let me refer some analog components that are written in other languages and what is already available in JS:

• for the database I want CouchDB but written in Javascript. Awesome or Lawnchair might be starting points. The endpoint would be something like Persevere but without the Java/Rhino dependency. Maybe Pintura is *it*…
• for the appserver I dont have the right analog. Of course that it must support JSGI. But *the* most important thing: it can not and must not allow the generation of HTML and the return of HTML to the browser/client! All methods/functions should only accept parameters and return results in JSONified format. Maybe NitroJS could be *it*. If it threw away the sucky template format. Completely. No templates on the serverside. No serverside HTML generation. Pure HTML is the new template standard (see below).
• URL routing should use the object hierarchy on the appserver as default. Explicit URL routing (static or using regexp) would have to be done explicitly.
• for the presentation layer I want pure HTML+JS. The browser should be the only component responsible for rendering templates. The clientside part of the framework should make all calls to the server using REST/AJAX and providing JSON-formatted parameters. No GET or POST parameters. It should only accept JSON-formatted results. No HTML. Standard HTML is the only templating system needed. Page elements (DIV, SPAN, etc) should have an “id” as an identifier for serverside databinding. If a page has a tag/field with “id=xpto” then that tag/field should be filled with the contents of the “id” key returned from the server in a JSON string. A good starting point would be PURE, but without using “class” as the databinding identifier (”id” should be the standard).
• I want the appserver to have features that Zope has had for years: I want acquisition (aka prototype-based programming, aka JS object-orientedness). I want a through-the-web management interface. I want ZClasses. I want automatic form generation for classes/objects and an automatic management (CRUD) interface for objects.

So, how’s that? It’s Xmas anyway, so I can ask for whatever I want. Gimme, gimme… Or I can start working on it… Who’s with me? I can be the Main Bitcher, Overall Architect and Project Manager.

Não serve nem deve servir. A Internet serve o individuo, transfere poder das organizações e do colectivo para o individuo. Uma afirmação colectivista e socialista cuja consequência lógica é a submissão da Internet a uma qualquer entidade supranacional (ONU? EU?) e a retirada de direitos digitais aos cidadãos (confidencialidade, anonimidade, privacidade).

“A tecnologia não resolve problemas, as pessoas resolvem problemas.”

Precisamente. Pessoas. Possivelmente agregadas em grupos por vontade própria. O que não resolve problemas: colectivos impostos, partidos e políticos, entidades supranacionais e supraindividuo.

“Os políticos do presente e do futuro têm de orquestrar a inteligência colectiva.”

Não têm nada. A inteligência colectiva orquestra-se a si própria. A inteligência colectiva de uma colónia de formigas não é orquestrada por ninguém. A inteligência colectiva de um cérebro também não, não é preciso ninguém a orquestrar os neurónios.

“Devem impor-se pela confiança. O seu desígnio não é um conceito de justiça meramente formal, mas o desenvolvimento das capacidades para que cada um atinja o seu potencial.”

Cá está. Mais uma das várias afirmações que trai o tom geral da entrevista, um tom de descentralização, poder distribuido, capacidade dos individuos. No fundo, no fundo, as pessoas e cidadãos são umas bestas que precisam que os politicos se imponham e lhes orquestrem a vidinha para que possam atingir o seu potencial.

Para além do discurso bonito, é uma agenda compreensivel para quem representa não só uma multinacional mas também o poder politico (um partido).

Em tudo o resto é uma boa entrevista.

This goes agains the theories of attention economies: “…in an information-rich world, the wealth of information means a dearth of something else: a scarcity of whatever it is that information consumes. What information consumes is rather obvious: it consumes the attention of its recipients. Hence a wealth of information creates a poverty of attention and a need to allocate that attention efficiently among the overabundance of information sources that might consume it”.

I dont think that there ever was an attention shortage. Maybe in medieval times or up until the early XX century. But since then, I believe that the supply of attention has been more or less constant. At least from the producer’s side which, in this case, is the consumer. Confused? You see, it is us who are usually consumers that produce attention; media companies buy it from us, they are attention consumers (pun intended). And in at least the last 50 years we’ve had more or less the same ammount of attention to suply (ie. the time we spent watching TV or reading the newspaper).

The attention shortage was only apparent due to the fact that the market was ineficient, cornered by big media companies, with only major players playing it. And thus media companies made a lot of money by buying attention cheaply (from us) and selling it with a large profit margin to advertisers who didnt have any other choice for buying attention.

If anything, there was a consumer surplus: media companies were benefitting by being able to purchase (consume) a product (our attention) for a price less than they would be willing to pay (ie. cheap).

The truth of the matter is that, while the supply of attention has been more or less constant, competition for segments of the attention market has been hugely increased by the Internet. Before the Internet, only big companies were able to produce attention-consuming products and thus distorted the attention market. With the Internet we have watched a huge decrease in the costs of producing attention-consuming products. That has increased the number of producers who are now fighting for a piece of the attention market. This is the problem that TV and newspapers are facing. And the Internet has also increased our ability to find and acquire (ie. spend our attention) this wealth of attention consuming information produced through the Internet.

That doesnt mean that we will now shift to a market where we, as attention producers, will get a better price for our attention thus creating a producer surplus. Far from it. The fact that our attention can now be acquired more easily and that more people are producing attention actually means that the value of our attention is getting smaller.

In short: the attention market is being subjected to increased competition and is being driven to near-perfect competition, to a market equilibrium. At this point the previous consumer surplus (the media companies advantage) is reduced to zero as well as economic profit. There is no surplus, no economic surplusses, no aditional attention created. The Internet is just allowing for an efficient market for producers and consumers to match each other. A long tail market…

Like Seth states, the unanswered question is how to address this long tailed attention market and do something profitable with with the available attention. I’m pretty sure that marketers will get smart before long and will know how to take advantage of the hyperlocal, hyperspecialized nature of every long tail market. And hopefully stop producing funny comercials with chimps. Although I disagree that the media companies are doing a much better job. They are looking at specific audiences, handfuls of tiny micromarkets. Which, I think, makes sense from their perspective as producers of attention consuming products.

But I believe that the “problem” (or opportunity) to crack is something much bigger: what do you do when attention is no longer scarce? How can one take advantage of an abundance of attention? How can one create economic value and advantages and make money in an efficient market?

Maybe the answer isnt trying to play the market. Maybe the answer is to become the market. Or at least to provide its marketplace infrastructure. Open Attention Exchange anyone? I’d go into it if I wasnt focused on other things…

As usual on the Internet, the same idea seems to bubble up
from several people all at once.

For the last 2 years or so, I’ve been thinking a lot about
web app architecture and app server frameworks. My thinking
has led to an approach that I’ve been trying to explain in
some previous posts.

But now Peter Svensson has given it a name:

Thin Server Architecture
http://unclescript.blogspot.com/2008/02/thin-server-architecture.html

Sounds like a nice buzzword and a nice TLA: TSA.

Peter has gotten together a group of people (me included) and
kickstarted a working group, already working on putting up some
clustered information in a place of its own:

Thin Server Architecture Working Group
http://www.thinserverarchitecture.com/

Meanwhile, while researching on the subject, I got a couple of
aditional links that are important for our thinking and for my
continuing posts about a future web framework:

How Nexaweb Works
http://www.nexaweb.com/home/us/index.html@cid=2295.html

Developing Rich Internet Applications with Declarative Markup
http://rockstarapps.com/wordpress/wp-content/uploads/2007/08/java-basedria.pdf

Slides 6-9 are especially interesting. In slide 9 you can easily see
what TSA is all about: its represented by the 4th stack, the one where
the app container has only UI stuff (view+logic) and server side you
only have biz logic and data.

— MV

I should start this post (hopefully the last detail before
going into a synthesis post) by remembering some words from
my initial post in this series:

“Meanwhile, lots of stuff has come up: Django, Pylons,
TurboGears, Ruby on Rails, you name it… I dont want to
go over extensively why I dont like any of them, but let
me just state this: if the “framework” allows for the
mixing of layout/design/HTML with code/programming, for
me is enough of a disqualifier.”

The problem, as I stated before, is that current frameworks
stuff a lot of power into the templating languague. And that
is not only unnecessary but its a bad, bad thing.

If you dont understand why 1) embedding Python/PHP/Ruby/etc
in HTML is bad or 2) outputting HTML from Python/PHP/Ruby/etc
is worse, I’m not even going to try and explain. Not only
because that means you are clueless but also because someone
else has done it better that me:

http://www.stringtemplate.org/about.html
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

Now the problem is that although I agree with this paper and
the rules set forth in it, I disagree with the implementation.
Allowing for “$var” statements in the templates is still, in
my view, some form of entanglement and breakup of the MVC pattern.

What would be the best way to do it? Well look no further than
some already existent template engines:

PyMeld
http://entrian.com/PyMeld/

HTMLTemplate
http://freespace.virgin.net/hamish.sanderson/htmltemplate.html

Meld3
http://www.plope.com/software/meld3

They allow for the insertion of values (data binding) through
the use of HTML element attributes. Both HTMLTemplate and Meld3
create new attributes (”node” and “meld:id” respectively) but
PyMeld does it better: it simply uses the “id” attribute to do
value replacement. This is, in my opinion, the best way to do
a templating system. And there’s no need to make it “powerful”
through the introduction of loop control and other stuff like
Genshi or Zope Page Templates.

Does this mean that I have found my perfect templating engine?
No. You see, these are serverside templating engines and the
template/view should be implemented at the client level, if you
want to adhere to the MVC pattern.

What I would like is something like these templating engines:

Ajax Pages
http://ajax-pages.sourceforge.net/

Javascript Templates
http://www.fishwasher.com/jst/

Trimpath Junction Javascript Templates
http://code.google.com/p/trimpath/

Unfortunately all of these engines make the usual mistake of
introducing new syntax to HTML (the “$var” problem or variants
thereof instead of relying on the existing HTML markup, namely
the “id” element markup.

To sum it up, what I would rely like is a Javascript implementation
of Meld.

Aditional templating functionalities that might not be provided
through the use of the “id” attribute (although I think that it
would be all that is needed) could be added through the use of
aditional semantic potential to existing HTML markup with Javascript.
See for example Inc, for JS code include (although I would prefer
for this to be done through the implementation of the “src=” attribute
for DIVs.

http://johannburkard.de/blog/programming/javascript/inc-a-super-tiny-client-side-include-javascript-jquery-plugin.html

— MV

Like I said before, most of the week’s linkage
has had to do with CouchDB or, generally speaking,
to do with JSON-formatted REST-accessed database and
application servers.

http://mvalente.eu/cat.cgi?JavaScript%20in%20All%20of%20the%20Tiers
http://del.icio.us/mvalente

CouchDB is sure fun to use, but its Erlang dependency just
pisses me off.

http://couchdb.org/
http://code.google.com/p/couchdb/
http://jan.prima.de/~jan/plok/archives/108-Programming-CouchDB-with-Javascript.html

The way that I’ve been thinking about a new web development
framework indeed involves a REST interface and JSON or XML
formatted data. But I just think that a) you might as well
standardise the programming languague used at all tiers (and
that means Javascript) and b) you should have REST/JSON as
interface not only to the DB tier but also to the logic tier.

Sure enough there are some alternatives if you want to go
that way.

Basura DB (Python based JSON/REST DB implementation)
http://www.intertwingly.net/code/basura/
http://intertwingly.net/blog/2007/09/24/Tests-Id-Like-CouchDB-to-Pass

Persevere (Java based)
http://code.google.com/p/persevere-framework/
http://www.ibm.com/developerworks/web/library/wa-aj-objmap/

Robaccia (Python based web framework includes a RESTful JSON server)
http://bitworking.org/news/restful_json_server

JSONStore
http://taoetc.org/97

DBSlayer (HTTP/JSON interface for MySQL databases)
http://code.nytimes.com/projects/dbslayer

But aditionally to databases, I’m thinking more in line with
the proposed RADAR architecture of having the REST interface
also available for the app server. There arent as many options
here…

The RADAR Architecture
http://pragdave.pragprog.com/pragdave/2007/03/the_radar_archi.html

Naked Objects
http://www.nakedobjects.org/tutorial/index.shtml

NetKernel
http://www.theserverside.com/news/thread.tss?thread_id=47695
http://www.1060research.com/netkernel/

And sure enough all of the above is typically Java-based (yuck!),
with some other languages thrown in (Python, Erlang), but none
goes all the way and standardises on Javascript as the implementation
language and the glue language. Apparently I am not the only one
considering this idea…

Alt Framework
http://marcello.cellosoft.com/projects/alt/

Simile’s Exhibit Framework
http://simile.mit.edu/exhibit/

— MV