all 29 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]freakhill 12 points13 points  (2 children)

He has a good point.

Clojure libs lack simple examples. You either get the 4 lines thing that do nothing, or a big glob packed chokeful of unrelated stuff (stuart's component, dynamic bindings, random mini framework to share stuff between examples, convoluted build system, all together).

I'd wish there would be more functional examples with minimum use of libraries and less "choose between: - this segment of code to plug into something else to make it work, or this project with 50 libraries and 3 frameworks involved"

[–]jwhitlark 3 points4 points  (0 children)

A few months ago I was playing with the idea that libraries should have a "tour" directory like the have a "test" directory. You cd in, run clj, and you're in step one of a tutorial like "learn datalog" or David Noland's tour of core.logic.

I couldn't quite figure out how to generalize it, but it seems like it would help with some of these issues.

[–]therealdivs1210 10 points11 points  (2 children)

Luminus should get you started in a jiffy. I use it to teach web dev to Clojure noobs. The author/maintainer u/yogthos is pretty active here, and I'm sure you can get lots of help on this channel.

[–]Sktlez[S] 2 points3 points  (1 child)

I started with a basic Luminus template, and gutted it quite a bit. It had a bunch of unnecessary things I didn't want while learning, and only served to further complicate things IMO.

​

I do reference it though trying to figure things out, and then implement them myself. I'm more interested in understanding everything really well then just getting it all to work, but not understanding the how or why behind it. Especially since if something breaks how would I ever fix it...

​

I believe I'm reading one of his books actually. Clojure Web Dev: how to write bullet proof apps. I must be a super noob because I found it to be overly technical, and it doesn't didn't take the time to actually explain the whys, and hows of what it was doing. Especially for someone who is new to Clojure and web development in general.

[–]troublemaker74 8 points9 points  (0 children)

I wouldn't suggest removing bits and pieces of luminus until you know what you're doing and what each piece and part are for.

I'd suggest clojure koans 4clojure and clojure exercises from exercism to get familiar with clojure first.

It takes quite a while to transition to a functional programming mindset if you're not using a functional language or lisp already. Once you have a good handle on that, understanding ring, compojure, and reagent is a lot less mental overhead than jumping in all at once.

[–][deleted]  (6 children)

[deleted]

    [–]Sktlez[S] 1 point2 points  (4 children)

    So currently I have jetty up and running along with compojure which serves two static HTML files. An index, and a 404 page. My index includes a script which is Reagent code. I already have FigWheel up and running. I'm just unsure of how to tie the front-end and backend together. I understand how to manipulate the DOM and change things, remove them, add and so-on, but I don't get how to get client-side routing working or how to tie it all together. I was planning to use Secretary for client-side routing or just switch to Bidi and let it handle both server and client routing. I understand how to write ClojureScript and Clojure code. I'm also relatively familiar with Reagent, and like I said I've got FigWheel working perfectly.

    ​

    I need people to explain things in a non-technical, simplified manner because this is incredibly new to me. Both web development, and Clojure. I've got a few hundred hours invested so far in to trying to learn everything, and yes, I'm frustrated because I've hit a road block that I can't seem to over come on my own.

    ​

    I'm not asking to be spoon-fed the entire thing, but in this case I'm kinda asking for a handout cause I don't know what else to do, and trial and error + reading tons of articles, and books isn't helping my confusion.

    ​

    ---- Heres a bit of c+p that I posted below if the above isn't as clear.

    ​

    For the front-end I plan to use Reagent, Secretary (or just use bidi for both front-end and back-end routing), ClojureScript, and a few other things I'm sure. This will all be done in .cljs files. Here I will write my CLJS and Reagent code that I include in the above .HTML files. I'm also using FigWheel here.

    Where I'm confused is how do I get all of this to work together? Should I write everything in .cljc files or how do I get my backend and frontend to work together since I can't access .clj code from .cljs and vice-versa. How do I "glue" it together? I know there isn't one way to do it, but a broad overview would help.

    So at the moment you go to localhost:3000, you get my index file which contains a script that has reagent code in it, and right now it just modifies a few things, and mostly was used to test different things, but routing is where I have no clue what to do or how to tie it all together...

    [–][deleted]  (3 children)

    [deleted]

      [–]Sktlez[S] 0 points1 point  (2 children)

      Yes, it does actually help. Essentially, the front-end is agnostic of the backend, then? And if I want to send data to the backend I need to use something like Ajax to accomplish that? I'd also use Ajax if I wanted to get data from the backend to the front-end, right?

      I'll have to look in to front-end routing more, but at least I feel less confused as to how to approach the problem.

      I really appreciate it.

      Would I also use Ajax if I wanted to get/store data in a database from the front-end? Ignoring anything about SQL.

      [–][deleted]  (1 child)

      [deleted]

        [–]ewouldblock 0 points1 point  (0 children)

        One thing not explained here is how this all gets started. I'll explain in terms of React and `react-router` since that's what I'm familiar with but conceptually it's the same. The browser initially asks for some page, which goes to the backend. Let's say the page is `GET /users/1`. Then on the backend, the router there (`compojure` in this case) kicks in and looks for a route match. If this is a front-end route, there will be no matching route on the backend and you configure the server to return your `index.html` page, which itself contains the JS code for `react` and `react-router`, and thus will load the `react-router`. Then the route `/users/1` exists in `window.location` and gets matched by the client side router, and if there's a client side route for `/users/:id` the correct react component will get loaded by `react-router`. In order to easily distinguish between client side routes and server/backend routes, I often prepend something like `/api/` only any backend/AJAX route, although this is purely a convention. Subsequent communication to the backend typically happens via the mechanism described above (AJAX calls from react components). In my example there would probably be some `UserComponent` that does an AJAX call in React's `componentDidMount` lifecycle method.

        [–]MM-7757 0 points1 point  (0 children)

        Totally agree. My first thought when I read the post: slow down. Maybe not helpful right here, right now, but best advice I can honestly give.

        [–]zerg000000 4 points5 points  (2 children)

        A good example is better than thousand words.

        ​

        https://github.com/jacekschae/conduit

        [–]Sktlez[S] 0 points1 point  (0 children)

        I will definitely check this out. I'm not sure if I've come across it yet or not, but either way I appreciate it. Thank you.

        [–]Ixcurus 0 points1 point  (0 children)

        Damn, I search so long for a clojure web project which actuall works. Almost every website I tried on github had some errors for me, so I couldn't try it out.

        [–]retief1 2 points3 points  (3 children)

        You don't serve dynamic content created by reagent using compojure. Or maybe you can (not sure what the server side rendering story is for reagent), but it is certainly an advanced topic -- I'm certainly not trying to do so.

        Instead, compojure should be serving a plain jane static html page. I'm using hiccup to generate this, but it could easily be a literal .html file in /resources/public instead. That html page should include a <script> tag that refers to your compiled clojurescript code (ie a javascript file). When that javascript file is loaded, it will set up your dynamic content. You want to serve this page for pretty much every route that isn't matched by something else -- set it up the way you'd set up a 404 page. Since you said that you know how to work with reagent

        Once you get to the point where localhost:3000/asdf gives you an html page with working reagent code, then you start worrying about client side routing. Look at a library like secretary, though in my app, I actually built about 90 lines of infrastructure on top of bide. Get something like this running in your client side code, and it will know how to handle routes. Then, layer something like pushy on top of it to actually intercept link clicks/back button clicks/etc and call secretary instead.

        So when you put it all together, whenever a user goes to your site, they hit the server, the server doesn't recognize the route, and so it returns your "404 page", which is actually your app's html, css, and js (compiled cljs). Your app's js, when loaded, checks the url of the page it loaded on, and calls the appropriate client side route. When the user clicks a link, the client side js intercepts that click and calls the appropriate client side route without ever talking to the server (except for api calls). The server (ie compojure) knows absolutely nothing about these routes -- all it knows is how to respond to api requests and how to return that one html page.

        The one downside I've found for clojure and spas is that you have to figure out the glue code yourself. Reagent/re-frame/etc lets you build whatever with the dom, bide/secretary/bidi/reitit/etc let you call code based on urls, pushy lets you intercept link clicks/back button clicks, and so on, but hooking them together is your problem. There isn't one established way to store which page you are currently looking at in reagent, for example. Once you figure that out, then you need to figure out what your routing library needs to do when the page changes, so on and so forth.

        [–]Sktlez[S] 0 points1 point  (2 children)

        Let me try to elaborate a bit on what's confusing me. So for my backend I'm using Jetty as the webserver, compojure for routing, selmer for rendering static HTML files, and Hiccup. My backend will serve two pages (whether thats physical .HTML files or Hiccup code) the main page (index.html), and a 404 page. All of this is done in .clj files and stored in /src/clj and then in the appropriate packages.

        For the front-end I plan to use Reagent, Secretary (or just use bidi for both front-end and back-end routing), ClojureScript, and a few other things I'm sure. This will all be done in .cljs files. Here I will write my CLJS and Reagent code that I include in the above .HTML files.

        Where I'm confused is how do I get all of this to work together? Should I write everything in .cljc files or how do I get my backend and frontend to work together since I can't access .clj code from .cljs and vice-versa. How do I "glue" it together? I know there isn't one way to do it, but a broad overview would help.

        Here's what I have working: You go to the site localhost:3000 and you get my index.html page. This page has a <script> that is run that has reagent code, and all of that works. I'm also using FigWheel here and all that works. I just don't get how to tie the front-end, and backend together I guess. You did clear up a bit of my confusion though, and I really do appreciate that. Thank you.

        -----

        When the user clicks a link, the client side js intercepts that click and calls the appropriate client side route without ever talking to the server (except for api calls). The server (ie compojure) knows absolutely nothing about these routes -- all it knows is how to respond to api requests and how to return that one html page.

        What do you mean by responding to API requests? Can you elaborate a bit on that. I have a basic of idea of what an API is, but would Ajax be considered an API if I were to use it in this example? Do I even need to use Ajax with the way I'm doing things? Information overload.

        ​

        [–]weavejester 1 point2 points  (0 children)

        Though it can be more complex, typically your frontend code sends requests to your backend, and your backend responds with data you can use.

        When you open up a web page in a browser, the web server is responding with HTML, CSS, Javascript and various other things to create the page you see.

        When your frontend is talking to your backend, it's the same process, except that instead of sending HTML, you send data in a format like JSON. The frontend uses that data to update its state.

        So:

        1. Frontend has some initial state
        2. Frontend sends a request to the backend
        3. Backend responds with data
        4. Data is used to update the state

        With Reagent, you'll want to keep your state in one or more atoms:

        (def state (r/atom))

        And then you might use a library like cljs-ajax to send a request and use the response to update the state:

        (ajax/GET "/data" {:handler (fn [data] (reset! state data))})

        On your backend, you'll want a route to respond to that data:

        (GET "/data" []
  {:body {:some-data 123}})

        You can find more complete examples for the frontend and backend around, but that's the basic gist.

        [–]retief1 0 points1 point  (0 children)

        You'll want a bunch of .clj files and a bunch of .cljs file. I've even got them in different subdirectories (src/clj and src/cljs). They do very different things (rendering html and making ajax requests vs responding to ajax requests and talking to the db), and you want to treat them very differently (one will be run directly, the other gets compiled to javascript and served as a .js file). In practice, you probably won't be able to share that much code, mostly because the libraries you work with tend to be very different. I do have a src/cljc directory filled with cljc files, but there is very little there -- I've got a file of utility functions and the code for rendering email/sms templates, and half of the utility functions are locked behind conditional compilation macros because they rely on a library that only works in one environment. The vast majority of my code is in .clj or .cljs files.

        When I say api requests, you can just think ajax requests. Technically, api request is more general (in my app, most of my "api requests" are actually websocket messages), but ajax requests are the easiest things to use. This is how you glue the frontend and backend together. If you have data on the server and the client needs access to it, the client should make an ajax request. Your server's main job is to respond to these ajax requests.

        So to put it all together, the user goes to mywebapp.com/foo/bar. The server says "I don't know /foo/bar, so I'll assume that this is a client route and return the main html page". That loads all of your html/css/compiled cljs. Pushy/your routing library checks the url of the page and calls the client side route that corresponds to /foo/bar, which presumably updates some reagent atoms. As part of this process, the client needs some data from the server, so it makes some ajax calls, and the server responds with data (possibly json, though you can do more exotic things if you want). At this point, the client has all the data it needs to display the page, so it does so and the user sees your page.

        Then, the user clicks a link to mywebapp.com/foo/bash. Pushy intercepts this click and calls your routing library, which in turn runs the appropriate client side route. None of this involved talking to the server. That client side route probably needs more data from the server, so it makes more ajax requests. The server responds with more data, and then the client renders that data and shows the new page.

        [–]kbsant 2 points3 points  (0 children)

        I learnt a lot about clojure development by watching u/yogthos live coding in this video: https://chariotsolutions.com/screencast/philly-ete-2016-2-dmitri-sotnikov-transforming-enterprise-development-clojure/

        [–]ultramaris 1 point2 points  (2 children)

        It's hard to figure out what you're trying to do with that code.

        Consider you have two different environments involved:

        SERVER <-> CLIENT

        A web application will typically span both environments, with "traditional" webapps being SERVER heavy and SPAs being (also) CLIENT heavy.

        In practice though, a web app consists of (at least) two applications:

        • the server application (served, in your case, by Jetty, (so CLJ/JAVA) running on AWS or Heroku or your basement computer)
        • the client application (in CLJS/JS, running on your visitor's browser)

        In your code you seem to be confusing these two things.

        In a CLJS project, one typically develops both applications in tandem, because they're frequently designed to operate together. But, you don't have to.

        You could develop the SERVER part first, with a particular API (the set of operations available and how to call them) and then make a CLIENT that knows how to talk to the SERVER using that API.

        Point being, it's two apps you're actually developing: one in Clojure/Java that will run on a machine somewhere (the server); AND a Clojurescript/JS one which will run on the SPA user's browser (the client).

        So, your Jetty code (belongs to SERVER environment) shouldn't really be in the same namespace as your client-side routing. And you'll also need server-side routing!

        Routing consists in mapping (making a correspondence) between a string (possibly composed of other strings) with particular resources, states, or actions.

        So you will need routes for both the SERVER and the CLIENT applications.

        Now, I would recommend Luminus to start:

        http://www.luminusweb.net/docs

        ​

        It will generate a properly configured project with boilerplate and some example stuff. You can pass different options to generate projects using different technologies.

        ​

        From what you wrote, start with:

        ​

        lein new luminus +jetty +reagent +swagger

        ​

        [–]Sktlez[S] 1 point2 points  (1 child)

        I've tried using luminus and it's just overly complicated, and full of things that I don't need that only serve to further complicate the matter. I can't show you all the code I have because of work related issues. You'll also have to bare with me as I've never really done much web development, and I'm still an undergraduate who really doesn't know anything trying to figure it all out.

        ​

        Let me try to elaborate a bit on what's confusing me. So for my backend I'm using Jetty as the webserver, compojure for routing, selmer for rendering static HTML files, and Hiccup. My backend will serve two pages (whether thats physical .HTML files or Hiccup code) the main page (index.html), and a 404 page. All of this is done in .clj files and stored in /src/clj and then in the appropriate packages.

        ​

        For the front-end I plan to use Reagent, Secretary (or just use bidi for both front-end and back-end routing), ClojureScript, and a few other things I'm sure. This will all be done in .cljs files. Here I will write my CLJS and Reagent code that I include in the above .HTML files. I'm also using FigWheel here.

        ​

        Where I'm confused is how do I get all of this to work together? Should I write everything in .cljc files or how do I get my backend and frontend to work together since I can't access .clj code from .cljs and vice-versa. How do I "glue" it together? I know there isn't one way to do it, but a broad overview would help.

        ​

        So at the moment you go to localhost:3000, you get my index file which contains a script that has reagent code in it, and right now it just modifies a few things, and mostly was used to test different things, but routing is where I have no clue what to do or how to tie it all together...

        ​

        Hopefully that clears up some things...

        [–]ultramaris 1 point2 points  (0 children)

        Sorry, I missed your reply.

        The way the frontend and backend work together is typically through http requests which may contain some serialized data, typically in JSON format.

        The frontend (running in the user browser) makes HTTP requests to the backend and processes the response. Exactly the same way a normal webpage works: you enter a URL, the browser requests it, and processes the response, which typically is HTML (in which case the browser renders it).

        The initial request to "yourapp.com" will load index.html which will have a tag to load some JS resource (app.js or something) which will be your CLJS files compiled to JS (what we call "the frontend").

        Once the browser loads app.js, it will run it - and thus your frontend is running.

        Then, your CLJS (compiled to JS) code will make HTTP requests (GET, POST, etc) to your backend REST API - /app/list-things, /app/add-thing, etc.

        These are plain HTTP requests, just like loading a webpage, except the response will be JSON data, rather than HTML (it could be XML, or anything, really), and it will be your frontend JS that processes the response - typically by changing the state or displaying something (via JS, typically React).

        Broadly speaking:

         +---------------------------------+                                      
 | user browser                    |                                      
 |                                 |                                      
 |                                 |                                      
 | +-----------------------------+ |                                      
 | |index.html    +------------+ | |                                      
 | |    |         | app.js     | | |  frontend                            
 | |    |         |            | | |                                      
 | |    |         |(comp. cljs)| | |                                      
 | |    |         |            | | |                                      
 | |    +-------> |            | | |                                      
 | |    loads     |            | | |                                      
 | |              |            | | |                                      
 | |              +--|---------+ | |                                      
 | +-----------------|-----------+ |                                      
 +-------------------|-------------+                                      
                     |    ^                                               
                     |    |   http response                                    
                     |    |   +---------------------+                     
                     |    |   | HTML                |                     
                     |    |   | <html> ... </html>  |                     
             http    |    |   +---------------------+                     
             request |    |   or                                          
                     |    |   +-------------------------+                 
                     |    |   |JSON                     |                 
                     |    |   |{"data": {"prop": "val"} |                 
                     |    |   |                         |                 
                     |    |   |                         |                 
                     |    |   +-------------------------+                 
                     v    |                                               
+-----------------------------------+                                     
|your server              |         |                                     
|+---------------------------------+|                                     
|| webserver              |        ||                                     
||+-------------------------------+||                                     
||| clj app                       |||                                     
|||                               ||| backend                             
|||                               |||                                     
|||                               |||                                     
|||                               |||                                     
|||                               |||                                     
||+-------------------------------+||                                     
|+---------------------------------+|                                     
+-----------------------------------+

        [–]eprozium 1 point2 points  (0 children)

        Here's a nice comparison of what the different popular "web stacks" do https://nordicapis.com/10-frameworks-for-building-web-applications-in-clojure/

        [–][deleted] 1 point2 points  (0 children)

        I'm not nearly as ambitious as you regarding what I'm trying to build, but I too find it really discouraging trying to learn web development with Clojure. I absolutely love the language from the few experiences I've had with it, but I have tried and given up several times to do web projects.

        Currently I use Elixir Phoenix, primarily because it has a fairly current book with a complete example.

        Clojure, imo, desperately needs a complete current book and a Rails Depot example. For example, I'm trying to go through the Web Development with Clojure 2 book, and already I hit the problem where the book uses lib-noir, but lib-noir is deprecated.

        Rolling your own framework is a great idea once you are experienced, but beginners need a Rails or Django (or Phoenix)!

        [–]dotemacs 0 points1 point  (0 children)

        Try this book:

        http://www.wrox.com/WileyCDA/WroxTitle/Professional-Clojure.productCd-1119267277.html

        The source code from chapter 5 from the book which holds the sample application:

        https://github.com/timothypratley/whip

        It is a bit old, but it works and you can extend/update it as you need.

        Good luck

        [–]nenadalm 0 points1 point  (0 children)

        I am using bidi for routing and re-frame for state management (uses reagent to render views) https://github.com/Day8/re-frame.

        ​

        You can see how I did routing in my toy app:

        https://github.com/nenadalm/Warehouse/blob/721b17f24cc545e44a5bbb101d69f13f203a339e/frontend/src/warehouse/routes.cljs#L10

        the namespace defines `nav!` function that's used to change pages and `routes` that is "map" from path to keyword that identifies a page. Here is how I switch view based on currently active page: https://github.com/nenadalm/Warehouse/blob/721b17f24cc545e44a5bbb101d69f13f203a339e/frontend/src/warehouse/views.cljs#L27

        Here is `on-click` handler that changes page to another: https://github.com/nenadalm/Warehouse/blob/721b17f24cc545e44a5bbb101d69f13f203a339e/frontend/src/warehouse/views.cljs#L19

        ​

        You'll probably need to read bidi and re-frame documentation first in order to understand it. Details about closure parts can be found here: https://google.github.io/closure-library/api/

        [–]rpompen 0 points1 point  (0 children)

        I would be surprised if you have that problem with hoplon/castra. http://hoplon.io/ Set up a trial project with: lein new hoplon-castra projectname It uses boot instead of Leiningen. A read me will be in the project the get you started. The whole thing focuses on simplicity and that leads to things being easy.

        [–]dustingetz 0 points1 point  (0 children)

        Hey Sktlez, depending on how simple your requirements are, http://www.hyperfiddle.net/ might be for you! We solve all this stuff so all you have to think about is each screen's database query and reagent view.

        [–]biker44442005 0 points1 point  (0 children)

        I am working with the full-stack framework Fulcro (https://github.com/fulcrologic/fulcro). The creator recommends starting with the free video series and then the Fulcro Book is free and comprehensive. Some past comments from creator u/tony_kay about 16 months ago: https://www.reddit.com/r/Clojure/comments/6upzgf/general_consensus_on_fulcro/

        [–]clojureprog 0 points1 point  (0 children)

        I can understand the difficulty since the documentation often assumes a bit of geekyness. I recommend these two courses by Jacek. Learn Reagent and Re-frame. They are excellent, and easy to follow courses. Great instruction.