4 ms·

Most of the comments are about the startup RAM use and distributable size, which is a criticism shared with Electron. The demo app is not attempting to address

Most of the comments are about the startup RAM use and distributable size, which is a criticism shared with Electron. The demo app is not attempting to address these particular weaknesses. The point of the article is there are some applications where processing speed is important where Clojure's and JVMs concurrency and long running and large dataset performance is very important. And the ecosystem appears to be ready to make it possible to create apps where these strengths vis-a-vis Electron are combined with the other strengths of Clojure compared to low level languages (expressive syntax, interactive development).

grandinj 7y ago
I routinely run my fairly and complex java UIs clamped to 256M of memory, and startup time is measured in a handful of seconds. Distribution size is not great I'll admit, unless you go to considerable effort to slim the JRE down.
- deleted 7y ago
  [deleted]
- didibus 7y ago
  I feel distribution size like, users should have a JRE on their machine. Same way native apps expect you to already have a bunch of existing modules already installed as well. Or at least, if many apps were all using Java, you'd only install a JRE once, and then keep getting the non JRE bundles, so size of distribution would be a lot less. What I mean is, at least for Java apps, this is a possibility. In Electron world, even though almost everyone has Chrome installed, you can't share it, you need to keep bundling the whole thing over and over again.
slgeorge 7y ago
Yeah it's really interesting because it's a fully worked example of packaging a desktop application using a hosted approach. Personally, I'm more comfortable with that stack. Also worth looking at is Vlaaad's Cljfx (https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx). And I just want to say the number of examples that Vlaaad has created for the project is amazing and really helpful - it's a great example of helping others on-board to use your project - thanks Vlaad.
daxfohl 7y ago
Yeah I'd say the point of the article is to highlight the Clojure wrapper for JavaFX, providing an option to develop JavaFX desktop apps in an Om/Reagent fashion and playing to Clojure's strengths. All the criticism here seems more like criticism of JavaFX itself.
neurobashing 7y ago
not just that: we've come full circle. At one point, there were a bunch of Java/JVM desktop apps. They were widely disliked/mocked because they were heavyweight, had slow startup time, didn't use platform-standard widgets, etc. The web became an alternative to cross-platform apps. Now we're seeing a proliferation of Electron apps - web apps - that are widely disliked/mocked because they are heavyweight, don't use platform-standard widgets, etc. And at least in this piece, an alternative is the JVM.
- mapgrep 7y ago
  Yes the initial hype on Java when it came out of Sun was all around desktop use, often but not exclusively in browser. They even tinkered with the idea of writing the browser — even an OS! — in Java. There was literally something called JavaOS. Anyone remember the JavaStation? Trouble is the computers of 1996, combined with the less optimized JVM of 1996, were really not up to the task. And I would venture the GUI libraries were not there yet either. 24 years later we have very speedy JVMs and much faster computers and networks and toolkits like the one in the article (JavaFX) sound much smoother. Meanwhile Clojure offers concurrency primitives that are making threading much more accessible.
- didibus 7y ago
  Yup, and since VSCode and IntelliJ both used too much RAM, I needed to switch to Emacs on my old dell laptop, yet it used to be that people mocked Emacs for using too much RAM, in fact, the joke was that Emacs stood for: Eight megabytes and constantly swapping. The wheel just goes round and round :p
  - renox 7y ago
    Unfortunately I am old enough to remember starting emacs remotely on a fellow student's computer so that he stopped working and went to the restaurant with us: starting emacs 'froze' the computer and made it unusable for a (small) duration.. So there's some truth behind the joke: vi started much faster. So I never learned emacs which I regret now because I feel that emacs is much better as a C++ IDE than vim.
Scarbutt 7y ago
IME, regular JS is much faster than regular Clojure. You can make Clojure run faster than JS by writing Java with parenthesis, but then you defeat all the purpose of using Clojure in the first place.
- piranha 7y ago
  That is a weird claim to make and completely not true in my experience. Idiomatic Clojure is faster than any JS except maybe asm.js-like stuff.
- jplane 7y ago
  I am very curious about your experience. Could you provide some more details?
- didibus 7y ago
  Clojure has always been measurably faster than JS for me on every use cases I've ever used it for.

grandinj 7y ago

I routinely run my fairly and complex java UIs clamped to 256M of memory, and startup time is measured in a handful of seconds. Distribution size is not great I'll admit, unless you go to considerable effort to slim the JRE down.

deleted 7y ago
[deleted]
didibus 7y ago
I feel distribution size like, users should have a JRE on their machine. Same way native apps expect you to already have a bunch of existing modules already installed as well. Or at least, if many apps were all using Java, you'd only install a JRE once, and then keep getting the non JRE bundles, so size of distribution would be a lot less. What I mean is, at least for Java apps, this is a possibility. In Electron world, even though almost everyone has Chrome installed, you can't share it, you need to keep bundling the whole thing over and over again.

slgeorge 7y ago

Yeah it's really interesting because it's a fully worked example of packaging a desktop application using a hosted approach. Personally, I'm more comfortable with that stack. Also worth looking at is Vlaaad's Cljfx (https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx). And I just want to say the number of examples that Vlaaad has created for the project is amazing and really helpful - it's a great example of helping others on-board to use your project - thanks Vlaad.

daxfohl 7y ago

Yeah I'd say the point of the article is to highlight the Clojure wrapper for JavaFX, providing an option to develop JavaFX desktop apps in an Om/Reagent fashion and playing to Clojure's strengths. All the criticism here seems more like criticism of JavaFX itself.

neurobashing 7y ago

not just that: we've come full circle. At one point, there were a bunch of Java/JVM desktop apps. They were widely disliked/mocked because they were heavyweight, had slow startup time, didn't use platform-standard widgets, etc. The web became an alternative to cross-platform apps. Now we're seeing a proliferation of Electron apps - web apps - that are widely disliked/mocked because they are heavyweight, don't use platform-standard widgets, etc. And at least in this piece, an alternative is the JVM.

mapgrep 7y ago
Yes the initial hype on Java when it came out of Sun was all around desktop use, often but not exclusively in browser. They even tinkered with the idea of writing the browser — even an OS! — in Java. There was literally something called JavaOS. Anyone remember the JavaStation? Trouble is the computers of 1996, combined with the less optimized JVM of 1996, were really not up to the task. And I would venture the GUI libraries were not there yet either. 24 years later we have very speedy JVMs and much faster computers and networks and toolkits like the one in the article (JavaFX) sound much smoother. Meanwhile Clojure offers concurrency primitives that are making threading much more accessible.
didibus 7y ago
Yup, and since VSCode and IntelliJ both used too much RAM, I needed to switch to Emacs on my old dell laptop, yet it used to be that people mocked Emacs for using too much RAM, in fact, the joke was that Emacs stood for: Eight megabytes and constantly swapping. The wheel just goes round and round :p
- renox 7y ago
  Unfortunately I am old enough to remember starting emacs remotely on a fellow student's computer so that he stopped working and went to the restaurant with us: starting emacs 'froze' the computer and made it unusable for a (small) duration.. So there's some truth behind the joke: vi started much faster. So I never learned emacs which I regret now because I feel that emacs is much better as a C++ IDE than vim.

Scarbutt 7y ago

IME, regular JS is much faster than regular Clojure. You can make Clojure run faster than JS by writing Java with parenthesis, but then you defeat all the purpose of using Clojure in the first place.

piranha 7y ago
That is a weird claim to make and completely not true in my experience. Idiomatic Clojure is faster than any JS except maybe asm.js-like stuff.
jplane 7y ago
I am very curious about your experience. Could you provide some more details?
didibus 7y ago
Clojure has always been measurably faster than JS for me on every use cases I've ever used it for.