Clojure and the Web
Recorded at:
Clojure is not Lisp-2
by
Dmitry Gutov
This is blatantly incorrect. Clojure is Lisp-1.
The reason (:uri request) works is because clojure.lang.Keyword implements clojure.lang.IFn.
Can't leave out the client
by
Faisal Waris
The earlier post about Opa is interesting in this regards and there are many frameworks such as Google Web Toolkit (Java); Script# (C#); WebSharper (F#); etc.; that allow client-side javascript to be generated from the language used on the server side.
Additionally, integration with client frameworks such as Dojo, jQuery, etc. may be required.
The old models of web don't work any more and I don't think we have a good story for the new model of the web, yet.
Rich clients - like Silverlight, IOS, Android, Flash - are also on the rise putting different demands on the server side.
Brian Marick's book on Ring from Pragmatic Programmer's
by
Shree Mulay
Meat is at 19:30
by
Vincent Murphy
Re: Brian Marick's book on Ring from Pragmatic Programmer's
by
Vincent Murphy
(request :uri) vs. (:uri request)
by
Howard Lewis Ship
This handles cases where the map is nil correctly.
In addition, when using (defrecord), the record type acts like a map but does not act like a function (it can't be in the first position). So if the request was actually a record, (:uri request) would work, but (request :uri) would fail with an exception that request is not a function.
This is important, as for performance reasons, it can be nice to convert from pure maps, or (defstruct) to (defrecord).
I haven't researched why a record acts like a map, but does not act like a function.
Re: Brian Marick's book on Ring from Pragmatic Programmer's
by
Justin Forder
Re: Can't leave out the client
by
Vladimir Tsvetkov
With Flex/Flash you build a something that's purely a Client, composed from data-driven components. Components can be self-contained and highly reusable. The key to this self-containment is that the Flex/Flash components are purely client stuff that just waits for data to be set. Such Client is using the server to request/modify data asynchronously. The server just returns data. To me personally the HTML-based web apps are harder to reason about, design and componentize, simply because the server is not obliged to just return data, but it can also give you portions of the client. So the client components aren't really components, because they are partly generated from the server, partly generated from the client - and it's very difficult to design them in a way that allows them to be self-contained. They rely on both server-side processing and client-side processing. All these web frameworks are simple request/response frameworks - they don't address component-based architectures and designs where you can create applications by composing reusable components.
What do you think?




Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think