For those curious, Replete relies on the ability of ClojureScript to self-host, and thus essentially carry its compiler with it.
Replete iOS was one of the first applications of self-hosted ClojureScript (around 2015, the first time we could evaluate ClojureScript forms directly on iOS, no JVM in sight).
Just recently Replete was ported to Android, via some amazing work of Roman Liutikov.
I'm maintaining the site(https://github.com/shadow-cljs/shadow-cljs.org). It contains a JavaScript file but doing nothing but handling the click, although its size is large, it should do very little thing on your browser. I also installed a Firefox on my Phone(MIX2S) and it looks fine.
The first error might be platform security limitation and the second one looks like a bug. Please file an issue on GitHub https://github.com/replete-repl (use repo for iOS or Android app)
I'm not sure if this is the case; due to the immense body of work on JIT JavaScript, ClojureScript would usually perform better than Clojure for everything but math, hence would be good idea for server side usage as well. YMMV, of course.
The jvm has also had an immense amount of work done on its jit. One oft cited problem is its boot time, but other than that, its clojurescript really faster?
Internal tests, heard the same from others. I didn't do much digging, but I think it's the JVM being very under optimized for code not written in Java.
When node.js came out I was extremely excited. I remember watching video where Ryan Dahl received standing ovations and I almost jumped myself out of my chair to applaud.
I neither liked Javascript nor hated it but the idea of having same semantics on the back-end and front-end was really enticing. Sadly, after years working in node I realized that the promise of shared code was a lie and it is simply just doesn't work as I wish it would.
But then I tried Clojure and Clojurescript and to my surprise the idea of shared code actually somehow works here, despite the fact that you are essentially living in two different worlds - JVM and Javascript VM.
Do you think it is feasible to run the entire stack on closure script?
JVM just irks me the wrong way. Probably less than electron / nodejs does but if I'm stuck with one set of primitives and externs (npm) I'd rather use the same one both places even if the JS one is suboptimal in all cases (I've written enough JS that I'll be able to deal.)
Re The shared code thing between server and client for JS I never understood the proposition. You're solving different problems sharing code _never_ made sense.
I think what people were really talking about when they said they wanted it was sharing data. Sharing their object relations, or sharing their mapping code. Or better yet, not having to share mapping because with the same language in both places you no longer need to map data.
And nodejs/browser js does in fact get you all of that. Provided you have clean models and clear conventions / functions to manage that shared state.
Where the story breaks down is the lack of native immutability, and the problems that leads to elsewhere, namely, if you have some data in the client that maps perfectly to serverside data you likely still end up with that serverside version of it including g server side only infoyou don't want exposed. Likely this is the what you should do boundary wise but it is what often ends up happening anyway.
Closure forcing immutability also forces not only the data structures but also the library code that makes reasoning about, and slicing and dicing those structures far easier / natural or I guess you would say isocratic.
and you could edit text in Lisping and send it to Replete for evaluation. (The generic hooks still exist in Replete, so in theory other apps could do the same.)
I personally mainly use Replete for quick checks of things when AFK (seeing what a particular form might evaluate to, checking a docstring, etc.) In, short I've never really used Replete for any heavy development.
When Lisping existed (it is evidently no longer available), I was never really motivated to use it to develop code with Replete.
What's the case for using clojurescript these days in a company compared to JS 2019? the project has almost no contributors, no one working full time on it, the closure library they use its from 2016, the friction to interop with JS is still too high and too much of a hassle, they never embraced npm because they didn't want to listen to their users like typescript, etc..
You're kidding? Clojurescript ecosystem is so more matured and production-ready than any of other alternatives.
Clojurists emphasize simplicity and pragmatism. Why most popular front-end cljs wrappers are for React? Because it simply makes sense. It just works. If for any reason it stops making sense they'd quietly adopt something else.
Do you really enjoy chasing the hype and rebuilding your app every few months? Have you caught up with all the syntactic features added in ES/TS in the past few years? All developers in the team as well? Or are they still fighting if it is okay to use implicit returns or they are pure evil? Should you use rambda or lodash, what about immutable.js? Don't even let me start on webpack and the plugins.
People often falsely claim that Clojure codebases are not scalable because they haven't seen codebases built by large teams. The truth is - Clojure and Clojurescript are so practical that it doesn't require to have a huge team to build something really impressive and it definitely doesn't require to have a large team to maintain it.
Why do you think Clojure and F# coming as the most payed programming languages in most surveys for the past few years? If I had to choose either to have a team of 5-6 JS/TS devs and pay them 100K each, or to have 3 Clojure(script) devs and pay them 200K each - I'd rather do the latter, because ROI in that case is much, much higher.
One of the biggest advantages of ClojureScript (except for all the advantages of using Clojure that you also get with ClojureScript) is the language's stability. Almost all features and enhancements are done in the form of libraries, so the language you are using today is pretty much the same language you were using last year and the year before that.
I think that stability is a big advantage, depending on what type of client side applications you are building. I know of several consulting companies that are using ClojureScript for their client side work, and they can basically just continue building apps without having to re-architect their underlying framework every year. That can have a big effect on the cost of development.
I also highly recommend that any ClojureScript development is done using shadow-cljs, and that allows very convenient integration with npm modules.
As a general rule, anything javascript does should be seen as the way 'not to do things', not as something to jump on the bandwagon with. I have never dealt with a more frustrating language, ecosystem, package manager, toolset and so on. When I used ClojureScript for a previous project I found it a breathe of fresh air in comparison. Thesedays I use Elm. It's great to leave the world of webpack bugs behind, or installing alternate package managers using other package managers. I fully recommend trying it sometime.
Fantastic tooling, potential to live in the same language for cljs front-end/clojure backend, less code means less bugs than JS, shorter time to implement, higher productivity from smaller teams, stable core, lots of development on great libs, immutability/persistent data structures/strong concurrency patterns get you out of the tar pit, low friction to interop with JS, cljs loves npm via shadow-cljs.
Easier to list the case against. The case against is it has a steeper learning curve and it's harder to hire for.
I’d add that if you are ok with remote and the company is doing something interesting: hiring (or training) isn’t that problematic, you will actually get access to very talented & motivated people because of Clojure
If you require people to be co-located Berlin has a very strong Clojure community for example, depends on where you are though.
Well. I can only say that now and then I read about new, super clever solutions to js problems ranging from async code to packaging or react. Most of the time that's the first time it occurs to me that X could be a problem, as I'm just happily banging out clojurescript.
Cljs seems to dodge a mountain of stupidity. Even react makes more sense in cljs than js.
Hello
I use clojure and clojurescript at work
I have no fear about clojure be small because clojure is hosted. There is no problem to use any lib on npm or maven.
Clojure don't need to be huge.
Replete iOS was one of the first applications of self-hosted ClojureScript (around 2015, the first time we could evaluate ClojureScript forms directly on iOS, no JVM in sight).
Just recently Replete was ported to Android, via some amazing work of Roman Liutikov.
It is all open source, for those interested in how it works: https://github.com/replete-repl/
(replete.http/get "http://replete-repl.org")
from
http://replete-repl.org/replete-namespaces.html
I get a "warning: no such name space" (on android).
Also, seems there's no selecting/copying text from the repl output, which is a bit annoying...
You should be able to copy output by pressing on a history row.
> You should be able to copy output by pressing on a history row.
Appears I can copy the historical input but not the output.
As for http/get - after the require i get a "Cleartext HTTP traffic to (...) not permitted" with a http url, and an {:error nil} with a https url...
Is there a more appropriate forum for discussing tutorial/getting started stuff? I'd like to play, but a set of (tested) koans seems to be required.
This wasn't clear to me before or after I looked at the page.
They have hugely different applications, but at a certain level, they look like the same language.
https://blog.ndk.io/jvm-slow-startup.html
(Curious whether it really matters or if it's just something you need to be aware of day to day)
I neither liked Javascript nor hated it but the idea of having same semantics on the back-end and front-end was really enticing. Sadly, after years working in node I realized that the promise of shared code was a lie and it is simply just doesn't work as I wish it would.
But then I tried Clojure and Clojurescript and to my surprise the idea of shared code actually somehow works here, despite the fact that you are essentially living in two different worlds - JVM and Javascript VM.
JVM just irks me the wrong way. Probably less than electron / nodejs does but if I'm stuck with one set of primitives and externs (npm) I'd rather use the same one both places even if the JS one is suboptimal in all cases (I've written enough JS that I'll be able to deal.)
Re The shared code thing between server and client for JS I never understood the proposition. You're solving different problems sharing code _never_ made sense.
I think what people were really talking about when they said they wanted it was sharing data. Sharing their object relations, or sharing their mapping code. Or better yet, not having to share mapping because with the same language in both places you no longer need to map data.
And nodejs/browser js does in fact get you all of that. Provided you have clean models and clear conventions / functions to manage that shared state.
Where the story breaks down is the lack of native immutability, and the problems that leads to elsewhere, namely, if you have some data in the client that maps perfectly to serverside data you likely still end up with that serverside version of it including g server side only infoyou don't want exposed. Likely this is the what you should do boundary wise but it is what often ends up happening anyway.
Closure forcing immutability also forces not only the data structures but also the library code that makes reasoning about, and slicing and dicing those structures far easier / natural or I guess you would say isocratic.
https://news.ycombinator.com/item?id=11658418
and you could edit text in Lisping and send it to Replete for evaluation. (The generic hooks still exist in Replete, so in theory other apps could do the same.)
When Lisping existed (it is evidently no longer available), I was never really motivated to use it to develop code with Replete.
Clojurists emphasize simplicity and pragmatism. Why most popular front-end cljs wrappers are for React? Because it simply makes sense. It just works. If for any reason it stops making sense they'd quietly adopt something else.
Do you really enjoy chasing the hype and rebuilding your app every few months? Have you caught up with all the syntactic features added in ES/TS in the past few years? All developers in the team as well? Or are they still fighting if it is okay to use implicit returns or they are pure evil? Should you use rambda or lodash, what about immutable.js? Don't even let me start on webpack and the plugins.
People often falsely claim that Clojure codebases are not scalable because they haven't seen codebases built by large teams. The truth is - Clojure and Clojurescript are so practical that it doesn't require to have a huge team to build something really impressive and it definitely doesn't require to have a large team to maintain it.
Why do you think Clojure and F# coming as the most payed programming languages in most surveys for the past few years? If I had to choose either to have a team of 5-6 JS/TS devs and pay them 100K each, or to have 3 Clojure(script) devs and pay them 200K each - I'd rather do the latter, because ROI in that case is much, much higher.
I think that stability is a big advantage, depending on what type of client side applications you are building. I know of several consulting companies that are using ClojureScript for their client side work, and they can basically just continue building apps without having to re-architect their underlying framework every year. That can have a big effect on the cost of development.
I also highly recommend that any ClojureScript development is done using shadow-cljs, and that allows very convenient integration with npm modules.
Easier to list the case against. The case against is it has a steeper learning curve and it's harder to hire for.
If you require people to be co-located Berlin has a very strong Clojure community for example, depends on where you are though.
The official guide recommends using webpack, the irony. https://clojurescript.org/guides/webpack
Cljs seems to dodge a mountain of stupidity. Even react makes more sense in cljs than js.