Hacker News Reader

Comment by kgwxd | Hacker News Reader

After 20 years of traditional JavaScript, I recently got a chance to use ClojureScript on a decent size project, it's the only way I'm ever doing JavaScript from now on. It's a beautiful way to use React, no JSX or HTML strings in site, it's all generated using the same stuff used to write application logic. Yes, there's still a lot of tooling behind it, but I very rarely had to directly deal with any of it, Leiningen does most of the work with package management and builds, and ClojureScript itself takes care of utilizing Google Closure for its dead code elimination and other optimizations, without me having to write a single ugly annotation.

View on HN

Yeah Reagent is definitely the most productive front-end development flow. Just having hiccup vs JSX is a huge win. With JSX I spend most of my time chasing down syntax errors. With Hiccup I can simply use my IDE to navigate the code and syntax errors almost never occur and when they do it is obvious. Not to mention Hiccup is much more concise and can be read by macros.

Clojurescript truly is alien technology. Modern react has basically adopted Reagent's programming style with Hooks. Clojurescript/Reagent were 5 years ahead of the curve, truly amazing.

Clojurescript gives you a live repl, immutable data by default, core.async, macros, and an amazing consistent core library. None of these things are ever going to come to the javascript world

I had only heard (from afar) about Om; how does Reagent compare?

Reagent is a simpler abstraction around React, almost like a director's cut :) Om is a bit more oriented to react components. Both are mighty fine.

http://theatticlight.net/posts/Om-and-Reagent/

If only the Clojure(script) community would keep an up-to-date full guide on how to do modern web development with Clojure+ClojureScript...

I'm 1000% sold on Clojure (and have done some production back-end tools with it), but every time I try to do front end or mobile, I struggle without outdated guides or books and relative lack of other current online resources to get me reasonably down the road toward success.

Apparently people who successfully use these tools are happily working and not having the time to educate new people. Of course it's not their responsibility, but it does seem that the Clojure community is far less involved in nurturing new users than many other languages/toolkits/frameworks.

This is why, after last year one of our consultant teams struggled with this very thing, I built Clojurice: https://github.com/jarcane/clojurice

Full-stack setup with Boot and hot reloading on both front and backend, with some basic SASS, DB, and configuration setup as well.

Have a look; even if it's not for you, it might give you some idea how to set up an application and dev environment.

This is my impression as well, we do need better landing page esque docs and more blogs

deps.edn, shadow clj, and regeant seems like what I would try and target at the moment unless trying to do full stack datoms

In which case Fulcro looks like the future there just very complicated to learn I think I need to learn graphql first to help my understanding

Luminus provides ClojureScript support out of the box along with documentation on how to use it. It's been around for years now, and the primary goal is to provide a smooth beginner experience:

http://www.luminusweb.net/docs/clojurescript.html

You can create a new project with Clojure/Script support by adding different flags. For example, for a re-frame project:

    lein new luminus myapp +re-frame

This will generate the needed boilerplate and configuration. You can now start the server by running:

    lein run

The server will start a nREPL that you can connect the editor to on port `7000`, this is defined in the `my-dev-config.edn` file. The typical workflow is to connect to the REPL, and run your code as you're writing it.

Next, you start ClojureScript compiler in a separate terminal with:

    lein figwheel

The front-end workflow typically involves having figwheel running while you write the code, and it will automatically push changes to the browser. You can also connect to the nREPL started by Figwheel from the editor. This port is specified in `project.clj` under `:figwheel` with the `:nrepl-port` key. The default is `7002`. Once you connect the editor you run `(cljs)` function to switch to the ClojureScript REPL. You can now evaluate any code that's running in the browser. Note that Figwheel has to be started, and the page loaded in the browser first.

The project is set up to keep all the code in the same repository, and you have three separate source paths:

* `clj` - server-side code * `cljc` - code shared between the server and the client * `cljs` - client-side code

Packaging the app is done by running

    lein uberjar

Nice to see some lisp lovers in the frontend world. How does clojure handle types though, how would you argue with a typescripter for clojure rather than typescript ?

I wouldn't. I'd just finish the job and head off to the beach.

You get immutability for free with Clojurescript which is a bigger win than types but if you must have types there's Clojurescript spec now:

  http://cljs.github.io/api/cljs.spec.alpha/

Adding to your point, spec goes beyond the power of a (garden variety) type system, since it does its work at runtime. This of course incurs a performance hit, but you can easily exclude these checks in a prod build just by setting a compiler flag.

I've come to the realization that what we mean when we say "programming" must be fundamentally different categories of activity for different people.

I can't remember the last time I had a type error, or maybe if I did it was so trivial to fix that it's not sticking out. Type errors wouldn't even rate in the top ten categories of bugs that I make or encounter, so it seems odd to pick a programming language with that as a primary concern.

All else being equal, it does seem nice at some theoretical level to have a compiler that checks type correctness, but there's lots of other issues that would also be nice to have the compiler handle, which it often doesn't. For example, TypeScript seems to (like JavaScript, so far) not have any bigints, which seems to me a much worse flaw than lacking a type checker. What good is it for the computer to check my usage of types, if it can't even do arithmetic correctly with them?

But maybe this is just more of that nice feeling. I can't recall the last time I overflowed a fixint, either. (64 bits help with that -- or even 53 bits.) It's admittedly not a major practical concern in my daily programming life.

Maybe there are people who fret about type safety the way I fret about overflow. I assume it must be a concern among some styles of programming, because I keep hearing about how languages without compile-time type checkers are bad, even though my experience does not agree.

(Then people go and use languages where the type system is merely at the level of "Number" and "String", and it lets you pass a loop index to a function expecting a height in centimeters, and that's considered acceptably type-safe.)

If you mainly backend dev, you should just install Ember CLI, create a new Ember app and start building.

Super simple, super modern and easy to use. You will love it and forget those hyped madness what others do...

Additionally, Ember.js devs get the highest salary in frontend world. ;)

https://emberjs.com | https://yoember.com

Except that Ember is one of the heaviest front-end frameworks in terms of file size. Heavy file-size = more work for your mobile phone's CPU to deal with.

It changed a lot and you don't have to use all the feature if you don't need it. React with data support, router, etc can be super big... and latest Ember without Ember Data and tree shaking is small, so you win a lot of developer time and money and you end up with a well maintainable code, which can be understand by others in the first day, because of conventions over configurations. ;) IMHO Ember.js is still the best option for frontend, especially if you build a serious Web Application.

> Except that Ember is one of the heaviest front-end frameworks in terms of file size.

IIRC react requires nearly 300MB worth of npm packages just to get the hello world example to run. How does Ember fare in comparison?

NPM packages generally have nothing to do with the size of the built website. I don’t care if I need around 300mb of npm packages to build a 10kb website when ember itself is bigger.

Yes, cljs is like frontend finally got its meds and everything makes sense again!

Reply on news.ycombinator.com