

Hoplon: A Simpler Way to Program the Web - johnwalker
http://hoplon.io/

======
STRML
Looks like a great project.

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.

~~~
nickik
ClojureScript specially has taken off. This project, then you have the
extreamly cool (but a bit hard to understand) pedestal
([https://github.com/pedestal/pedestal](https://github.com/pedestal/pedestal)),
the Om
([https://github.com/swannodette/om](https://github.com/swannodette/om))
library has made a splash even in the JS community.

A lot of exitment around core.asnyc (witch allows CSP like Go) on the web.

~~~
johnwalker
I'm really looking forward to pedestal. From what I understand the team is
vacationing, but that there are plans to integrate core.async. I do wish that
its development were a bit more public, though.

~~~
nickik
I would probebly not bother with following the devlopment to closly, I will
wait until they feel like it is realy for early testing.

Look at this talk, [http://www.infoq.com/presentations/pedestal-
clojure](http://www.infoq.com/presentations/pedestal-clojure), I think it
gives the most up to date ideas about pedastal and the next version.

------
prodigal_erik
> Reload this page with JavaScript disabled and see how the content was
> "prerendered" at compile time.

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.

~~~
nnq
> single-page apps will be the death of the web

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!
:)_

~~~
teddyh
> Sooner or later we'll standardize some RESTy way of doing it for apps

We used to have that, and it was called HTTP and semantic HTML.

~~~
coldtea
No we didn't.

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.

------
krrishd
I feel like despite the great things these projects are trying to achieve, in
the end they are just hacks. I think its time we try to shift the web
standards to meet modern needs rather than trying to build around the
limitatns right now. The web is the future, and there's no point putting off
the inevitable.

~~~
morganherlocker
At the same time, developers need to ship using the tools that are currently
available. I think a multi-pronged approach is inevitable. Of course, I say
this as someone who avoids this sort of tool as a general rule, since it seems
risky to use in production, so I definitely see what you are saying. On the
other hand, this sort of thinking would probably have been an argument against
jQuery several years ago, and despite the fact that it was a 'hack' over the
awful js standard api, it became a de facto standard through brute force of
popularity.

------
raphinou
It's a pitty they do not show how client server communication is done. Eg how,
after a click on a button, do i query a db and display its result in the page.

~~~
terhechte
There's an examples Folder on GitHub with a client/server chat demo. That
really helps figuring the RPC part out

~~~
weddpros
link : [https://github.com/tailrecursion/hoplon-
demos/tree/master/ca...](https://github.com/tailrecursion/hoplon-
demos/tree/master/castra-chat)

------
toisanji
Does this use react from Facebook? React is supposed to be the last missing
piece for clojurescript.

~~~
Touche
Doesn't look like it. Additionally it appears to be conceptually heavy. It's
hard to convince Clojure users to use anything but small libraries, even Noir
(a Sinatra-like framework) was abandoned for this reason. This might be really
good but the amount of buy-in required is a hard sell to the community.

~~~
smrtinsert
it has its own impl of rp that doesnt seem as advanced as react. I think there
have been some performance issues as well.

~~~
michaniskin
Hoplon's reactive model is quite different from React's. We think it's more
advanced :). There are no "performance issues" reported lately (there was some
confusion with an old proof-of-concept demo, but any recent version of Hoplon
will provide acceptable performance).

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.

------
acconrad
So what is the performance benchmark for Clojure / ClojureScript? I've seen a
lot of buzz for Clojure as of late, but given how bloated the web is at the
moment, until I see Clojure (or Haskell) make leaps-and-bounds better
performance in return for the pain of learning the language (and the barrier
to functional programming), how can we hope to mass-adopt this technology?

~~~
jonnybgood
Performance isn't everything and in many cases not that important. Clojure and
Haskell make leaps-and-bounds better performance than Python and Ruby which
both have mass adoption.

------
codereflection
Lost me at " Use a spread�sheet-like dataflow pro�gram�ming en�vi�ron�ment to
man�age client state."

------
jw-
For those interested in the learning more about single language web
applications the Links project
([http://groups.inf.ed.ac.uk/links/](http://groups.inf.ed.ac.uk/links/)) has
been going for some time with quite a few research publications.

------
hacknat
I like the name.

------
hmans
No.

------
ossdev1
The funny thing is that even with "Single-page applications, not documents"
you still have a document... your "single-page".

Besides, that's NOT dataflow programming (see old papers for Fabrik, Prograph,
InterCons, etc).

