Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "frontend matters". We turn our attention to the frontend, and our eyes burn from the complexity.

Our discussion includes:

• What is a Single Page Application (SPA)?


• The progression from static websites, to multi-page websites, to JavaScript-enhanced pages, to SPAs.


• Why we like SPAs.


• Where's the "main" for the frontend?


• The complexity of frontend builds.


• How does the frontend app start running?


• How does the "table of contents" concept apply on the frontend?


• How can you make the most important parts of the application clear?


• What are the most important parts of a SPA?


• What is the "backend of the frontend"?


• The asynchronous, reactive cycle that drives a SPA.

Selected quotes

You don't usually go into a code base just to browse it, or just to have fun. You go there with a purpose. You need to work. You need to get something done fast.

We like rich frontends. We're able to do a lot more interactivity. There's less interruption when the page has to load. There are a lot of advantages to SPAs.

With a SPA, it's really, really fast to switch between everything. It feels almost instantaneous because there is almost nothing to load each time.

The counterpart is that a SPA is more sophisticated, so it ends up being more complicated. It's almost like a process that's running continuously. There's more code that's present in a SPA than any individual page load.

From the browsers point of view, the "main" is the markup, and you have to tell it to run some code.

It's just one blob of code to the browser. You can't look at that code because it's transpiled, minified JavaScript.

I do think it's interesting that we've gotten several minutes into this episode, and we're still talking about how things get made into the final sausage. It's reflective of how much effort it takes to set up the JavaScript ecosystem.

We make a "main.cljs" file, and that is the top of the application. It's a signpost. "Hey! Hey! Look here first!"

The tab's not going to go away, so all we need to do is start up all the event listeners because JavaScript is a very event-driven language.

I want "main" to be a table of contents of everything that matters in the app: the views, the routes, the URLs, browser hooks, web sockets, etc.

The worst kind of "main" is no "main" at all. There are frameworks where you make a whole bunch of separate files for each of your routes.

I love how many times we said the word "react" in this episode. It's all very event driven. That's just the model of the whole browser. It's the water that you swim in, so you must swim the right way in order for the application to succeed.

Reactive cycle

User Interaction → Event → Callback → Reactive Model → Re-Render

Kinds of frontend components

• Navigation (eg. browser history)


• Router


• Settings


• State holders (eg. app state, reactive atoms)


• Pure models


• Browser integrations (eg. camera, microphone, GPS, notification API, fullscreen API)


• Render

Links

• "Reentrant Coding" Series
  
  
  
  • Ep 114: Brand New, Again
  
  
  • Ep 115: The Main Event
  
  
  
  


• Clojure for static sites
  
  
  
  • Stasis
  
  
  • Powerpack
  
  
  
  


• ClojureScript for frontends
  
  
  
  • shadow-cljs
  
  
  • Figwheel
  
  
  • Reagent