This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-07
Channels
- # aleph (1)
- # announcements (2)
- # babashka (1)
- # beginners (49)
- # calva (1)
- # cider (5)
- # clj-kondo (14)
- # cljdoc (11)
- # cljsrn (6)
- # clojure (120)
- # clojure-austin (1)
- # clojure-europe (6)
- # clojure-finland (3)
- # clojure-italy (29)
- # clojure-nl (6)
- # clojure-spec (38)
- # clojure-uk (14)
- # clojurescript (65)
- # code-reviews (8)
- # cursive (20)
- # data-science (1)
- # datascript (5)
- # datomic (57)
- # emacs (6)
- # figwheel-main (2)
- # fulcro (32)
- # funcool (1)
- # jackdaw (7)
- # jobs (3)
- # joker (7)
- # kaocha (8)
- # keechma (3)
- # nrepl (7)
- # off-topic (25)
- # quil (3)
- # re-frame (10)
- # reagent (43)
- # remote-jobs (1)
- # ring (1)
- # shadow-cljs (173)
- # sim-testing (1)
- # spacemacs (1)
- # sql (3)
- # tools-deps (34)
Having seen the latest apropos on youtube yesterday, and reading by on the #clojure-spec I wonder if anything could be changed to make things go faster. Even Java is moving faster, and I understand there are very few people working on it, and they want to get it absolutely right this time. Personally I don't really care, I only got a micro cms using spec to generate validate and create html to edit documents, which is still in pre alpha. But by people thinking about doing Clojure, when they are used to types, and finding out the current state of spec, it's might cause them to stop looking into Clojure.
@gklijs according to https://insideclojure.org/2019/10/06/journal/ it seems like there are things they still don't know how to do.
So I guess this is one of the cases where adding another 8 mothers doesn't necessarily produce a baby in one month.
No exactly, might be it, it's not the easiest problem, and any flaw will be hard to fix in a backwards compatible way.
I've been impressed by the restraint in releasing spec and making sure it's labelled an alpha. It's a little frustrating that it's moving slowly, but IMO that's better than the language bloat that's happened to, say, Rust in the last ~3 years
Don't think Rust is a good example, as it's all backwards compatible and you don't have to use it. And it's a relatively new language. But like Elm with always some breaking changes, that's another story. Or ecmascript, where dispite new constructs you have to transpile always to also make it work with other browsers. I'm also not sure what a good solution would be. Like mentioned in the podcast, you can only get good feedback if it's used.
There's an amount of review you can do to see if spec solves your problems, without actually using it in production. You can think it through, or you can try it on a branch.
Heya, I was looking for a drawing tool for diagrams in cljdoc docs. I started with ascii art but then @martinklepsch mentioned http://draw.io. For whatever reason, I had not noticed this one before. Reminds me of OmniGraffle in the style of diagram it produces. Nice thing is it free to use (outside of Confluence/Jira). https://about.draw.io/
ya, http://draw.io is licensed under apache v2 https://github.com/jgraph/drawio
@lee Perhaps UMLet would be a possibility for you. I like it for its text-driven approach to building up swimlane diagrams. https://www.umlet.com/
I will say that is not what you're looking for if you want lots of different fancy icons for things like AWS services, etc.
@pez The Svelte talk is really interesting, although I had heard all of these arguments before https://www.youtube.com/watch?v=wVXjExRiFy0 I really like the idea behind it, but dislike the custom language/syntax they invented for it. I wonder if there is a way to make a lightweight and fast web ui framework on top of javelin that just uses clojure(script).
@dmarjenburgh what about hoplon?
Yeah, so hoplon uses hlisp
which I’m not sure is necessary. And I tried to do the get started
guide using boot and it started downloading the internet. Huge number of dependencies (including all existing clojure versions). Took a long time and it pushed me away from it.
I recommend watching the “Rethinking Reactivity” talk if you’re into frontend. I like the idea a lot, but many points in Svelte can be done even better in ClojureScript:
- Svelte has a custom compiler - ClojureScript is already a compile to js language. No new Sveltescript syntax to learn
- Svelte can bring in a lot of dependencies and leave out the modules you don’t use in the build - The Closure advanced compilation will optimize it better
- Svelte has custom syntax and repurposes existing js like $: x = y
- In ClojureScript we have macros.
I’m kinda wanting to try creating a simple web UI framework on top of Javelin to see if the experiment will work. Need to dig into Svelte and Hoplon first 🙂
I think the problem that Svelte solves with it’s custom syntax, that CLJS struggles with (being a general purpose language), is creating a way to relate state mutations to DOM mutations that doesn’t require a VDOM
it’s not immediately clear to me how to do this in as ergonomic a way as Svelte with plain macros
Me neither, honestly. But every web framework creating new file syntax and file extensions really bothers me. .jsx
, .vue
, .svelte
, '.hlisp
. Meaning editor plugins need to be created to resolve and highlight code etc. I would be happier with it if it was a compilation step from clj/cljs to cljs without macros I guess.
yeah. I’m very interested in a CLJS native approach to a similar solution. I just am not sure how it would work yet
Definitely a nice hobby research project 🙂