Well, definitely on the ClojureScript side of things your best bet at the moment will probably be one of the various wrappers around Facebook's React library, of which the main contenders are currently Om and Reagent, in addition to several different thin layers over react. You can develop complex single-page apps in these as easily as you could in any number of robust javascript-native frameworks.
If you don't have much experience with web development already, I'd personally suggest re-frame, which builds a model for handling state management and events on top or Reagent, and which will insulate you to some degree from the complexities of React itself. You should also check out Om. As far as pre-built components go, for Reagent there is the re-com library which has a variety of buttons, containers, and other handy widgets. You also have the whole universe of React javascript components to choose from, and the ones which are built into Google Closure, though it can be a little tricky to get the ClojureScript interop right. One thing you should be aware of if you're developing a client-only app is that it can be difficult to get pure-browser applications to interact with things on your filesystem due to security restrictions. You might be able to get around some of these by loading the page up at a file:// URL, but behavior tends to be inconsistent across browsers and you're likely to run into problems. Partly for this reason, many applications that use a browser as their UI ship with a small server component that serves pages on localhost, which the front-end then communicates with in order to do various I/O-related tasks (SABnzbd works like this, for instance). You can of course use Clojure for the back-end and possibly share code on both sides of the stack, but then you get into the various complications of distributing a desktop Java application. Of course, in theory there's nothing stopping you from writing a complex single-page app in jquery or ember.js or any number of different javascript frameworks, since you can interoperate with relative ease. As far as the state of the art goes, though, my strong impression is that most of the focus in the community has been on Om, React and their peers. On Friday, July 24, 2015 at 1:01:23 PM UTC-4, Gary Schiltz wrote: > On Friday, July 24, 2015 at 2:00:28 AM UTC-5, Gary Verhaegen wrote: > > On Thursday, 23 July 2015, Gary Schiltz <[email protected]> wrote: > > If I were writing it in Swing for the desktop, I'd create a top level > > frame, populate it with a bunch of nested panels to group widgets like > > buttons, text fields, text areas, etc, use some layout managers to make it > > display nicely when resized, and attach event listeners to the interactive > > widgets. I could use seesaw (https://github.com/daveray/seesaw) to write in > > Clojure instead of Java to interact with Swing. Is there an equivalent > > ClojureScript library that similarly interacts with some JavaScript widget > > library? > > > > React/Om works mostly like that, except that you use CSS as your layout > > manager. I'm > > not too sure about accessing files directly from a webpage, though. There > > may be security > > restrictions there. > > > > If you want to do anything with web technologies, you really have to spend > > some time learning > > HTML and CSS, even if you don't intend to write them yourself. Maybe in the > > future there will > > be rich enough sets of premade widgets, but my feeling is that at this > > point you have to > > understand your compilation target. > > Of course, you're right about the value of knowing web tech when the browser > is the target. I wasn't trying to be lazy (well, maybe a little :-), and I'm > not completely ignorant of HTML and CSS, just a lot more experienced with > desktop development for the client side. I am genuinely interested in what > people in the industry use to target complex single page apps, delivered in > the browser. And by complex, I am mainly referring to dynamic visual layout, > and interaction semantics (i.e. creation, deletion, and modification of > widgets to reflect app state). > > I know that HTML and CSS is the lingua franca of web designers, so when there > is a significant involvement by web designers in a project, it makes no sense > to try to bypass HTML and CSS. However, just as JavaScript can be thought of > as an assembly language for ClojureScript (or CoffeeScript, etc), HTML and > CSS can be thought of as assembly languages for hiccup, crate, garden, etc. > > Anyway, I'm not looking for a philosophical discussion about HTML/CSS/XML vs > S-expressions, I was just wondering what folks consider to be the current > state of the art for creating complex single page apps (and in my case, > client-only apps). My impression is that a lot of what would would be > implemented as JPanels in Swing would be div elements in HTML, and Fluxbox > (HTML5) or a polyfill for it (HTML 4.1) are used for layout of the div > elements and their contents. In the case of very simple widgets, perhaps form > elements such as <input type=checkbox> are enough, but in anything more > complex, folks use widget sets like JQueryUI, Sencha, etc. What is > interesting to me is that where Java on the desktop pretty quickly settled on > AWT and Swing (and SWT to an extent) back in the 1990s, there doesn't yet > seem to be that much of a consensus on how to do single page apps. Is this > also others' perception? > > Gary S -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
