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.
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.
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.
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 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.
Besides, that's NOT dataflow programming (see old papers for Fabrik, Prograph, InterCons, etc).
