From Twitter: Maybe we have to face it: Clojure has nothing to offer web programming that is better enough to make people switch to Clojure


#1

#2

Hmm… is this bad?


#3

I think it’s at least not good. The majority of developers are developing apps for the Web, for example JavaScript developers. Since there are so many developers, the community becomes better and better with new ideas and new tools. Now JavaScript community is where innovations come out. I think that’s something we hope to achieve. If Clojure community does not appear attractive to new generations of developers, the language itself dies slowly.


#4

If take a look of the current development of React, I think ClojureScript are few years ahead of current Js Web Dev world. MobX is really a Js version of Reagent and are very popular right now.

Clojure/ClojureScript are really js/java expert oriented language, they will beat you someday if you don’t understand the host language well. The entry point is too high.

Clear Winner

cljss / garden >> less/scss
core.async/manifold >> es6 async/wait solution.
cljs-loader >> still fragmented js module loading solutions
clojure.spec >> ???
specter >> ???
datascript >> ???
edn >> json

Clear Loser

Documentation
e.g.
Reagent are good, but you cannot find complete documentation anywhere. If you look at the source code and change log, you will found a lot of good stuffs never mentioned in any blog or document.

The same apply to core.async/manifold, they are great but one must learn it from source. which really scary for every new comer.

No one shop solution
Most of the Js Frameworks take care of every development step, from project template, code generation, test/test coverage, integration test, DI/CI, Containerize, Workable Example, Coding standard…etc. All fully integrated.

10 year won’t fixed basic flaw
npm support is still alpha quality.
where is my webpack??
yes, we have clojure.spec for better error message. but the clojure.core.specs is still not in-place. Therefore, we are still suffering from terrible error messages.


#5

This. I don’t understand why we don’t already have awesome interactive documentation à la Klipse or Dynadoc, given the power of Clojure. We don’t even have good classic documentation to start with, even if for the Clojure side things are getting better (the clojure.org website is having better guides etc.). Still we’re so far from what Haskell has (hackage), Racket or Rust.

I think it’s true for every JVM/compile-to-JS language.

I do think though that Clojure has compelling advantages over other languages, but the marketing is awful. A better website with awesome docs would really help.


#6

A few tweets later he says: “My statement was that maybe we shouldn’t try to copy Rails’ success in the web space. We should ignore it and make our own success in some other domain.”

This might be true, but I think Clojure web development with compojure is already much more pleasant than Rails development (in the Ruby world, I prefer Sinatra’s approach to that of Rails; this has to do with framework vs library issues in addition to language preference).

In any case, it seems to me that Clojure’s ecosystem is less optimized for the “hello world” experience than that of some other languages, which is to say that one must do a bit more up front, but it pays off over the lifetime of a project.

It’s hard to sell people on this approach over the virtues of:

$ do everything-for-me

… before they’ve actually built larger systems that lasts for years.

(Better intros and docs would be great! Though I’m not very into documentation strategies that involve switching to the browser rather than seeing them in the editor while working.)


#7

As someone who knew Clojure and ClojureScript from day one but didn’t start using ClojureScript until recently, maybe my thoughts on this might be of interest.

I didn’t use ClojureScript before because by the time I had set up a development environment for it, I lost any interest in it that I had. It was too complex and too time consuming, and thinking I have to do this for every project I want to start did not give me a good feeling about the future of the language.

This has changed dramatically, thanks to Zach Oakes’ Lightmod and Nightlight and things like Chestnut and Tenzing for Leiningen/boot templates and parinfer for easy parens matching, getting started with ClojureScript has become quick and easy for the first time. So that’s what pulled me back in (Lightmod specifically) and Reagent is what made me stay. I’ve been using CoffeeScript + Vue.js over the last few years, jQuery before that, played around with Angular, and Reagent beats everything I’ve ever tried, I’ve switched over to it completely for all new projects. It’s the first zero boilerplate framework I’ve seen in my life. It’s so simple it just gives me a deep feeling of joy, because I have really grown to hate complexity as a programmer. There is no such thing as perfection, but this combination comes pretty close.

ClojureScript itself also had some great changes of course that make it much easier to use now. Infer-externs is a great leap forward to make working with ClojureScript easier in the JavaScript ecosystem that it targets. And the support for node.js packages is going to further integrate it into the ecosystem.

I have to agree with others here, the documentation needs some work, especially the beginner documentation. The way reagent does it is actually quite good as is, it shows you just the basics you absolutely need and nothing else which makes it super easy to get started. And for advanced stuff you look at the Reagent cookbook examples. But those examples are out of date in places, especially the automated testing examples (which I would consider crucial) and there need to be more.

So long story short, in my opinion the focus going forward should be put on infer-externs and node.js support for ClojureScript itself, and when it comes to community projects, work on better beginner documentation and most important of all, support Parinfer, Lightmod and Nighlight, Chestnut and Tenzing any way you can, with code, feedback, tutorials or just plain exposure by telling people about it, these projects should be front and center, the first thing people encounter who are new to ClojureScript, their importance to get more people into ClojureScript cannot be overstated.

As for Clojure, personally I have to say I haven’t had to write any complex server side web code in years. Most of what used to be done on the server side can now be done on the client, and I think the need for server side stuff is only going to shrink further as time goes by, so I agree with the tweets that maybe server side web dev is not the future for Clojure, but maybe that’s just me, ymmv. And I don’t know what else Clojure could focus on. There is a real need for an alternative to the huge bloated Electron desktop apps that are growing ever more popular, but I don’t think Clojure can compete in that space, and if it did, could it compete with Red once it’s out of the alpha stage? Because I’d say Red is pretty close to perfect in that space.


#8

The startup-culture teams I’ve known are profoundly conservative.¹ At one company, it felt easy to get a “kick me” sign on my back for bringing up solutions outside a certain spectrum. Case studies from that company:

Case study: Coffeescript

With great effort, I could introduce a tech like Coffeescript on Node.js. (Yes, I know Coffeescript’s controversial. But for this application it greatly simplified boilerplate. I led the team through a big analysis, brainstorming advantages/disadvantages. It won grudging consensus.)

Even then, many resented it, for reasons they never articulated—reasons I believe are cultural/psychological/cognitive. One person stormed out of the analysis I conducted.

Case study: Clojure

Clojure was outside that acceptable spectrum.

Junior Rails contractors built us a microservice backend. (Already, Rails experts hear warning bells: Rails… for microservices!?) They took months implementing it, and it had cosmically bad performance—our mathematician’s R prototype outperformed it by orders of magnitude.

In Clojure, I implemented it from spec in a weekend. 1 tiny service that outperformed the R prototype.

Management immediately got their recently-hired Rails expert to translate it to Ruby.

Management and the first employee asked me to explain this debacle. They rudely refused to listen to my analysis — it was outside their conceptual framework. The only answer I could articulate in their frame (as I became offended & near-shouted) was that it’s pure, fucking incompetence & we’re fucked to the core. :stuck_out_tongue:

Case study: immutable DBs

Immutable DB architecture, even using plain MySQL and Python, was also outside that acceptable spectrum.

An emergency occurred: we lost vital numbers, so I had to fake them statistically so none would be the wiser. My laptop would take a month, but we had only 2 days. So I spun up dozens of machines to load immutable DB slices, letting hundreds of processes number-crunch. Success.

Afterwards, I gave a talk gushing about immutable analytics.

Later, they had the usual nightmares: “We’ve got 1 DB — and now logging in takes 20 seconds, not to mention generating reports!” I said, “What’s the problem? Just dump the DB every so often & load it on N machines for analytics.” Completely ignored, as if my words evaporated from our timeline.

Again, during immediate emergencies I was allowed to use whatever solution to achieve success — but it couldn’t be permanent. Company failure was preferable.

Some analysis:

The first employee wanted to use Rails. The CTO demanded PHP, because of its then-larger labor market. Priorities: investor-friendly fast growth and management-friendly coders-as-replaceable-cogs.

Later, Rails became acceptable as its labor market grew.

Coders from that local labor market seemed to come from a tool-led trade tradition, not a theoretical compsci tradition. (I only have a highschool degree, but studied theoretical lit.) For example, they might speak of profilers, but never big-O analysis.

Coders in a trade tradition apparently have a harder time switching tech. Maybe they rely more heavily on visual cognition, which’d explain why syntax is so painful for them to change. Maybe they fetishize pseudo-math notation (unlike most, who it triggers). Anyway, they’re stuck on concrete implementations rather than abstract ideas.

Footnote

¹ “Conservative” in terms of sticking to computing pop culture. You could say Clojure is conservative because it sticks to compsci concepts, and evolves only after great deliberation. But that’s a different meaning.


#9

After reading all tweets, I have a thought.

All reasons go to the same root — not beginner friendly.

not beginner friendly could be expanded to

  1. community expecting Clojure user have certain level of skill to solve basic problems, but that’s not the truth for truly beginner.
  2. tooling are designed for who know the design space crystal clear, libraries are great! But beginner will not know how to compose them, since they don’t have that knowledge and we don’t give any example (frameworks actually are good examples/recipes for beginner)
  3. parens are enemies of beginner, many people will just skip the language when they see the parens.
  4. Marketing are bad, the public image of Clojure are not really related to success / for everyone / hot topic.

#10

Interesting stories… Sometimes I just wonder if such things only happen in China, that people stick to old techs like Java, Angular, only some startups got chances to try new techs. In China people don’t want to try Clojure and the majority only knows Lisp as foreign things, not many people are trying it out due to syntax differences.


#11

Yeah, the only way I currently see Clojure highly adopted fast is through easy-to-use Clojure distros. Which maybe support a basic Python- or Ruby-like syntax that gives you 80% of Clojure.

Also, I noticed it’s far easier to adopt Clojure when there aren’t preexisting programmers — they play politics. :slight_smile: Is avoiding buy-in from other programmers an important principle? How did other tools ensure jobs?

  • Rails: did 37signals promote Rails-based small businesses? It appears to have an entire entrepreneurial philosophy & lit. And I heard there’s a gift economy where you got status (and higher income) for contributing to Rails development/docs. So you don’t need to convince coders — you sell directly to (say) a local hotel who wants a dynamic website. If so, Rails thus could be seen as a business model.

  • Python: did it grow at universities, among lone researchers & sysadmins?

  • Node.js: had a huge labor market. (Everyone who learned client-side Javascript, which Netscape willed into existence.)


#12

A (future need for) scalability plays nice with Clojure(Script), which allows for an all-Clojure solution. Only one language --essentially, aside from some Java and JavaScript interop-- to learn and it scales all the way up to to heaven.

Investigated Laravel framework some time ago (PHP) with Vue.js (JavaScript), which are quite nice and Laravel even has a REPL, but quickly became disappointed with the idiosyncrasies and weaknesses of the three programming languages involved.


#13

there are some good points here. Of course, I really love webdev with Clojure; it is the epitome of the full-stack experience with excellent tools (REPL, Figwheel) and an exceptionally good language, meaning that I use it for just about everything. But behind all that use-everywhere best-language goodness is surely a steep learning curve I’ve buried in my memory. Like Emacs, it’s one of those things that you invest into learning and receive pay-back in every category, until you forget where the payback even originated.

Clojure has the potential to be an internet-shaker; the full-stack, the joy of the development experience, the good efficiency/optimization story (outside of the “slow startup time” complaints, immutability dominates React performance, and back-end Java vastly outperforms less developed alternatives like PHP, Perl, Python, and probably Ruby and others). There is also a good amount of passion in the community still, and excellent introductory books and resources; we just need better publication of success stories and using all that we have available to us (Yeah, I’m working on that, too).


#14

I don’t understand why we don’t already have awesome interactive documentation à la Klipse or Dynadoc, given the power of Clojure

I have a pet theory about this having a lot to do with the lack of documentation standards. Most nice doc gen comes from well-formed documents adhering to some sort of standard (javadoc, tomdoc, what have you). There’s not really been anything that’s been adopted on a larger scale and indeed we haven’t even really agreed on how to do things like embed markdown in things like docstrings. @arrdem is doing a little bit of work on this right now, in addition to bringing back grimoire.


#15

I like that guy, I’m pretty sure I follow him on twitter. Super smart, way smarter than I am. I disagree with him though. Clojure has a lot to offer web programming and it makes things way easier, not just simpler. Immutability and the lack of ORMs, I think the yesql style approach where you just write sql is much easier. The amount of searchable docs/blog posts on plain sql eclipses the amount of docs on the various ORMs from other frameworks.

I also despise html templating like the rails default of erb. I don’t like react, but I do like that it’s just javascript when it comes to the views, so much better. Clojure has that too in the form of hiccup. If you put together:

  • cursive IDE (for a zero config editor integrated REPL experience)
  • parinfer
  • immutability
  • no ORMs, just SQL
  • hiccup for HTML

You get a winning combination that is better than the “competition”. I also don’t think it’s a zero sum game. Great artists steal. I’m starting to think instead of stuff like Arachne which is amazing and definitely a ground breaking approach to web dev, but over my head, we should have been focusing on imitating other communities’ frameworks to on board people to clojure this whole time.

Noir is incredible even though I found it much later after it had been deprecated. I’m trying to recreate the simplicity of it with my framework coast. Of course, I have a long way to go with the docs and the design, but I’m making improvements everyday :muscle:


#16

I think the thinking process of normal people are

Duke: I want to build a great SPA
Duke is going to google everything and see a lot of Ads (success story / blog)
Duke go to play around the tutorials of these Advertised framework/library
Duke pick one framework/library which make him feel

  1. easy
  2. have access to features he don’t understand much and don’t want to spend time on. e.g. security, testing, html5, UAF. ( security is just a few clicks away! sweet! )

Duke create a prototype in few days. Duke feel happy and create another Ads “build SPA in Y minutes”.

Duke continue to build his App with X and will not find another replacement if X is not making his App broken.

In another corner on earth,

Tom: SPA cooool
Tom google Ads Ads…
…

Most of the people like instant advantages like easy-to-use, free features, get popular.
they might want good quality, good maintainance, good performance afterwards, but the scope is already limited by the previous investment.


#17

Discovered clojure(script) about 1 year ago. Mostly because of react-js & immutable-js, and “the mess” that frontend development kinda is. Now prefer it over python also :slight_smile:

It’s been a while since I’ve been this happy with the the final code, so I tried getting the devs in my company & community on board, done a few presentations, talked a lot with people.

So far it’s been a bit of a reality wake up call, pretty much content that “it is what it is”. A few takeaways:

  • a lot of devs want to work 8h/day at work doing what they know then go for a bear. Nothing wrong with that, I guess.
  • most people just don’t see a fundamental problem. So if you don’t see any problems in OOP & mutability, not really a big incentive to spend your free time learning something else.
  • some just don’t get it. There pretty happy just doing a fresh refactor that is a little better than the version that got to the point of needing a “full refactor” and considering that a big win that they are proud of.
  • jobs… Some have this mindset “why would I spend my time learning this instead of getting better at javascript” there very few jobs in clojure and endless supply of js jobs out there.
  • Outreach Most people have not head about clojure before, strangely enough all of them seemed to have at least heard of ELM. Small stuff like free courses on websites like egghead.io seems to go a long way.
  • Functioal programming seems to scare people since they associate it with Haskell (monads, category theory)
  • Most people already have a codebase, it’s pretty hard to rebuild it in clojure, so it’s a waiting game, not like they can adopt new things over night.

All in all to me it seems like clojure is a niche language that has a awesome community. Don’t think I will be programming at home in anything else in the future, really happy with clojure on backend & frontend.

Can’t really see it growing very fast because of a lot of factors, the most important ones seems to be that immutability & functional are not that easy it requires a certain level of skill & passion for craftsmanship. To me it seems like that reduces the market to about 20% of the developers out there.

Would be great to find more efficient ways to get the word out though, not enough buzz IMHO :slight_smile:


#18

I personally think this is not about Clojure itself, it’s about Clojure community marketing strategy.
Product itself can’t decide the market mostly. Maybe we need to find common points from all success programming languages.


#19

Then the problem becomes how did successful programming languages become successful? And how could Clojure(Script) follow their ways?


#20

Is this topic not talking about this “making Clojure(script) popular/successful”?
Find other programming languages’ success reasons is not must follow it. It is in order to find out what we miss but must needed.

Maybe I put my think in a simple sentence can’t express my real meaning clearly.
No matter success or popular or something else. We really really hope Clojure(Script) can be a great ecosystem for programmers, right?

Please allow me give an example. If my food is not popular in customers, I will not limit my thinking just on my food. The failed reasons might be my shop location, might be the city culture, might be the time, might be my food description. or Ad or more reasons. I don’t need everything be perfect. I change some places not on my food might can change the low attention status.

Just say upper nonsense words are meaningless. I also write down my own experience as a programming newbie.

I like something easy, cool, something fun, something useful and familiar.
Just same as I like Emacs, Org-mode, Lisp, Clojure.
I recently create a package https://github.com/stardiviner/ob-clojure-literate for Clojure literate programming in Emacs Org-mode.
What is easy? CIDER is easy for me, easy to play on it.
What is cool? Clojure does not have really cool thing.
Clojure is not kind of easy for newbie, too many steps to start. Not like Python, Ruby etc. So they will not give a try. and dive in deeper like you. (You guys can’t think as yourself, you need to think as non-clojurist thinking)
Even though Clojure is host on JVM can invoke Java, but if we can simplify this invoking learning curve, give out more examples, people might will take a try. (Honestly, I know a lot of people stick on JavaScript, Java, C, C# etc are because their job, company or … some reasons.)
And lisp dialects is not familiar for many programmers already. So … you know.

Anyway, I have only one idea, make Clojure(Script) language itself (some parts) and tools simpler. And not just creating existing tools, also really new new tools. You can beat others in an already built marketing, need to find new marketing. (As upper some guys said.)

At the end, thanks for viewing my useless opinion.