20 ms·

Comparing JVM alternatives to JavaScript

123 points by based2 8y ago

kgwxd 8y ago
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.
- globuous 8y ago
  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 ?
  - sanatgersappa 8y ago
    I wouldn't. I'd just finish the job and head off to the beach.
  - cutler 8y ago
    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/
    - lgessler 8y ago
      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.
  - ken 8y ago
    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.)
- vmware513 8y ago
  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://emberjs.com | https://yoember.com https://yoember.com
  - cutler 8y ago
    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.
    - deleted 8y ago
      [deleted]
    - vmware513 8y ago
      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.
    - geezerjay 8y ago
      > 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?
      - asutekku 8y ago
        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.
- bgorman 8y ago
  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
  - theptip 8y ago
    I had only heard (from afar) about Om; how does Reagent compare?
    - vnorilo 8y ago
      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/ http://theatticlight.net/posts/Om-and-Reagent/
- vnorilo 8y ago
  Yes, cljs is like frontend finally got its meds and everything makes sense again!
- blunte 8y ago
  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.
  - jarcane 8y ago
    This is why, after last year one of our consultant teams struggled with this very thing, I built Clojurice: https://github.com/jarcane/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.
  - slifin 8y ago
    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
  - yogthos 8y ago
    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 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
symlinkk 8y ago
He doesn't like JavaScript development because the tooling is too complex, but then he pulls in behemoths like GWT?
- not_kurt_godel 8y ago
  GWT is incredible. Admittedly the tooling is a bit clunky but it's really no worse than your run-of-mill webpack/yarn/grunt/gradle/whatever JS build. Such a shame it's kind of been semi-abandoned, it just blows TypeScript/React out of the water on so many fronts. Hard to pick what I like best about it but I think the number one gap that TS et. all will have trouble reaching is compilation to asm.js. It's really hard to overstate just how much more performant GWT apps are pound-for-pound due to this and a few other performance-related features/hacks that seem a long way off, if not downright impossible, to match as long as the source language is JavaScript.
  - invokestatic 8y ago
    Have you tried Vaadin? Apparently, it's based on GWT and still actively developed. I'd really like to try the GWT style development model for an upcoming project and Vaadin looks like an appealing solution.
    - not_kurt_godel 8y ago
      I have not, but I have met the Vaadin guys at a conference and seen demos. I would agree it does look quite appealing overall.
torqueTorrent 8y ago
It can be useful to keep it simple and try to stay exclusively with HTML-latest + ES-latest + CSS and avoiding external JS libraries as much as possible. Using the latest versions of just the basics (HTML, ES, CSS) can help minimize what only recently required the addition of external JS libraries.
pcj-github 8y ago
Add https://github.com/google/j2cl https://github.com/google/j2cl to the mix if you're looking for java development for front-end work.
nercht12 8y ago
The sad part is, even with all these complex toolkits and yada yada, I still haven't seen much of an improvement in the UI, which is, from the user's perspective, the primary ( if not only) thing that matters. Sites just get slower, break more easily, and look comical when you turn the JS off. Maybe some backend helps ease some pains, but if you have to spend hours and hours reading about how to do X in framework Y cooperating with framework Z did you really save any time or make your site more robust than including and using a few tools from a lightweight library? Not that I make anything big, but it seems websites aren't any better than before; just the toolkits are getting bigger.
- draw_down 8y ago
  I don’t think it’s surprising that changing development tooling does not change UIs. Those are different things.
- pjmlp 8y ago
  Quite right, but then Web FE devs will tell you how HTML/CSS are so much better than native toolkits, as if.
- muxator 8y ago
  How true. Lately I am also starting to have problems with my default Firefox setup, which blocks 3rd party cookies and trackers. The result? A lot of (in my opinion) lazily coded websites break, without ever catching a single error, because they were put together assembling external services and skimming on testing. Normally everything more or less works with my fallback chrome in its default configuration, but then I feel we are more or less back to "optimized for ie6" days.
paglia_s 8y ago
The problem with this post is that React, an UI library, is being compared with toolkits that in some cases are simply Java-to-JS compilers. To make a fair comparison there should also be a plain js example
lemming 8y ago
I'm a bit mystified why OP didn't include Kotlin on their list. It's very accessible for Java devs, works brilliantly with tools they are probably used to (IntelliJ, Gradle etc) and compiles natively to JVM and JS (and Native these days, if you care about that). It seems like the ideal candidate.
- invokestatic 8y ago
  Probably because it's not Java. Yeah, it's similar to Java and runs on the JVM, but it ain't Java. Confusingly, the author uses the term "JVM" in the title but then discusses strictly Java in the article itself.
- skybrian 8y ago
  Kotlin's JavaScript support has been around for a while but I was under the impression that it wasn't used much. Is there a community using it now and is it getting much support?
  - cutler 8y ago
    Kotlin may be a nice language but its HTML library: https://github.com/kotlin/kotlinx.html ... is an abomination.
Twirrim 8y ago
It's interesting seeing GWT producing small javascript. I must admit I have been somewhat biased against it given prior experience. It used to be used for the AWS console all over the place, on the theory that it would be easier for the service devs to also write the console code. That got eventually overhauled to the far superior form it is now. The Javascript that used to be produced was enormous, and of course on a per-service basis, and it had a big overhead on the parsing and running stakes. If any of you was using the console maybe 5 or so years ago, you'll know what I mean about the console loading experience (it was fine once the javascript got processed).
- skybrian 8y ago
  AdWords is a huge service. It was the largest GWT app out there and always pushing the limits. It was entirely rewritten when they moved to Dart. It's hard to say how much of the improvement was due to better language-level tools versus having learned a lot since then. The GWT team at Google went on to write the j2cl compiler, and based on Github commit history, they're still working on it: https://github.com/google/j2cl https://github.com/google/j2cl
acjohnson55 8y ago
Scala.js is also an option. https://www.scala-js.org/ https://www.scala-js.org/ It skips the JVM altogether and complies Scala to Javascript. I haven't used it for anything significant, but I've heard nothing but good things.
- threeseed 8y ago
  I am using it now and it's solid. Recommend combining it with: Slinky React (https://slinky.dev https://slinky.dev) JSON RPC (https://github.com/shogowada/scala-json-rpc https://github.com/shogowada/scala-json-rpc) Diode (https://github.com/suzaku-io/diode https://github.com/suzaku-io/diode) Scalably Typed (https://github.com/oyvindberg/ScalablyTyped https://github.com/oyvindberg/ScalablyTyped) Being able to use almost every React library but with full types and code completion is amazing. And with JSON RPC you can treat Client -> Server as though it's just another method call.
- forty 8y ago
  I reimplemented flux example in scala.js a few years ago. It really looks great, not so different from the js code but all strongly typed. https://github.com/forty/scala-js-flux-example https://github.com/forty/scala-js-flux-example
jarym 8y ago
For all that people wanted to run away from Java’s ‘complex’ toolset it seems modern JS has managed to recreate most of it. I wonder if we’ll do a loop with JSON and end up back at XML
- doctorpangloss 8y ago
  We did, GraphQL is the new XML.
  - goatlover 8y ago
    Yeah, I don't understand the love for GraphQL. It seems over-engineered and difficult to get started with.
    - geezerjay 8y ago
      GraphQL gets a lot of love because it presents itself as a solution to a considerable and all too frequent problem: get the front-end/client teams to coordinate with the back-end teams. This is more of an organizational ans project management problem than a technical problem, thus their advocates are ok with the trade-off.
  - yen223 8y ago
    How so?
itslennysfault 8y ago
This is a crazy argument IMO. JavaScript tooling is stupid simple if you know what you're doing. Learning something new is always hard so if you're new to JavaScript (and have a JVM background) of course it'll seem hard at first. I love node 'cause it "just works" (but really it does). The app I work on is node TypeScript Nest.js backend and TypeScript Angular frontend. The set up process for a new dev is install node (takes like 10 seconds), clone the repo, npm install, npm start. Ready to start developing. TypeScript is as simple as installing typescript, and running tsc from the command line. With ts-node you can simply make your npm start script "ts-node ./index.ts" and you're off and running.
- wpietri 8y ago
  > JavaScript tooling is stupid simple if you know what you're doing. Do you mean simple, or easy? I think the latter. The JS tooling seems well optimized for the novice user, but I think it's hard to argue that it isn't complicated behind that friendly face. Also, I think most things seem easy once you know what you're doing. Almost tautologically so.
- cutler 8y ago
  The trouble with Typescript is that the corporates have gotten their hands all over it as a means of turning JS into Java. TS turns lean, functional JS into an over-engineered smorgasbord of classes, interfaces and general OOP nonsense. JS was designed primarily as a functional language.
  - pault 8y ago
    This runs counter to my experience. I've found that TS will confirm to any style of programming you prefer to use. If you want to avoid classes and inheritance, just type your functions and data structures and call it a day.
  - dboreham 8y ago
    >lean, functional JS into an over-engineered smorgasbord of classes, interfaces and general OOP nonsense Aka "code that someone other than you can understand"
cromwellian 8y ago
J2cl (successor to GWT) produces even smaller code.
tlrobinson 8y ago
This is a pretty unfair comparison for React. He uses the "JavaScript has complex toolchains" excuse to not use best practices like JSX and a bundler, then claims React is verbose and slow compared to other solutions that use complex toolchains? First of all, Parcel is a dead simple to use bundler that supports JSX, hot reloading, code splitting, and various file types (including TypeScript) out of the box: https://parceljs.org https://parceljs.org Second, that React code is much longer than it needs to be, mostly due to formatting, but if you use function components and React "Hooks" it can be extremely short: const Counter = () => { const [count, setCount] = useState(0); return ( <div> <p>The current count is {count}</p> <button onClick={() => setCount(count + 1)}>Increment</button> <button onClick={() => setCount(count - 1)}>Decrement</button> </div> ); }; With the imports and call to "render" it's about 15 lines of code, which is much shorter than all of his other examples. The class version (written how I'd do it) is about 25 lines, which still shorter. Here it is without JSX, using Preact's HyperScript-style `h` instead of `React.createElement`: class Counter extends Component { constructor(props) { super(props); this.state = { count: props.count || 0 }; } increment() { const { count } = this.state; this.setState({ count: count + 1 }); } decrement() { const { count } = this.state; this.setState({ count: count + 1 }); } render() { const { count } = this.state; return h("div", h("p", "The current count is " + count), h("button", { onClick: () => this.increment() }, "Increment"), h("button", { onClick: () => this.decrement() }, "Decrement") ); } } And of course these are toy applications, which aren't even representative of real applications. I'm not sure I can go back to imperative UI toolkits like GWT, etc. The application size seems approximately accurate, but if you really care about bundle size you could use Preact (which supports most of React's features). The brings the bundle size down to about 10KB, which is also much smaller than his examples. Load time is also unfair due to lack of bundling.
- blunte 8y ago
  The early part of his post listed the challenges in doing front end dev because of the many (and frequently changing) options and varying online guidance on how to do things. Undoubtedly there exist better combinations of tools, but as someone just starting front end exploration, knowing what is the right combination is virtually impossible.
wwweston 8y ago
Interestingly, even as a one time front-end specialist, I'm leaning the something same direction this author did: the complexity introduced along with front-end frameworks/tooling treads near (and in some cases beyond) a border past which I stop feeling like working with JS itself is a win. The more the development process treats the browser as a runtime target for generated code, the less point I see in sticking with JS -- or even augmented versions of it -- as a source language. And I like JavaScript. Of course, I don't much like Java, so that's not where I'm likely to go, but I am struck with what the author demonstrated here regarding that as an option. Like the author, I'm very curious about something like Elm; if I'm going somewhere with a type system, I'd like to go further along the spectrum of benefits types can provide. And I'm also not sure we've reached the apex of possibilities of working more directly with HTML/CSS/JS, but that's highly domain/application dependent and another topic.
theptip 8y ago
In a similar vein, I have been idly wondering about the viability of using Python for building browser apps recently: Http://brython.info Http://pypyjs.org No idea what the performance is going to look like for webasm, but might be a worthwhile sacrifice if the developer productivity gains were good enough (using the same language for FE and BE makes many things easier).
- aitchnyu 8y ago
  Here is Mozilla bringing Python to Browser via WASM, a few science benchmarks run faster in WASM than CPython, others get upto 12x slower. https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/ https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scien...
xx4xx4 8y ago
oh, i know now
ralusek 8y ago
Use `create-react-app` you absolute maniacs.
truth_seeker 8y ago
GraalVM is also an alternative. It might be able to run your existing NodeJS project on JVM. https://github.com/graalvm/graaljs https://github.com/graalvm/graaljs

123 points by based2 8y ago

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.

globuous 8y ago
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 ?
- sanatgersappa 8y ago
  I wouldn't. I'd just finish the job and head off to the beach.
- cutler 8y ago
  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/
  - lgessler 8y ago
    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.
- ken 8y ago
  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.)
vmware513 8y ago
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://emberjs.com | https://yoember.com https://yoember.com
- cutler 8y ago
  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.
  - deleted 8y ago
    [deleted]
  - vmware513 8y ago
    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.
  - geezerjay 8y ago
    > 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?
    - asutekku 8y ago
      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.
bgorman 8y ago
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
- theptip 8y ago
  I had only heard (from afar) about Om; how does Reagent compare?
  - vnorilo 8y ago
    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/ http://theatticlight.net/posts/Om-and-Reagent/
vnorilo 8y ago
Yes, cljs is like frontend finally got its meds and everything makes sense again!
blunte 8y ago
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.
- jarcane 8y ago
  This is why, after last year one of our consultant teams struggled with this very thing, I built Clojurice: https://github.com/jarcane/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.
- slifin 8y ago
  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
- yogthos 8y ago
  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 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

symlinkk 8y ago

He doesn't like JavaScript development because the tooling is too complex, but then he pulls in behemoths like GWT?

not_kurt_godel 8y ago
GWT is incredible. Admittedly the tooling is a bit clunky but it's really no worse than your run-of-mill webpack/yarn/grunt/gradle/whatever JS build. Such a shame it's kind of been semi-abandoned, it just blows TypeScript/React out of the water on so many fronts. Hard to pick what I like best about it but I think the number one gap that TS et. all will have trouble reaching is compilation to asm.js. It's really hard to overstate just how much more performant GWT apps are pound-for-pound due to this and a few other performance-related features/hacks that seem a long way off, if not downright impossible, to match as long as the source language is JavaScript.
- invokestatic 8y ago
  Have you tried Vaadin? Apparently, it's based on GWT and still actively developed. I'd really like to try the GWT style development model for an upcoming project and Vaadin looks like an appealing solution.
  - not_kurt_godel 8y ago
    I have not, but I have met the Vaadin guys at a conference and seen demos. I would agree it does look quite appealing overall.

torqueTorrent 8y ago

It can be useful to keep it simple and try to stay exclusively with HTML-latest + ES-latest + CSS and avoiding external JS libraries as much as possible. Using the latest versions of just the basics (HTML, ES, CSS) can help minimize what only recently required the addition of external JS libraries.

pcj-github 8y ago

Add https://github.com/google/j2cl https://github.com/google/j2cl to the mix if you're looking for java development for front-end work.

nercht12 8y ago

The sad part is, even with all these complex toolkits and yada yada, I still haven't seen much of an improvement in the UI, which is, from the user's perspective, the primary ( if not only) thing that matters. Sites just get slower, break more easily, and look comical when you turn the JS off. Maybe some backend helps ease some pains, but if you have to spend hours and hours reading about how to do X in framework Y cooperating with framework Z did you really save any time or make your site more robust than including and using a few tools from a lightweight library? Not that I make anything big, but it seems websites aren't any better than before; just the toolkits are getting bigger.

draw_down 8y ago
I don’t think it’s surprising that changing development tooling does not change UIs. Those are different things.
pjmlp 8y ago
Quite right, but then Web FE devs will tell you how HTML/CSS are so much better than native toolkits, as if.
muxator 8y ago
How true. Lately I am also starting to have problems with my default Firefox setup, which blocks 3rd party cookies and trackers. The result? A lot of (in my opinion) lazily coded websites break, without ever catching a single error, because they were put together assembling external services and skimming on testing. Normally everything more or less works with my fallback chrome in its default configuration, but then I feel we are more or less back to "optimized for ie6" days.

paglia_s 8y ago

The problem with this post is that React, an UI library, is being compared with toolkits that in some cases are simply Java-to-JS compilers. To make a fair comparison there should also be a plain js example

lemming 8y ago

I'm a bit mystified why OP didn't include Kotlin on their list. It's very accessible for Java devs, works brilliantly with tools they are probably used to (IntelliJ, Gradle etc) and compiles natively to JVM and JS (and Native these days, if you care about that). It seems like the ideal candidate.

invokestatic 8y ago
Probably because it's not Java. Yeah, it's similar to Java and runs on the JVM, but it ain't Java. Confusingly, the author uses the term "JVM" in the title but then discusses strictly Java in the article itself.
skybrian 8y ago
Kotlin's JavaScript support has been around for a while but I was under the impression that it wasn't used much. Is there a community using it now and is it getting much support?
- cutler 8y ago
  Kotlin may be a nice language but its HTML library: https://github.com/kotlin/kotlinx.html ... is an abomination.

Twirrim 8y ago

It's interesting seeing GWT producing small javascript. I must admit I have been somewhat biased against it given prior experience. It used to be used for the AWS console all over the place, on the theory that it would be easier for the service devs to also write the console code. That got eventually overhauled to the far superior form it is now. The Javascript that used to be produced was enormous, and of course on a per-service basis, and it had a big overhead on the parsing and running stakes. If any of you was using the console maybe 5 or so years ago, you'll know what I mean about the console loading experience (it was fine once the javascript got processed).

skybrian 8y ago
AdWords is a huge service. It was the largest GWT app out there and always pushing the limits. It was entirely rewritten when they moved to Dart. It's hard to say how much of the improvement was due to better language-level tools versus having learned a lot since then. The GWT team at Google went on to write the j2cl compiler, and based on Github commit history, they're still working on it: https://github.com/google/j2cl https://github.com/google/j2cl

acjohnson55 8y ago

Scala.js is also an option. https://www.scala-js.org/ https://www.scala-js.org/ It skips the JVM altogether and complies Scala to Javascript. I haven't used it for anything significant, but I've heard nothing but good things.

threeseed 8y ago
I am using it now and it's solid. Recommend combining it with: Slinky React (https://slinky.dev https://slinky.dev) JSON RPC (https://github.com/shogowada/scala-json-rpc https://github.com/shogowada/scala-json-rpc) Diode (https://github.com/suzaku-io/diode https://github.com/suzaku-io/diode) Scalably Typed (https://github.com/oyvindberg/ScalablyTyped https://github.com/oyvindberg/ScalablyTyped) Being able to use almost every React library but with full types and code completion is amazing. And with JSON RPC you can treat Client -> Server as though it's just another method call.
forty 8y ago
I reimplemented flux example in scala.js a few years ago. It really looks great, not so different from the js code but all strongly typed. https://github.com/forty/scala-js-flux-example https://github.com/forty/scala-js-flux-example

jarym 8y ago

For all that people wanted to run away from Java’s ‘complex’ toolset it seems modern JS has managed to recreate most of it. I wonder if we’ll do a loop with JSON and end up back at XML

doctorpangloss 8y ago
We did, GraphQL is the new XML.
- goatlover 8y ago
  Yeah, I don't understand the love for GraphQL. It seems over-engineered and difficult to get started with.
  - geezerjay 8y ago
    GraphQL gets a lot of love because it presents itself as a solution to a considerable and all too frequent problem: get the front-end/client teams to coordinate with the back-end teams. This is more of an organizational ans project management problem than a technical problem, thus their advocates are ok with the trade-off.
- yen223 8y ago
  How so?

itslennysfault 8y ago

This is a crazy argument IMO. JavaScript tooling is stupid simple if you know what you're doing. Learning something new is always hard so if you're new to JavaScript (and have a JVM background) of course it'll seem hard at first. I love node 'cause it "just works" (but really it does). The app I work on is node TypeScript Nest.js backend and TypeScript Angular frontend. The set up process for a new dev is install node (takes like 10 seconds), clone the repo, npm install, npm start. Ready to start developing. TypeScript is as simple as installing typescript, and running tsc from the command line. With ts-node you can simply make your npm start script "ts-node ./index.ts" and you're off and running.

wpietri 8y ago
> JavaScript tooling is stupid simple if you know what you're doing. Do you mean simple, or easy? I think the latter. The JS tooling seems well optimized for the novice user, but I think it's hard to argue that it isn't complicated behind that friendly face. Also, I think most things seem easy once you know what you're doing. Almost tautologically so.
cutler 8y ago
The trouble with Typescript is that the corporates have gotten their hands all over it as a means of turning JS into Java. TS turns lean, functional JS into an over-engineered smorgasbord of classes, interfaces and general OOP nonsense. JS was designed primarily as a functional language.
- pault 8y ago
  This runs counter to my experience. I've found that TS will confirm to any style of programming you prefer to use. If you want to avoid classes and inheritance, just type your functions and data structures and call it a day.
- dboreham 8y ago
  >lean, functional JS into an over-engineered smorgasbord of classes, interfaces and general OOP nonsense Aka "code that someone other than you can understand"

cromwellian 8y ago

J2cl (successor to GWT) produces even smaller code.

tlrobinson 8y ago

This is a pretty unfair comparison for React. He uses the "JavaScript has complex toolchains" excuse to not use best practices like JSX and a bundler, then claims React is verbose and slow compared to other solutions that use complex toolchains? First of all, Parcel is a dead simple to use bundler that supports JSX, hot reloading, code splitting, and various file types (including TypeScript) out of the box: https://parceljs.org https://parceljs.org Second, that React code is much longer than it needs to be, mostly due to formatting, but if you use function components and React "Hooks" it can be extremely short: const Counter = () => { const [count, setCount] = useState(0); return ( <div> <p>The current count is {count}</p> <button onClick={() => setCount(count + 1)}>Increment</button> <button onClick={() => setCount(count - 1)}>Decrement</button> </div> ); }; With the imports and call to "render" it's about 15 lines of code, which is much shorter than all of his other examples. The class version (written how I'd do it) is about 25 lines, which still shorter. Here it is without JSX, using Preact's HyperScript-style `h` instead of `React.createElement`: class Counter extends Component { constructor(props) { super(props); this.state = { count: props.count || 0 }; } increment() { const { count } = this.state; this.setState({ count: count + 1 }); } decrement() { const { count } = this.state; this.setState({ count: count + 1 }); } render() { const { count } = this.state; return h("div", h("p", "The current count is " + count), h("button", { onClick: () => this.increment() }, "Increment"), h("button", { onClick: () => this.decrement() }, "Decrement") ); } } And of course these are toy applications, which aren't even representative of real applications. I'm not sure I can go back to imperative UI toolkits like GWT, etc. The application size seems approximately accurate, but if you really care about bundle size you could use Preact (which supports most of React's features). The brings the bundle size down to about 10KB, which is also much smaller than his examples. Load time is also unfair due to lack of bundling.

blunte 8y ago
The early part of his post listed the challenges in doing front end dev because of the many (and frequently changing) options and varying online guidance on how to do things. Undoubtedly there exist better combinations of tools, but as someone just starting front end exploration, knowing what is the right combination is virtually impossible.

wwweston 8y ago

Interestingly, even as a one time front-end specialist, I'm leaning the something same direction this author did: the complexity introduced along with front-end frameworks/tooling treads near (and in some cases beyond) a border past which I stop feeling like working with JS itself is a win. The more the development process treats the browser as a runtime target for generated code, the less point I see in sticking with JS -- or even augmented versions of it -- as a source language. And I like JavaScript. Of course, I don't much like Java, so that's not where I'm likely to go, but I am struck with what the author demonstrated here regarding that as an option. Like the author, I'm very curious about something like Elm; if I'm going somewhere with a type system, I'd like to go further along the spectrum of benefits types can provide. And I'm also not sure we've reached the apex of possibilities of working more directly with HTML/CSS/JS, but that's highly domain/application dependent and another topic.

theptip 8y ago

In a similar vein, I have been idly wondering about the viability of using Python for building browser apps recently: Http://brython.info Http://pypyjs.org No idea what the performance is going to look like for webasm, but might be a worthwhile sacrifice if the developer productivity gains were good enough (using the same language for FE and BE makes many things easier).

aitchnyu 8y ago
Here is Mozilla bringing Python to Browser via WASM, a few science benchmarks run faster in WASM than CPython, others get upto 12x slower. https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/ https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scien...

xx4xx4 8y ago

oh, i know now

ralusek 8y ago

Use `create-react-app` you absolute maniacs.

truth_seeker 8y ago

GraalVM is also an alternative. It might be able to run your existing NodeJS project on JVM. https://github.com/graalvm/graaljs https://github.com/graalvm/graaljs