Fork me on GitHub
#clojurescript
<
2020-02-06
>
Ivan Koz00:02:19

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

sova-soars-the-sora00:02:36

@nxtk rum in cljs and selmer on the clj side have been quite good for me

sova-soars-the-sora00:02:56

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.

sova-soars-the-sora00:02:00

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

πŸ‘ 4
jaime05:02:47

Hello! Which testing library and runner will you recommend for testing individual components and testing the app in the browser? In javascript ecosystem, there are: β€’ react-testing-library - For testing individual components, by mounting it in the dom and simulate user interactions (click, typing...) https://github.com/testing-library/react-testing-library β€’ Cypress - For browser testing, opening the browser and do the actual interaction (think of selenium) https://www.cypress.io/

herald12:02:40

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

herald12:02:34

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

jaime13:02:59

This is probably a new perspective in testing. I should try it out! Thanks a lot

πŸ‘ 4
jaime05:02:12

devcard is cool, it's like storybook. I just found out storybook was inspired by devcards? https://twitter.com/bhauman/status/1032329502603530242?lang=en

herald09:02:49

Not sure if the storybook team knew about devcards, but that story repeats itself a lot in clojurescript. re-frame also came before redux!

athomasoriginal18:02:31

@UNL0HK5ME We use react-testing-library for our component library at work. Amazing tool!

jaime06:02:28

@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?

Kamuela09:02:22

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?

thheller09:02:13

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.

andy.fingerhut09:02:39

Out of curiosity, could you imagine someone preferring Node.js on the server if they were much more familiar with JavaScript libs than Java libs?

Kamuela09:02:04

Well that's exactly my situation @andy.fingerhut, and I like the direction of travel of the JS ecosystem as well

andy.fingerhut09:02:44

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?)

Kamuela09:02:42

So, I guess I would be missing out on a superpower I've already never experienced. So far, still a net positive

Roman Liutikov09:02:42

connecting to node/cljs REPL server on prod would mean you’d have to use bootstrapped cljs, which is not that common

thheller10:02:24

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

p-himik10:02:44

How exactly does it get worse?

thheller10:02:03

the worst part currently is the ESM situation, moving to the strict commonjs->ESM interop variant is gonna break a lot of stuff

thheller10:02:20

also ESM is too restrictive so many packages still cheat .. which also breaks in strict mode

thheller10:02:30

or just don't ship ESM at all ...

p-himik10:02:22

Apart from modules, do you see any other issues?

thheller10:02:30

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 ....

thheller10:02:15

and it just keeps going ... a new version of the language every year is complete madness

p-himik10:02:37

Ah yeah, Babel is now a "people's standard", heh.

thheller10:02:04

I'm biased because I have to deal with this shit from a build tool perspective

p-himik10:02:15

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.

thheller10:02:07

first of all the JVM has a much better backwards compatibility story

thheller10:02:37

and yes the new release cycle is kinda weird BUT you can decide to upgrade and have full control over it

p-himik10:02:30

Oh, how is JS backwards compatibility bad? Again, apart from the modules.

thheller10:02:40

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

thheller10:02:05

I hope they'll eventually stop doing that but as of now they don't

thheller10:02:04

the language moving forward and stuff isn't necessarily bad ... how the ecosystem is handling that is

thheller10:02:51

that isn't limited to JS but also to many libs

p-himik11:02:15

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.

thheller11:02:42

again ... ecosystem issue ... by transpiling many libs contain some transpiled boilerplate code

thheller11:02:50

repeated over and over and over again

p-himik11:02:29

I see, thanks.

thheller11:02:14

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.

p-himik11:02:30

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.

Kamuela11:02:24

I think the tooling perspective does bias you a bit because you're doing the hard work that I don't have to πŸ˜›

thheller11:02:26

personally I'm done with JS and wouldn't recommend it to anyone πŸ˜›

4
thheller11:02:09

react for me was the last straw

thheller11:02:32

hey we added this new feature ... but to use it you have to rewrite all your code πŸ˜›

πŸ’― 4
Kamuela11:02:06

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

p-himik11:02:14

Maybe CLJS on top of Node.js will be able to change your mind.

thheller11:02:15

for the most part we are all still figuring this out and nobody knows how to do anything ... so some breakage is expected

thheller11:02:44

node just isn't a platform I'd chose for servers

thheller11:02:02

its great for CLI scripts but thats about it πŸ˜›

Kamuela11:02:27

It's really tough in that I write Node.js for servers everyday haha

thheller11:02:54

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 πŸ˜‰

Kamuela11:02:44

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

p-himik11:02:26

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.

p-himik11:02:35

And what do you mean by the atrophy of the Java ecosystem?

Kamuela11:02:40

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

p-himik11:02:53

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++.

Kamuela11:02:13

Except that Node and browser have an interop story with C++ in more than one way, now even with WASM

p-himik11:02:33

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.

Kamuela11:02:05

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?

Kamuela11:02:08

Again, not a holy war, I just see JS and its compiler targets as more future-proof

p-himik11:02:27

> does it have that kind of widespread support from industry? It does. :)

johnj00:02:41

nodejs powers the frontend servers on some big companies, netflix, wallmart, ebay, many more well known

johnj00:02:05

and they all contribute back bug fixes, so its pretty solid stable

johnj00:02:31

still prefer JVM/Clojure, but nodejs is no toy

shaun-mahood16:02:38

@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.

shaun-mahood16:02:53

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.

Kamuela16:02:04

Thanks for that rationale article; I hadn't seen it before. Yeah this is how I lean but... it feels very frowned upon

shaun-mahood17:02:58

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.

lukasz16:02:29

I'd consider cljs-on-node only for simplest usecases, or where nodejs is the best supported platform e.g. lambda

βœ”οΈ 4
jeroenvandijk16:02:29

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)