+1 for re-frame. It is more opinionated than Om and reagent which means one less choices when entering the front-end wilderness (and the opinions are sound). re-com is also great but be aware that it is for modern day browsers only. As an alternative you could use one of the many reagent bootstrap wrappers.
> On 27 Jul 2015, at 04:33, Tim Gilbert <[email protected]> wrote: > > 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. -- 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.
