JSFoo 2019

On component architecture, front-end engineering and Developer Experience (DX)

Tickets

If you are going to transpile JS, why not use ClojureScript?

Submitted by Shivek Khurana via Zainab Bawa (@zainabbawa) on Tuesday, 10 September 2019

Section: Full talk (40 mins) Technical level: Intermediate

View proposal in schedule

Abstract

Nearly all production JavaScript apps use some form of transpilation, be it Babel or TypeScript or something else. This let’s you overcome the shortcomings of the underlying language and makes the application more sustainable. But the famous languages that transpile to JS are are Java like. They prefer classes and objects and clear separation of concerns.

ClojureScript is a functional LISP which stands against the philosophy of OOP. And it can compile to JavaScript. This talk is about why Clojure and ClojureScript deserves your attention.

Outline

Build Up/ Problems
Situations that led me to question my toolkit & introduced me to Clojure/Script

Clojure/Script Crash Course
Understanding the Clojure/Script syntax and functional/immutable model

Google Closure Compiler & Closure Library
Google’s way of writing JS and how ClojureScript depends on it

Interop With JavaScript
How ClojureScript allows you to plugin to the existing state of the art

REPL Driven Dev - Developing inside the Runtime
Tools that accelrate your dev workflow to light speed

spec - Ensuring Type Safety
Types make large systems predictable and Clojure’s optional spec library helps you with types and generative testing

Build tooling
The current state of art and things you need to bootstrap a ClojureScript project

React Wrappers
Existing React wrappers in ClojureScript

Conclusion & QA

Requirements

A general understanding of the JS ecosystem. Some experience in shipping/ maintaing a web application, API, or a mobile app.

Speaker bio

Shivek has been building (and breaking) enterprise applications for more than a decade. His carrier began at a young age of 14 and largely consisted of unpaid work at Startups & SMEs. Over the years, he was lucky to find exceptional teachers, who helped him mature as a system architect. In this long journey, he has touched all parts of the stack, from Frontend to Backend, Data Pipelines to DevOps.

Since 2013, his focus has been on Frontend Development using React. He has built systems that are used by 0 to over 12 million users. This experience has shaped his ideas about how to grow and maintain complex applications and his preference for Clojure/Script.

He works as a Consultant at Krim Labs & as a Full Stack Clojure/Script Developer at JUXT Ltd. (UK). He also writes a Medium Blog about his experience and learnings on Scalable Architectures.

When it comes to software, he’s an expert at avoiding shiny new things, and focusing on the old and boring. He firmly believes that all code is liability and the best piece of code is the one that was never written.

Links

Slides

https://github.com/krimlabs/workshops/blob/master/jsfoo2019/Cljs%20Talk.pdf

Comments

  • Zainab Bawa (@zainabbawa) Proposer Reviewer a month ago

    Thanks for a detailed rehearsal, and putting up the slides early. The key points from today’s rehearsal were:

    1. Anchor the story around one core idea. Currently, the focus is too much on the negative aspects of ClojureScript. Instead, the focus could be, “I will tell you – participants – enough about ClojureScript – to get you interested in exploring ClojureScript after my talk.” This will help give a coherent message to the audience.
    2. Too much time is spent in recommending why not to use ClojureScript instead of getting into the details of ClojureScript. Show participants how ClojureScript works. Get into the details.
    3. If anyone who has not seen Lisp code at all, your current slides will flummox them. Show code on how to do code with JavaScript and then how to code in ClojureScript. FP is more than map, reduce and filter. Instead you want to emphasize the concepts such as immutability, first-class functions, etc. While Repl is a very good example, you also want to spend some more time on other tools and why these are unique things in Lisp. You want to encourage to people to be interested in exploring Lisp at the end of the presentation.
    4. Show and tell code. This is what the audience at JSFoo wants to see.
    5. Some facts need re-checking. For example, Java is not slow, but its the startup time for ClojureScript which is slow. This needs changing.
    6. Numbers and metrics are missing about what does a company get when using ClojureScript. Explain trade-offs in detail.
    7. Explain benefits and advantages for why use ClojureScript for a product.

    Incorporating the above feedback will help tighten the talk to a large extent, and also ease the audience into the aim of the talk – which is to explore ClojureScript.

    On the slides itself, incorporate the following feedback:

    1. Remove memes from the presentation. A good presentation doesn’t need memes to support it.
    2. Avoid putting full sentences for bullet points. Instead, put crisper bullet points.
    3. No more than three bullet points per slide.

    Share the revised slides by 22 September, latest, so that we can have a final round of feedback.

  • Zainab Bawa (@zainabbawa) Proposer Reviewer a month ago

    Thank you for the rehearsal. Here is the feedback from today’s session:

    1. The slides are much better.
    2. Increase the tempo of the talk.
    3. Put a little more energy into the examples and the talk.
    4. The talk is a little too long. The language part and syntax is something that you can run through faster.
    5. Audience can do without having to think in the talk. Entertain participants and intrigue them.
    6. Focus on SPEC and REPL. This is the part that connects with the audience and TypeScript.
    7. Remove the inter-ops part.
    8. Have a much more lively Q&A session.
  • Chirag Jain (@chiragj) a month ago

    Hi Shivek great job. The talk is much more crisp now and the live demo is really great especially the part where you debug the code without prior knowledge of the codebase. The talk can be improved by talking less about the syntax (we are already seeing you edit it live). Also the people at the back may not be able to see the code changes you are making, if you can bump the font size on the demo then it would help alot.

  • Shivek Khurana a month ago

    Thanks Zainab, Chirag, Jasim, Ravindra, Ramki and everyone else. I was able to make this better only after your comments and feedback after the first rehearsel.

    @jaju also suggested the I should try to reach the REPL as soon as possible. I’ve also added a few slides about spec and prepared a small demo.

    Will try and increase the tempo, and not focus much on the syntax and JS interop while on the state.

    @chirag: great point. Will fix my emacs for that.

Login with Twitter or Google to leave a comment