This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-20
Channels
- # announcements (2)
- # architecture (5)
- # beginners (118)
- # cider (5)
- # clara (13)
- # cljdoc (8)
- # cljs-dev (49)
- # cljsjs (2)
- # clojure (107)
- # clojure-dev (9)
- # clojure-europe (3)
- # clojure-italy (58)
- # clojure-japan (2)
- # clojure-nl (6)
- # clojure-spec (89)
- # clojure-uk (27)
- # clojurescript (9)
- # core-async (33)
- # cursive (2)
- # datascript (2)
- # datomic (31)
- # duct (4)
- # emacs (1)
- # events (1)
- # figwheel-main (1)
- # fulcro (69)
- # hoplon (7)
- # hyperfiddle (16)
- # incanter (4)
- # instaparse (4)
- # kaocha (1)
- # mount (2)
- # nrepl (19)
- # off-topic (40)
- # onyx (6)
- # other-languages (3)
- # pedestal (2)
- # re-frame (48)
- # reagent (2)
- # reitit (10)
- # ring-swagger (9)
- # shadow-cljs (63)
- # spacemacs (13)
- # sql (8)
I think it’s a pretty big deal that both Reason and Flow is just an npm install
away
installing the Reason editor integrations is a bit awkward but at least it’s using familiar tools
and it pretty quickly gets people up and running in an environment they already know (e.g. VS Code & npm)
Just a data point - I have to say that familiarity is a big deal where I work too. Everybody enjoys how easy it is to use npm
for installing stuff.
One of our frontend devs picked up Reagent with no prompting from me. He liked it, and thought it was easier to use than React + Redux. He showed it to one of our fullstack devs, who didn’t like it. Another fullstack didn’t like that HTML was data structures in Reagent, and that JSX was better.
But React as Facebook uses it has slowly been converging with React as it’s used in CLJS for a long time now. Hooks looks a lot like Reagent’s model. I predict that JSX will be thrown out in favour of a data representation of HTML sooner or later.
@didibus most likely because the learning curve is also high, and therefore it's used more often by people with more experience, which earn more because of there experience, and probably not or to e much lesser degree because the know CLJS. It's hard to draw conclusions from such research.
Right, though, what is it about experience that draws people to it? Like, more experience could have pushed you away from it, and into something else like TypeScript or Reason
I wonder if that's rooted in Java. Like people coming to JavaScript from a pre-web era, which are maybe Java devs already, so ClojureScript is less daunting? But newer devs might only have JavaScript experience, and then the Java aspect is actually an issue?
Or you have to be very experienced and at a large company (thus redundant/resilient to experimental projects) for someone to let you use it.
If I wanted to create something in the browser that would involve pixel display" (in a grid with zoom and such), would it be better to print pixels (as rects e.g.) on a canvas or to use many SVG elements?
Also, if I wanted to have, say, some hover effects or tooltips, what would then be better? I know I can create handlers for SVG elements, but that would be many, while I could also handle mouse events on the canvas and figure out where I am at by calculations.
are you trying to do charting/plotting?
oh sorry, I tend to overlook these replies 😕 no, not really. It's more or less simple image transformation: the user can upload an image, then it is transformed and the result is output on a canvas (so far).
That means I basically draw one rect/circle (user choice) for each pixel, and offer a limited zoom option
OK, then I don't have much to offer - svg probably would be 'easier' though
(depending on what you are using - Im assuming something like reagent in clojure not Jquery in hfil)
@henrik I think JSX is here to stay IMHO. React elements are already a data representation of HTML
@emccue Yes, the code would most likely be much simpler. I'm using a react wrapper (it does more than wrap) called Reacl though; but that just means the declarative syntax would be even nicer.
I think another point for SVG is that my images will be more or less static, i.e., they won't change much if at all.
@johb.maier the fastest (though probably not the most pleasant to use) would be to fill a Uint8Array with your RGBA data and use putImageData
. You can create a Uint32Array view into it's array buffer so you can at least treat each pixel individually without messing with individual colour channels.
once you have that data, you can scale/zoom either the canvas directly or with drawImage from another canvas. You can move that over to webgl if that's still not enough, or you need nearest-neighbor filtering which only some browsers will give you
@mseddon I didn't know that was possible, thanks. It's definitely something to think about since I initially parse the data I get as such an array anyway.
np! I would probably start here + a canvas. Avoid webgl unless you really need the speed 😉 https://developer.mozilla.org/en-US/docs/Web/API/ImageData