REPL driven mobile development with Clojure(script)
Submitted by Srihari Sriraman (@ssrihari) on Monday, 21 August 2017
The REPL provides quick feedback cycles that are necessary to keep developers in charge. Dynamic, and interactive environments that propel the development process are essential in all faces of software development, and the mobile ecosystem has recently seen an uptick here with React Native. Couple that with an inherently REPL driven language like Clojure(script), and we have a close-to-ideal environment.
I’ll speak through my experience in developing a react-native + clojurescript app (team of 2) alongside a native team (team of 10), comparing and contrasting the development and business perspectives of both teams. We finished up much before the native team, focussed on design and stability, and delivered more functional value to the business.
The talk will be most beneficial to mobile devs who crave quicker feedback cycles, and to businesses folk who want to leverage the their existing teams effectively.
- How were we able to build faster, and more robust apps than a native team?
- How react native helped (will only cover contextually relevant takeaways here)
- How clojurescript helps * The dynamism in process * Stability by design and simplicity
- What were the anologous experiences with the native team?
- What does the clojurescript ecosystem look like right now?
- what are the common reservations against picking it up?
- The benefits of an undivided and unilingual team
- pros and cons of a team that does both backend and front-end
- pros and cons of a team that uses the same language on front-end and back-end
- Briefly, about the company, our backgrounds, the problem statement, the teams, and the results
- Quicker feedback cycles enabled by react native
- Deliver value from day 1
- Incremental development of HTTP and websocket APIs
- Even quicker, continuous feedback using clojurescript
- REPL driven development
- figwheel. this is really cool, check it out. incremental code recompilation and loading. stays out of the way.
- DEMO: figwheel + REPL
- Explore and validate from day 1
- Stability via Clojurescript
- seamless JS interop
- immutable data structures by default; much easier to write reloadable code
- makes you lean on functional programming patterns more than say typescript, which is more popular.
- briefly compare: clojurescript, scala.js, elm, purescript, and ghcjs
- google closure: great standard library, massive code size reduction
- reagent: react wrapper
- immutable types by default, much easier to write reloadable code
- re-frame: SPA framework
- datascript: datalog in-memory DB
- callback hell: CSP. Hallelujah!
- The Clojurescript ecosystem
- Reservations against Clojurescript
- willy wonka style decisions on the movement of the language
- lisp. very different. but hey, no precedence.
- completely different build tooling. but then, it’s just one thing (lein).
- personal experience from 3y ago, and contrast with now
- Undivided team: the pros and cons
- loss of full picture
- quick feedback cycles => well defined APIs
- tradeoffs, overheads and what is realistic
- of DB specialists and Ops specialists who existed
- Unilingual team: the pros and cons
- using the source
- at some points in time, we moved code verbatim from cljs to clj
- ability to make PRs to the backend
- highly coordinated backend + front-end development
- less communication overhead
Srihari is a FOSS enthusiast. He has contributed to Gimp, Eclipse, Diaspora and is excited about opportunities to give back. Over the last few years, he has written many Clojure services meeting tight latency SLAs, engineered assembly lines, written generative simulation test suites, and built performant monitoring solutions for a variety of businesses.
He has recently found a profound interest in leveraging his Clojure(script) skills for the front-end, and has delivered multiple browser and mobile applications.
He is a partner at nilenso, a hippie tree hugging bicycle riding software cooperative based in Bangalore.