This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # architecture (2)
- # aws (18)
- # babashka (7)
- # beginners (149)
- # bristol-clojurians (4)
- # calva (11)
- # chlorine-clover (1)
- # cider (8)
- # clj-kondo (2)
- # cljdoc (2)
- # cljsrn (2)
- # clojure (186)
- # clojure-canada (3)
- # clojure-europe (3)
- # clojure-gamedev (5)
- # clojure-italy (1)
- # clojure-nl (13)
- # clojure-norway (4)
- # clojure-spec (25)
- # clojure-uk (32)
- # clojurescript (75)
- # core-async (2)
- # cursive (16)
- # data-science (3)
- # datomic (20)
- # docker (1)
- # emacs (26)
- # fulcro (7)
- # graphql (1)
- # incanter (1)
- # leiningen (1)
- # luminus (7)
- # malli (7)
- # mount (11)
- # off-topic (19)
- # pathom (15)
- # re-frame (9)
- # reagent (9)
- # remote-jobs (4)
- # ring-swagger (4)
- # shadow-cljs (63)
- # spacemacs (11)
- # sql (2)
- # vscode (7)
thank you guys, if you have anything to add, just tag the hell out of my nickname, i'm grateful for any advice and direction
layout and CSS... your HTML pages can be html sources or you can mix html files with hiccup-esque code in selmer, gives you that php power to inline include stuff more-or-less.
ideally your layout is modular or regular enough that you can break it into several components that are included, and specifics that are rendered for other pages. don't be afraid to use multiple CSS files, don't be afraid to create multiple versions. use version control. like github. update things accordingly, bump them along when you change them, try not to irreparable delete something that was working without first replacing it with a new working standard
You can write JS Cypress code to test a CLJS webapp. You might be able to use CLJS interop to write Cypress tests instead; I know you can with taiko. https://github.com/filipesilva/create-cljs-app/blob/4bd7a633521d4a3759bf9435c5a0ce25a88c4cfe/template/src/e2e/core.cljs
As for react-testing-library, I haven't tried using that from CLJS, but I've seen Enzyme used in CLJS before. Generally most projects don't do interaction testing of components, and just use devcards for visual testing. You can do this by manually looking at the devcards as you make changes, or by automating it. https://juxt.pro/blog/posts/visual-testing.html
devcard is cool, it's like storybook. I just found out storybook was inspired by devcards? https://twitter.com/bhauman/status/1032329502603530242?lang=en
Not sure if the storybook team knew about devcards, but that story repeats itself a lot in clojurescript. re-frame also came before redux!
@UNL0HK5ME We use react-testing-library for our component library at work. Amazing tool!
@U6GNVEWQG cool! I'll give it a try, with shadow-cljs it should be smooth. What about browser testing? Are you using cypress as well?
Is server side CLJS frowned upon? I mean if you technically have the option to use the JVM, do most consider it silly to host on Node? My experience is heavily within the Node ecosystem —is CLJS there a first-class experience?
CLJS works just as well in node as it does in the browser. I'd still never write a "server" hosted on node if I have a choice. Clojure is just so much better, eg. actual threads with shared memory between them.
Well that's exactly my situation @andy.fingerhut, and I like the direction of travel of the JS ecosystem as well
I guess having a Node.js web server would maybe prohibit being able to attach a REPL to a live running server? Whereas in Clojure/Java that is possible because of multiple threads (not the only reason why multiple threads are useful, but just one example?)
So, I guess I would be missing out on a superpower I've already never experienced. So far, still a net positive
connecting to node/cljs REPL server on prod would mean you’d have to use bootstrapped cljs, which is not that common
IMHO JS keeps getting worse ... not better, so I'd stay as far away from node as possible. It is still extremely hard to build something in JS that does actual work. Scaling something up in node using workers is a lot harder than on the JVM with threads and shared memory
the worst part currently is the ESM situation, moving to the strict commonjs->ESM interop variant is gonna break a lot of stuff
also ESM is too restrictive so many packages still cheat .. which also breaks in strict mode
then they keep piling on features which you can never be sure that the "consumer" actually supports. so you always end up with some transpiled garbage ....
and it just keeps going ... a new version of the language every year is complete madness
Yeah, I get that. But actually, Java had accelerated its release cycles as well, hadn't it? The only difference is that you can just say "works with Java 13, no less", but that doesn't really work with browsers.
and yes the new release cycle is kinda weird BUT you can decide to upgrade and have full control over it
it isn't bad ... it doesn't exist. effectively a huge chunk (probably like 90%) of the code on npm is ES5 with various levels of transpiled polyfills
the language moving forward and stuff isn't necessarily bad ... how the ecosystem is handling that is
Not sure I understand. OK, we got ES5 with transpiled polyfills. But it should continue working in the newest versions of the browsers, despite all the new language features, right? That's what I mean by being backwards compatible.
again ... ecosystem issue ... by transpiling many libs contain some transpiled boilerplate code
the ecosystem is breaking because it is getting to its limits. I hope they figure this mess out in time, right now I only see it getting worse.
like do you think this page needs 24,7mb of JS? https://clojure.atlassian.net/projects/CLJS/issues/?filter=updatedrecently
Hah! I did wonder why the tracker is so slow.
Also, seems like they request JS files twice, the first time with
cache-control: no-cache for some reason.
I think the tooling perspective does bias you a bit because you're doing the hard work that I don't have to 😛
hey we added this new feature ... but to use it you have to rewrite all your code 😛
I think the rewrite things don't bother me as much because it's what I'm used to. I don't have a lot of experience in crystallized ecosystems
for the most part we are all still figuring this out and nobody knows how to do anything ... so some breakage is expected
but if you write mostly CLJS and use as little JS as possible you can also start with node and migrate to CLJ when you are annoyed enough 😉
And I see myself using Clojure more on backend applications than front-end ones. It kinda sounds like maybe I just need to embrace Clojure. I truly worry about the atrophy of the Java ecosystem
Maybe it's worth even more then, to try and switch to something else? I've changed a few languages along with ecosystems, and all of the switches have given me some valuable knowledge.
I'm looking at some of the data science stuff that's coming out for JS right now, visualization and Tensorflow.js as well, that seems very new and cutting edge. Java feels left behind
Data science in JS sounds painful as hell. I've dealt with data in Python. Now I try to not touch it if I can help it. There is TensorFlow for Java. At least, some version of it. And if anything, JS here definitely lags behind - after all, TensorFlow was written in Python/C++. :) But that's not a good reason to start writing in Python or C++.
Except that Node and browser have an interop story with C++ in more than one way, now even with WASM
Not sure I understand that "Except" part. Java also has JNI, so that's not really an argument. And as it has been stated somewhere here previously, WASM is not perfect and doesn't always work properly or work at all.
I'm not necessarily trying to get into a holy war because I'm not "on a side" for the sake of it, I'm specifically talking about my concerns with Java. WASM is under development and support from a huge consortium of the biggest companies on the planet. That makes me comfortable that it is a useful target. I don't know enough about the JVM, but does it have that kind of widespread support from industry?
nodejs powers the frontend servers on some big companies, netflix, wallmart, ebay, many more well known
@kamuela You could take a look at https://macchiato-framework.github.io/ (the rationale at https://yogthos.net/posts/2016-11-30-Macchiato.html has some good background as well) - no idea how much it is used, but I know that at least one large shopping site was running CLJS on Node as part of their back end a few years ago and were pretty happy with it when I talked to them about it.
If I were comfortable with running node on the server, and had a good option for talking to databases, I would definitely choose it over learning the JVM. I came from a .NET/JS background and my least favourite thing about learning Clojure and CLJS has been learning all the quirks and background Java/JVM knowledge that I was lacking.
Thanks for that rationale article; I hadn't seen it before. Yeah this is how I lean but... it feels very frowned upon
I wouldn't worry about it, you're going to know the specifics of your situation and requirements better than we will. Worst case, you learn a bunch and can rebuild using the JVM. Best case, you learn a bunch and don't have to.
I'd consider cljs-on-node only for simplest usecases, or where nodejs is the best supported platform e.g. lambda
I'm building a lambda function in Sci to run via nodejs on AWS Lambda. I'm doing this because nodejs (and python) is the only option to have an inline definition in Cloudformation. This allows me to test my functionality locally (in clj) and without further difficulties push it too AWS via Cloudformation (one step)