Is it just me, or does it seem like cljs is making a big stir these last few weeks? After a few years with NodeJS, I've always wanted to do some more purely functional programming; I've seen a lot of buzz about Clojure/cljs and have started considering it for my next project.
A lot of exitment around core.asnyc (witch allows CSP like Go) on the web.
Look at this talk, http://www.infoq.com/presentations/pedestal-clojure, I think it gives the most up to date ideas about pedastal and the next version.
Id like to use LightTable but I'm more of a CoffeeScript guy and CS isn't built in yet. Apparently to add support you pretty much need to know ClojureScript to create a plugin, or something around that. I'll gladly write the CoffeeScript syntaxer, highlighter and a theme, as I run my own flavors in Sublime. Just need the integration to be there.
Someone help! (Please go learn ClojureScript and PR to LightTable immediately OP)
Some people have written plugins in pure js (eg https://github.com/joshuafcole/).
But when we try that, everyone piles on about how it's out of scope for web standards, and complains about how it's being done, and...
Just makes you want to throw your hands up.
To their credit, the page is not blank, unlike a lot of "web" authors out there. Unfortunately there are several links that point to invalid and nonexistent fragments like #/home/ instead of actual elements of that or some other document, which really means the framework is happy to make a siloed javascript app and does not ensure you are responsibly making all your content available as part of the world-wide web at some stable URL where third parties can reference it.
tl,dr: this encourages single-page apps which will be the death of the web.
The first sentence of the "Web Apps" section is Web applications are not documents. This is a motto that I believe a lot of people who think the way you do should take pause and reflect upon.
After years producing web apps, I came to the conclusion that non-js web apps are some of the craziest ideas ever. The browser without js is a tool to consume and, to some very minimal extent, produce documents. I consider most non-js apps on the browser to be huge hacks at best, that do what they can to circumvent the shortcomings of that technology. And heaven knows that shortcomings are a dime a dozen (lack of http method on anchors, limited to GET and POST, to only name a few).
If you do embrace building apps with js, then you need to stop thinking in the document-oriented paradigm, otherwise you'll be making some unnecessary compromises at the expense of your end users, and you'll be making your life harder as a developer. For instance, some actions that the standalone or native version of your application does with a single click might require 3 or 4 user interventions on the browser version, simply because you wish to remain true to some dogma.
A while back I've embraced the idea that web apps aren't documents. It freed me as an app developer to make choices that were otherwise unthinkable in a previous mindset. My APIs make more sense, my interfaces are more intuitive and my users are the happier for it.
Sorry, but with the exception of screen-scrapping, 99.9% of the web IS single-purpose data.
Some people imagine a magical unicorn world where webpages inter-operate etc, but that never was the case. And I don't want my Gmail data messing with my Adobe Kuler data, my Amazon data, or my eBay data anyway.
For inter-operation, we have RSS, REST, AJAX, JSON and co. Web pages themselves, as served to the end user, are not were it should be expected to be (and never was there in the first place).
> people working on such projects ought to be aware that the network they're building is competing with the web for content while being far more hostile to hacking and mashups.
On the contrary, case in point APIs: they're often distributed using formats such as JSON or XML, which weren't designed to be particularly web friendly the way HTML is. They're still much more suitable to hacking and mashups, because they go beyond the conceptual limitations of the web to fully embrace the potential of HTTP.
The only thing required for any app, even js intensive ones, to be part of the web is to provide some urls that resolve to web friendly versions of their resources and that really isn't that complicated.
"Documents" and "resources" aren't even approximately equivalent. "Resources" are more "things that can be described by nouns" than just "documents".
A document may be a representation of a resource, but the two are not equivalent.
Each resource must have a unique URI or the original web model (as envisioned by TBL) is broken.
This can be, and in many cases has been (google plus for instance), solved. It's just a matter of good design.
What en earth makes you think that? Yeah, the current way of doing SPAs without fallback for non-js clients is horrible and the alternative of a two-way site too much work.
But the solution is obvious: if what you serve is of any meaning to anyone else, you also have some sort of content consumption API. Sooner or later we'll standardize some RESTy way of doing it for apps, and for blogs and magazines RSS/Atom feeds are already good enough content-consumption pseudo-APIs.
The API will be the Javascript-less version of all sites, and all sites will have an API. Then people will make UIs for the content consumption parts of these (pseudo-)APIs, and these UIs, even if they run themselves in browsers will become the new "browsers" and gain their own scripting level features, while "old browser apps" will become today's equivalent of desktop apps.
It's not "death" of the web, just "endless, infinite pain" for us developers working in its perpetual shifting front-end... it's way worse than death! :)
We used to have that, and it was called HTTP and semantic HTML.
Nobody used "semantic HTML" to do anything serious with cross-webpage interoperability (where nobody means less than 1% of web developers/pages). As for TBL's "semantic web" that was dead on arrival.
Why? The number of customers that a) don't use javascript and b) would pay for a service only if they have a non-javascript version is incredibly small in my experience. If the service has value, non-javascript users will enable javascript to use it.
I'm ok with a SPA as long as long you also have an API. I'm also ok with a SPA as long as your app is just a content consumption app, e.g. you don't publish original content that is not accessible through other sources. But since even aggregating or re-mixing content or comments can actually be seen as creating "new content", the distinction is blurry.
My point is that we should be able to consume data on the web without having the full-browser+javascript to be the lowest level interface we have to this data.
And about the clients' interests: well, I think it is our duty as professionals to be able to see past our clients' interest too, to try and shape the future of the field we work in to the right shape, at least after we provide the clients with with good enough solutions (and yes, we should remember to stop at "good enough", because there's no point polishing a short-sighted solution, instead of working more to reshape it into a more future oriented one) and ensure short term profitability. Now, we don't all have a common notion of this "right shape" of the future of the web, but I do my best to shape it as much as I can towards "my kind of people's right shape" and push our vision up as many people's throats as we can, hopefully helping us all escape from this hell of short-sighted short-term clients' interests based decisions that brought us the current overcomplicated mess that the web is right now.
I think the days when you'd put HTML documents on the web like emails with no dynamic behavior in them are over, and have been for quite some time now. If you have content you want people to read and act on, you're going to want to develop the user experience.
Having content and apps on the web makes perfect sense to me, but I can't help but think we need to do something different in terms of delivering apps over the web. The problem is, the browser itself is the only "runtime" that's guaranteed to be available in all browsers on all platforms. Something like Java had tons of promise at one time for handling the "app" side, but Sun screwed the pooch by not shipping a JVM with reasonable startup times until years too late, and missing the boat on security. Now Java has a such a bad rep as a consumer-facing tech, that it would be just-short-of-impossible to revive it, even though it's probably still the best solution for "apps over the web" in many ways.
Maybe Google's NaCl / PNaCl will eventually help, but I'm not holding my breath.
The reason I suggest this might happen is that for years we've been trying to get away with munging the visual design while still preserving the notion of the document. Web apps take it to the extreme where documents are most often deliver as pure data (i.e. JSON). This move towards having all content as pure data is a great first step towards supplying the content for a pure text only framework.
I like this possible direction the world can take much more. Progressive enhancement was flawed from the start. Let interfaces be super rich, but supplied by content in pure data form that can also be delivered via the simplest interface ever, like basic semantic HTML.
Hoplon isn't optimized for "perf" in rendering things on the screen. Hoplon is designed to uncompromisingly optimize developer performance. I know that when my users are presented with a choice between more rendering perf and added features in the application it's a no-brainer. They just need good performance, but great features.
Hoplon presents a model in which web designers and programmers can coexist without friction, and it provides the underlying foundation for developing truly powerful abstractions (like components, for example) that are composable in ways that are impossible in other systems.
Besides, that's NOT dataflow programming (see old papers for Fabrik, Prograph, InterCons, etc).
