Good Morning!

Morning 🙂

I'm curious, what are you using (if at all) for rendering the frontend with Clojurescript, i.e., component library?

helix at the moment

I’m experimenting with https://htmx.org/ for my side project, for some oldschool-but-newschool server side html work. Pretty happy with it so far, but it’s not a complex application that I’m using it for.

but I am really disillusioned with react, at this point with cljs I think one doesn't need react although it depends what is the goal of the thing that we are building, personally I am not a fan of using something because it's popular (so other people can be hired and start working next day, which is the only reason anyone cares about popularity)

thank you both, reading. I've never really been a frontend dev, although I have done an experiment using vuejs + bootstrap-vue. So, whilst I'm playing with Clojurescript atm, I'm just a bit unsure/lost as how to make the frontend pretty.

Morning

the real difference between front/backend development is not just in the tools though

For styling, I’d say just use https://getbootstrap.com/ if you’re unsure. Easy to drown in all the options otherwise. If it’s more of a learning experience, you can use no styling tools whatsoever, of course.

yeah, I still think those are the very very very easy problems

what styling. I mean, it's hard to make a good CSS system that doesn't end up making your life difficult, but not harder than writing any good software system

I was a bit surprised that our frontend team don’t use a CSS library/framework — but then we have a full-time UI/UX person who has created our “house style” from scratch…

yeah, that works best

(they’re a big fan of Adobe XD and apparently now they can design “components” and export them to all sorts of media, of which CSS is just one flavor)

1. BE devs have their environment fully in control, usually a single system FE devs need to consider people using multiple different devices, different OS, different screensize, different capabilities (e.g. touch or not) 2. BE devs have control when they change the runtime, FE do not, we use what the client use 3. BE devs have sync db connection, you write save-to-db and next line you know your data is saved (or something went wrong), FE devs have localStorage which is a bad k/v database, or you need to include something heavy like datascript to have database that's moderately useful 4. However, another really big issue is due to the nature of the problem BE devs write software whose output will be consumed by other software, you can do linear state transitions and everything will be fine most of the time. That never works for FE For frontend, all the state that is represented must be thought as "shared" even if they are not actually related in any other way, because to be able to construct a proper FE experience, you often need to implement effects that affect the whole visual experience. Linear state transitions are not good enough anymore.

It’s all wizardry to me…

these are the difficult problems imho in FE

Oh yeah, the FE stuff is off-the-charts hard. I don’t know how they get anything done. The daily standup is always a revelation when the FE folks talk about what they’ve been blocked by…

a bit of clarification on my side. It's not so much the styling, it's the ability to do things, i.e., to "react" (pun not intended), to things. i.e., pull down data from the server, render it in a table, make each row clickable, fire an event. Add a button to a row, make that do something as well, show a dialog box, let the user click on it, handle the yes/no response...and then, yes, make it look pretty.

I echo @seancorfield's feelings here. FE just feels so hard 🙂

well, I think I have learned it so that I can reliably implement things, but without clojure and without lots of clojure talks I would've never been able

required me to switch mentality several times

I like the warm bosom of backend dev, it's just data flowing in and out, with transformations 🙂

Today, I updated our “deploy to production” console (which is built into our overall staging system admin app) and I wanted to display the versions of JARs on staging vs production — and that requires calls out to staging and production so I decided to display the page and then use JS calls back to the server to initiate those and populate the table. Writing the BE code to go fetch the versions took me maybe fifteen minutes. Writing the FE code to do the async calls and update the page in the browser… took me f’ing hours! I hate JS.

heh

shouldn't take that long

Almost anything I do with JS takes me hours.

i mean, if it's the same work

yeah, it's a lot about practice and dev environment

I tend to look at myself as both, but it usually ends up like this.

also about integration testing, I don't agree with dnolen that automated tests are not useful, I refactored a big chunk of FE last week, at the end I ran the tests, caught all the remaining issues and I was able to not waste time with manually clicking around. Testing FE takes way too long, people just ive up 😞

but these tests start with loading the page, clicking on elements, typing realistic values, reading the DOM, checking sizes of DOM elements... it's not just an 'assert'

😄

i know most tests aren't just asserts, but our python tests are almost all just that

btw, the 4th issue, and I can't let it go if went this far, I think ultimately leads to the conclusion that encapsulation on the frontend is a much worse idea than anywhere else

I got my final proof for this when I read this github issue:https://github.com/facebook/react/issues/11527#issuecomment-360199710

> I want to highlight that in typical React apps that rely on `setState()` this is the single most common kind of React-specific refactoring that you would do on a daily basis.

Our FE team are big on automated testing. And every new feature and every bug fix they do gets tests.

Imagine being told that most of your job is to rewire what you did yesterday?

We’ve had automated BE tests for a decade and we keep adding to that suite but we’ve only recently had completely automated deploys from our CI system (I’ve tweeted a couple of times about my battles with BitBucket Pipelines lately). I’ve also been working on simplifying and streamlining our build/deploy pipeline to the point where a deploy of most of our apps — 14 of them — is completely automatic to staging, based on CI builds passing, and then just “select & click” in the admin console to get them to production (which our product manager / QA folks can do whenever they want — including running SQL migrations).

Automated tests are awesome. They have helped our team multiple times spot side unintended side-effects of new features

Automated deploys of all the shell scripts etc that support processes on staging/production is a little less automated — because we don’t have any real automated tests around the shell script stuff — but even there it’s a single command from anyone’s dev setup to get the appropriate scripts on staging and then a single (manual) command run on staging to get that same bundle out to all the production servers if it “passes QA” on staging. So I think that’s my next target for Pipelines 🙂

And then, finally, there’s the two legacy CFML apps (yes, really), and those are also now down to a local command to package them and push to staging, followed by a few scripts to deploy them and restart the CFML engines. And a single command to push them to production, followed by a similar manual script step on production. Def. better than it was even a month ago. Of course we are actively rewriting those CFML apps to Clojure (and have been for years — it’s a lot of work) so that we can get to the same, fully-automated test & deploy CI process for those too.

I didn't intend to say dnolen is against all automated tests, just in context of FE testing the other day he told me this https://clojurians.slack.com/archives/C03S1L9DN/p1618931137246900

To be fair, he’s advocating a separation that makes FE testing viable/easy — just not testing the UI portion.

Seemed to me that what he described as an ideal situation is specific to his needs, not a generally applicable approach

and there are details that I bet would be causing trouble, like, if as he said all components are in js, that is basically saying almost all the important stuff is not in cljs

-> behavior of generalized components

so what I suspect is happening is that they avoid all the issues from putting behavior in the js components, but that's not really something anyone or any company can do

I can’t comment on the cljs issue since our FE is pure JS — React.js, Immutable.js, Redux, etc — but I know the FE team has worked hard to be able to automate testing of all the components, independent of the actual UI.

they must have great stories 😄

pun not intended

Oh yeah, seriously great stories. I’m in awe of them.

On the topic of testing front end stuff, Cypress is pretty amazing

I’d never heard of Cypress until the recent “State of ColdFusion” survey (like our State of Clojure survey) and it was a popular write-in answer to “What testing frameworks do you use?”

Having suffered the pain of Selenium in the past, I was blown away by how good it is

cypress is great

I am using puppeteer right now though, I think when* I tried Cypress had some dev env issues

on a different note, what do you think about my conviction that we (as in software people :D), should be actively producing many many more browsers for the internet?

What do you mean by “browser” in that?

Do you mean more programs like Edge, Chrome, Firefox, etc?

yes and no

Yes, as in, yes today all browsers are like that, no as in that's why we need more, that we need diversity.

Essentially, if you reverse the situation, what this would mean not for the users of the browsers but the makers of the interfaces that we (FE devs) would not have to repeatedly write the same code. I imagine this whole thing along the lines of what Bret Victor talks about in his talks. E.g. when he mocks APIs, if you have seen it.

How would “more browsers” not mean “more pain for FE devs”?

🙂

Let me ask a different question first: why would anyone use more than one browser?

I only use Microsoft Edge — on macOS, Windows, and Linux.

I use Firefox and w3m

Also: https://www.commitstrip.com/en/2018/12/12/chromedge/

OMG! :rolling_on_the_floor_laughing:

I switched (back, after 6-7 years or so) to Firefox about 6-8 months ago, because there was a bug in some Chrome helper on macOS that kept maxing my CPU that eventually annoyed me enough to lose the benefit of multiple logged in profiles. Firefox containers does that anyway, more or less

And the profile stuff was always more of a pain on Windows, whereas FF containers works the same in both (and Linux)

I think you misunderstood my question 🙂

I meant it generally, not specifically. Why would anyone in general use more than one browser, not why would specifically use more than one browser from the existing ones.

Second question has good answers, I use more browsers because I need to test what I do with them 🙂 Or because they have different 3rd providers baked in, e.g. difference between Edge, Chrome, Brave is just that.

It's otherwise literally the same 'browser' experience.

Think of it like this, how many other kind of browsers do we use, next to the web browser?

mogge

I'm thinking of buying a microphone. Does anyone have an recommendations?

morening

morning

Morning

@dharrigan: re-frame for me