Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#25 - Fulcro and co with Tony Kay @fulcrologic
46 Plays8 years ago
Where we talk about mould, scala and then the good stuff
Fulcro is an opinionated take on om.next that will save you tons of work
Tony is a true gent
Recommended
Transcript
Introduction and Location
00:00:15
Speaker
Is it episode 25? Yes. OK, well, in that case, welcome to Deaf and episode 25. We're here in sunny Belgium and super sunny Netherlands with Vijay.
West Coast Forest Fires
00:00:33
Speaker
And we're in America somewhere in the middle of nowhere with Tony K. The very sunny Sisters Oregon.
00:00:44
Speaker
Is it Oregon? Okay, so you're not super storming it. No, no, in fact, I think we're at the moment we're burning in half is the is this thing we're doing. Yeah, a lot of forest fires. All right, okay. I saw that photograph of the of the golf course and the fire in the background was that was that near you?
00:01:04
Speaker
Um, there are so many fires going in the West right now. Uh, it would be hard for me to say whether or not that was or not. Okay. All the way from California through Oregon, Washington, Nevada, Montana, like the whole Northwest is on fire. Yeah. It's probably just totally normal though, isn't it? You know, nothing.
Extreme Weather Media Coverage
00:01:25
Speaker
No, this is the worst, worst fire season since 2005. I think they said, um, and that was a pretty extreme one.
00:01:32
Speaker
There's no other bad weather in America, though, is there? Oh, no, no, no hurricanes or anything. Is it the global warming causing the fires or the fires causing global warming? Yeah.
00:01:47
Speaker
But the funny thing I heard about was, I think, the tropical storm, the little bit of wind and rain that you had in America that killed about 50 people. And then, oh, everyone's like, it was world news. And then in India, there was a flood that killed 1,200 people, and no one gave a shit. Great. Yeah, that seems to be the way it works. America, USA. Go media.
00:02:15
Speaker
Anyway, so we're talking about the most Belgian thing, the most boring thing in the world. We started off super exciting with the storms and the fires. I
Becoming Belgian: A Personal Story
00:02:24
Speaker
like that you're using most, I mean, Belgian as the synonym for boring. We haven't got there yet. So the most boring thing I've done this week is become a Belgian. So let the cut out a bag of it early there, PJ.
00:02:42
Speaker
Yeah, so to avoid the Brexit bullshit, I've now become an official Belgian citizen, and so have my kids, so we're all good. Nice. And so that's, yeah, that's all sorted. Screw the UK. I'm still a UK citizen, so I can say that with impunity.
00:03:02
Speaker
Right. So Vijay,
Masters of Boring Administration
00:03:04
Speaker
what have you been doing with the most boring thing? I think most of my life has been boring. So you've been doing this Masters of Boring Administration, haven't you? Yeah, indeed. So I'm on the last term of Masters of Boring Administration and I'm just doing my international negotiation. So it's a really nice class and it is run by a professor who is into technology. He's a CEO of many things, blah, blah, blah.
00:03:29
Speaker
So yeah, that is the most boring thing. I think I'm doing right now Other than I don't know starting deaf and again after summer holiday Yeah, yeah, we're back. Yeah, we're back into your 20 20 I know that you're into a lot of boring stuff aren't you Tony you're into testing? So yeah
00:03:55
Speaker
That's a nice way. That's a nice way to insult our guests. It's a pretty boring thing. It's not the most boring thing I've done this week though. Tell
Camper Renovation Adventures
00:04:03
Speaker
me what's the most boring thing you've done this week. I recently bought a really old camper, the kind that you put on the back of your truck and drive out into the woods with. It's got all sorts of issues because it's almost as old as I am. So I've been taking it apart and doing things like scraping mold. Scraping mold.
00:04:24
Speaker
We've got a winner, we've got a winner, Fox. Even testing can't beat that, you know? No. Cleaning up 40 year old, uh, uh, caulking. Yeah. Wow.
00:04:40
Speaker
But I see kind of a theme here. I mean, we keep talking to closure developers around the world.
Remote Living Clojure Developers
00:04:47
Speaker
And most of them are like hermits. They live in remote places with no human contact or anything. I don't know what it is with closure people. So eventually, once I pick up the full time, I'm going to end up in Himalayas or something. I don't know.
00:05:08
Speaker
You live in the middle of nowhere in Oregon, then, Tony? Yeah? I do. Yes, I do. It's actually not my total preference, but I've sort of ended up there. Isn't that where they did Little House on the Prairie, if I'm not wrong? No, I think Little House on the Prairie was actually in the prairie. Oregon is... Oh, I thought it was really in Oregon. The meme going away.
00:05:34
Speaker
Oh, I don't know where I don't know where they actually made the show. They probably made it in Southern California. But yeah, it was it was set on the Great Plains. No. All right. Okay. Okay. Well, I've got about as much American geography knowledge as you have of as Americans have of the rest of the world. Right. Sorry about that. Yeah, Belgium. It's somewhere near Italy, right? Yeah. Yeah. Yeah.
00:06:04
Speaker
We're definitely more temperamental than the Italians though. Yeah. Efango. Right, sorry, yeah.
00:06:14
Speaker
OK, so I think it would be nice if we do a bit of an introduction. I mean, how did you end up in the middle of Oregon or whatever? But I mean, apart from scraping the mold of a camper van, I'm sure you're very busy with the coding stuff and everything. So can you give us an idea? What do you mean by no feature? You mean, how were you chased out of town, Tony? Exactly. How was I chased out of town?
Moving for Health: Oregon Relocation
00:06:36
Speaker
Yes.
00:06:37
Speaker
Actually, I ended up in the middle of nowhere because of, uh, trying to find clean air for, uh, for my partner at the time who had some health issues. So that was more, that was more the out of town, uh, part trying to get away from the city, the bad air of city. Yeah. Wow. So where were you before? Um, I was in, uh, uh, bend, which was a little larger town here in Oregon. And then before that I was in, uh,
00:07:03
Speaker
Seattle area for a while. So the stench of Microsoft was too much. Yeah, Microsoft will run you out of anywhere.
00:07:14
Speaker
But what were you doing in Seattle and technology work-wise? Yeah, actually, I've been mostly working remote, the dream job of most of the closure engineers that are hermits. I wasn't working in closure at the time. At the time I was in the Seattle area, I was actually working for a company in Oregon. That's how I ended up back in Oregon, is they asked me to come and take over their engineering department.
00:07:41
Speaker
But it was actually a company doing primarily Java. And that was a number of years ago. And I'd been playing with Haskell and a number of other functional programming languages for years ever since graduate school, and had really been aching to get it into the work environment more. And so it was at that company that I started actually pushing a very Java centric. So
Scala Experiences: Complexity and Tools
00:08:06
Speaker
the, the obvious step forward there at the time was Scala.
00:08:10
Speaker
So I pushed.
00:08:12
Speaker
pushed for them to try adopting it. You know, we wrote, I don't know, 20, 30,000 lines of code in it. And then, you know, I really have a lot of appreciation from Martin Dursky's language design skills. I think he did a great job meeting his stated goals of let's maintain, you know, good operability with Java, but, you know, pull us into a, you know, good functional programming, type of functional programming language. But from a practical standpoint, it was, um,
00:08:42
Speaker
I found it to be overly complex in terms of the things you tended to do. Um, like the, the community there tends to fetishize complexity, I think a little bit too much. Um, they see the type system and they think, Oh, wouldn't it be cool if I designed this domain specific language using types, which it is gone. If you've ever seen, uh, like there's a.
00:09:02
Speaker
an SQL DSL over there called S-Query. Is it S-Query-L? I think it's the name of it. Which is, you look at it and if you get it to compile, you've got what you were looking for. But as soon as you start stepping out of the bounds of what the DSL can support, you're writing a more complicated query with more complicated joins.
00:09:25
Speaker
It's messy and then if you need to go extend the library, oh my god, you're in kind of AST type hell. The thing I found about Scala actually Tony, when I was writing it, I remember because I saw Dersky a couple of times, because he's a European as well, so he talked in Belgium and England a few times.
00:09:44
Speaker
I saw him at one of the Java conferences, and he was all about the scripting. Yeah, we can make it nice and light. We can do all the code and all the type inference. Let's get the types out of the way. And yet, as soon as you write a non-trivial Scala program, you have to tell the compiler everything. That's what I found anyway. I find it very hard to use all the type inference. There's a lot of magic in there.
00:10:13
Speaker
And that was ultimately the breaking point for me is the tools needed to be a lot more powerful in order to make it usable. So you needed the thing to be able to hover over something with your mouse to see what it was sometimes. And so if you didn't have an IDE that was really strong, it was difficult to reason about your programs.
00:10:33
Speaker
And maybe that was just design weakness, I don't know, but it was a common occurrence. And then the tools, because they had to be so advanced and because they did these exponentially explosive searches for things, the tools got really slow as your program got bigger. So I remember we had a million lines of Java code that would compile in, I don't know, seconds. And we had 20,000 lines of Scala code that took 30 seconds.
00:10:58
Speaker
Like it was literally two orders of magnitude slower in the toolset. And for a larger program that just became, you know, more and more developer time wasted, you know, even I, you know, even if you were doing test based development, or you weren't wasting all the time clicking through a UI or whatever to try to test the thing you're doing, you're still waiting for the toolset.
00:11:16
Speaker
to build your thing, um, any criminal builds. Yeah. And incremental builds because of that type inference thing, uh, particularly the, um, Oh, what's it called? Implicits.
00:11:31
Speaker
If you accidentally pull in too many implicits, then even an incremental compile could trigger these massive, you know, cascades of compiles that just cost you too much. So that was kind of my first, you know, walk into functional programming in a larger programming environment, you know, everything from, you know, before then had been kind of academic exercises and playing with the tools.
00:11:55
Speaker
And I'd seen closure come onto the scene and had been interested in seeing where that brought us.
00:12:06
Speaker
Yeah, just just one second. I mean, I think what's what's interesting about Scala is all of these big data tools and all this kind of stuff. So I mean, people have written real big programs in Scala. So I mean, I'm a bit obviously like you, I moved from Scala to closure and it's all good. But obviously people are having some success in Scala. So we can't completely. It's true. No, I mean, the way I would have approached it if we'd continued using it would would have been to broken things into modules so that you couldn't trigger
00:12:36
Speaker
you know, these big nasty compiles and interdependencies. It was a lot more management. It was tractable. But it was complex. But you're right. I mean, it's, it is, I think it's a great language. I think it's a, it's like I said, I really think the world of Martin Edersky's design, when I read books about it, absolutely love it. But it's sort of like, you know, I read books about like Bjorn Storstrom's book, C++, right? You know, the design and implementation of C++, you read that book, and you're just like,
00:13:05
Speaker
Wow, this, what a great idea. This is just superb. This is amazing. And then you sit down to use it and you shoot yourself in the foot every two seconds and you're like, Oh my God. And then the compiler goes into an infinite loop because templates are a Turing complete programming language and you can cause infinite loops in the compiler. And right. It's, they're great ideas, but the practicality of it didn't, didn't suit me personally.
00:13:26
Speaker
But isn't it because when you switch to Scala, I think probably 90% of the programmers who are picking up Scala are coming from Java world. So in Java, you're used to this kind of mindset of huge code bases because compiler is fast enough. And then when you transition into Scala, you continue that design thinking, quote unquote, design thinking, and then you bring that in.
00:13:50
Speaker
that messes it up. But if you see Haskell, for example, if you're switching to a language like Haskell, you wouldn't do the same thing. Like, you wouldn't... Of course Haskell compiler is really, really, you know... You've got the same tools issues. Yeah, yeah. So I thought that was the fundamental shift that people couldn't make enough to take advantage of Scala's better features.
00:14:12
Speaker
Of course, there are lots of warts in Scala. I mean, I've been writing Scala for almost six years now. Not six years, sorry. I think, yeah, four years maybe. So we started around 2.8. Then we had some fun with 2829, that fancy time. Right, that whole transition thing from version to version is always fun in that ecosystem.
00:14:34
Speaker
Yeah, but I think the latest thing is when we use 2.11 and then we use APIs, we build APIs, and we also use Spark. And as Ray was pointing out, all the big data things, those things are driven by Scala, at least on JVM. So from my point of view, when you switch from Java to Scala, if you bring in the Java way of writing code, that's much more hard to pick up the functional stuff. So how did you pick the functional side of Scala? What's your opinion on that part?
00:15:05
Speaker
Oh, no, I think it's, like I said, I think the language is wonderful. To me, the ultimate weakness of it was one tooling. I found to be really inefficient and buggy. I spent a lot of time, like if I sat there with a stopwatch and timed how much time I actually built software versus how much time I struggled with tooling, it was too high of a cost for me. But I want to love the language. I really do like the,
00:15:34
Speaker
the theoretical of it. It's the practical of it that kind of caused me issues. And then, you know, when I started playing with Closure and Saul Richycki's talk, Simple Made Easy, a lot of things fell into place in terms of the thing you're trying to point out there. With object-oriented programming, we have all these design patterns and things that are really workarounds for kind of a paucity of features in a language, right? We had classes, we had nouns, that's what we had. Everything's a noun, the kingdom of nouns.
00:16:03
Speaker
And, uh, you know, he makes some great points around things and I've always been on the fence about type systems because I was also, you know, a little, uh, I started out as a systems programmer, worked in C for years, uh, worked in, in, uh, Pearl, um, you know, in shell scripting and, and various other things. So I'd worked both with dynamic languages that were either loosely typed or untyped or, you know, um, and, and I'd worked in the typed world.
00:16:29
Speaker
And it was always on the fence because certainly types do catch a certain class of errors. There's certain kind of test that you kind of get that's sort of forced onto you. And the better you build your type system, the better off you are in terms of those tests helping you with something. But at some point they break down because they're just a static analysis, right? So like, for example, Closure Spec has this nice advantage of it's more of a dynamic analysis. You can actually check what's going on at runtime, you know, kind of assertion-based thing.
00:17:00
Speaker
Speaking of tooling, this is also one of the criticisms for closure, right? Because people say, you know, tooling is really bad with closure. Well, if you, I mean, recently things are like much, much better with obviously Emacs, you know, being the best editor ever or so, you know. So I think you would agree with that, right? I mean, I don't know which tools do you use. So is it Emacs or something else? So I use IntelliJ with cursive. Oh, okay.
00:17:25
Speaker
And I think very highly of that toolset actually. I do know people that use Space Max. And Space Max is an excellent tool. I don't have any complaints about that at all. And that's, I guess, if you bring that up, that was one of my initial worries about the Closure ecosystem is, all right, it's rather young. The tooling
Clojure Tools Evolution
00:17:50
Speaker
when I started using it,
00:17:52
Speaker
cursive, I don't think had been released yet.
00:17:56
Speaker
I think it was right on the cusp. I think light table was about the cutting edge of what was there. And you had the the emacs, you know, cider kind of things going, but there were pretty unstable still. And that improved really rapidly as I started playing with Closure. So I hit right at the nice cusp. And today I don't really have any complaints about the tooling. I mean, it's on the JVM. IntelliJ and cursive gives me almost everything
00:18:27
Speaker
that I want. And, you know, I rarely find myself trying to pull my hair out. You know, there are some rough edges, but the rough edges that are there
00:18:38
Speaker
are almost always solvable by Kill the REPL restarted. And that's gotten a lot less frequent. It used to be you did that about every five minutes and then we developed better techniques and figured out how to get the hot code reload to work better. And at this point, yeah, occasionally something mysterious is going on where everything just doesn't seem to be working.
00:18:57
Speaker
but it takes like 10 seconds to just clear it all out, clean the compiled stuff and restart, and then you're good for the rest of the day. So yeah, there's still annoyances, but it's not like I press save and I've got to wait 30 seconds while my IDE is hung doing an incremental compile. I don't have those kinds of headaches. That's true. So are you into the whole like REPL driven development stuff as well? Because I think that's a magic of Clojure, frankly.
00:19:24
Speaker
So I do think that's a very... I would classify myself in kind of an interesting way, I guess. I would say when I'm experimenting with a design or trying to figure out an algorithm, certainly I'm playing with the REPL. I particularly love the editor integrations where you can type out your expressions and send them to the REPL and have a real first-class editor support.
00:19:47
Speaker
Um, for that, uh, I do a decent amount of that when I'm actually coding something that I understand, I typically do it more behavioral driven with, with full-flow spec. Um, that's, that's typically how I'll, I'll build things because then I know all those little experiments that I would be running in the REPL. I can run just as fast in a specification and then have that specification sitting around for others to run when they're trying to expand or adapt that code later.
00:20:12
Speaker
So this is a nice, nice back to the boring, back to the boring testing stuff. But before we even go into the testing stuff, I mean, so obviously you're the author or the principal author for Fulcro, right? I mean,
Fulcro's Origin for SaaS Development
00:20:24
Speaker
can you give us some idea about, you know, how did you, how did you come up with the, with the idea to build this thing together and what were you building before and what is the big picture for Fulcro?
00:20:34
Speaker
Right. So I'd taken a job as a lead engineer for a company that needed to revamp their engineering department. And so I was tasked with new software development and deciding on technologies. And of course, I had an interest in one of the new technologies being functional programming. I find immutable data structures and the general functional programming model to be quite good for local reasoning and for keeping bugs out of the way and for efficiency and developer time.
00:21:03
Speaker
And so I really wanted that to be there. So we actually compared, I think F-sharp was in the mix, Scala. We put Haskell on the spreadsheet. It was made a spreadsheet. Put all the languages along the top and then down the side. What do we want? We included, I think, C-sharp and Java. Because some of the concerns were training engineers, hiring people, support for first-class immutable data structures.
00:21:30
Speaker
support for type systems, et cetera. Like all of those criteria, we just listed along the left and then we gave each one a wait.
00:21:37
Speaker
based on our group's kind of opinion of how important is that to us? And then for each language, we just went through and said, here's what it is. And one of the criteria would be availability of libraries, et cetera. And so at first we were just trying to decide what to use on the server. And in our spreadsheet analysis, Closure came out on top, not by a lot actually, by our criteria, maybe only by five to 10 percentage points, but it was enough to say, okay, that's what we should try at least. Let's give that a shot.
00:22:07
Speaker
As we were starting to build the server-side stuff, this is about the time that Bruce Howman's talk came out on Fig Wheel and various interesting things were happening in the front-end side with React and ClosureScript. Ohm, the first original version of Ohm was around and had the great to-do MVC and the time travel demo. I saw that time travel demo and the first thing that popped into my head was support DVR.
00:22:36
Speaker
Like that was the first thing that popped into my head when I saw that. I was like, what is the biggest problem developers have when once they're in production is somebody reports a bug and the bug report sucks, right? The bug report is it didn't work right. Yeah. Okay. So then, you know, you're sitting scratching your head for three hours trying to figure out what went wrong. Well, what if I could just along with my, you know, support requests, send you.
00:23:00
Speaker
a history of what was in the UI that you can play back and actually see what was going on. And oh, by the way, I could put into that data stream timestamps and correlate it with server logs right there. So I can see the second it went wrong, the millisecond it went wrong, and go see, oh, right, that database was down. All right, it's not a bug. It was just an outage. Or
00:23:20
Speaker
I can see the bug and with hot code reload, I could actually edit the code on your data from your UI and see the bug resolve. Like that was just, to me that was the killer feature because so much of our time as developers is spent
00:23:37
Speaker
tracking down crap. Yeah, it's just tracking down and figuring out what's wrong. And if that's such a, that's such a powerful diagnostic tool that, you know, ban all other features, I don't care if I can get that one in my production environment, I'm going to fly 10 times faster. So, so that was really the, the kind of the aha moment. And so then I started pushing towards, we really want immutable data. And, and this, this central atom based,
00:24:02
Speaker
database with pure rendering on the UI because you get this. You get this for free. That's just amazing to me. So that's what got me into it.
00:24:15
Speaker
Yeah, let's say the applications that we were going to be building there, I'm not working there anymore, but that's what we were aiming at was they were just web-based software as a service applications for the hotel industry. Okay. So, you know, data input, data analysis, charts and graphs, you know, your typical web app kind of environment. Raymond, did you have a question?
00:24:38
Speaker
Yeah, we were just going to go on. We're just going to talk about the sort of perennial philosophical part before we go into full-growth proper, which is like, how did you come to decide about frameworks versus libraries? How did you find that evolution? Because I think that's probably part of the history, at least, of what you've been doing recently, is making that sort of decision. It's a tough balance.
00:25:07
Speaker
You know, Fokker was originally named Untangled, and a lot of people probably still know it by that name. And, you know, when I, when I left the company, they had decided not to continue down the closure route, mainly for internal issues. It really didn't have anything to do with the technical. It had to do with, with more with just
00:25:30
Speaker
abilities of existing engineers that were there and their preferences. So it was more of a political battle that didn't get won. So I changed the name of it just to avoid the name. Yeah, the spreadsheets be damned. You still have to convince the legacy programmers that they want to do something new.
00:25:50
Speaker
I do believe in the small set of primitives that get the job done. I do like that philosophy and I think it is a good philosophy, the general, let's make a library. It does one thing, it does one thing well, and then we'll collect libraries together to get our whole. That works for a lot of things.
00:26:12
Speaker
But when you're trying to do application engineering, what you ultimately need is all the pieces. You need the part that you hook up on the server, and you need the part that you set up in the UI. And the more those parts know about each other, the more seamlessly they connect together. And if you look at the history of Untangled, we had a lot of little libraries. We had Untangled client, we had Untangled server, we had Untangled datomic,
00:26:41
Speaker
untangled spec, and all of these were meant to provide just one piece of the puzzle that you could pick and choose, right? You don't have to use the server-side primitives in Folkrow or Untangled. You don't have to use Datomic. You don't have to use, right? But the intention was, if you want to use
00:26:59
Speaker
Atomic, here are the pieces that are already pre-built for you that you can just plug in and move with it, right? Because we wanted fast development. You know, money is time, time is money. You don't want your developers redeveloping how to interact with a server if there's a clear, simple way that they're just going to all write the same way, right? And so FOCRO is based on Omnex. That's what's underneath at the core. And it wants to talk via Eden to a server and transit.
00:27:29
Speaker
You're going to write the same basic things over and over again for developers. Having those pieces available makes sense. Now, what size they should be, how many dependencies they should pull in, that's something I'm always wringing my hands over. I'm always trying to make the libraries
00:27:46
Speaker
give you as few dependencies as possible. And, you know, as you pick and choose things, well, you end up with them or don't end up with them. When I started maintaining fulcrum on my own, then I was kind of forced to do a little bit of coalescing of those things.
00:28:04
Speaker
just from a maintenance standpoint. Just trying to keep things up to date. It's much more efficient for me to be able to edit the server things in the same context as the client things. The number of dependencies that actually get pulled in in the current folklore library, that's the biggest thing that worries me is, yeah, you can pick and choose some piece of the library to use or not use.
00:28:29
Speaker
But the thing you're more worried about is getting infected with a dozen dependencies that you didn't want. That's the thing that you're more concerned about. And so I've tried to keep the server side fairly light. But again, the whole intention is full curl works best in a full stack scenario. You're probably going to use ring on the server side. If you don't, all right, well, maybe it's not the perfect choice for you. You still don't have to. But you're probably not going to be that offended by me pulling ring in.
00:28:58
Speaker
And then on the client side, I stopped worrying about the client side stuff because you've got Google closure. You don't care what dependencies you pull in. You put in advanced optimizations, it code prunes everything you didn't use, and who cares? It doesn't really hurt you. So that's how I landed where I'm at.
00:29:17
Speaker
is I am trying to limit the infection that you get in terms of dependencies you didn't want. So, for example, FOCRO SQL is still a separate library. FOCRO Datomics is still a separate library. You're not getting database dependencies shoved at you when you choose to use FOCRO.
00:29:34
Speaker
So that's the dividing line that I chose for this. Exactly. It's more of an opt-in kind of scenario. But Folkrow, the main library, is here's the minimum you need to make a full-stack, single-page application for the web with kind of all the batteries included that you need.
Full-stack Framework: Fulcro
00:29:56
Speaker
in terms of you need transit because you're going to talk across the network, you need ring because you're going to have a server. Yeah, I'm going to go ahead and supply you with a pre built web server that you can either do in a modular way, it actually is set up two different ways. There's one where you can just say, create a web server for me. It's like one line of code, or
00:30:15
Speaker
There's a module component you can pick up that lets you plug into the server-side API handler plumbing that's pre-built and hook that into any kind of server infrastructure, including servlets, like whatever you want to plug that into, just plug it in. And yeah, your dependency path is going to have a ring in it. All right, deal with it.
00:30:34
Speaker
So that's what's in the main library. And it is an attempt to be as minimalistic as a library as it can be to meet the criteria of, I want to build a full stack single page application. And I think we hurt ourselves by going to the point of saying, you know what? UI library just has to be a UI library. That's all it does. Because if you've got a browser-based, you're in a distributed environment. That's what you're wanting. You're wanting a distributed framework, and distributed systems are hard.
00:31:03
Speaker
why give yourself the pain of having to design the entire distributed, you know, full stack system if there's something out of the box that you can use.
00:31:13
Speaker
So I was wondering because, so this is a full stack thing. So, uh, the front end part, you said it's, it's, it's based on om next or it uses om next in the backend. So what, what, what is the rationale? Because did you try reagent as well? And, and why did you pick om next? So, um, where we started with untangled was actually a library by Luke van der Hart called quiescent.
00:31:37
Speaker
Oh, yeah, yeah, yeah, that's another yes, yes. Because we were leaning towards the, well, what we want is kind of a minimal layer that gives us the pure rendering, the React kind of interface. And we want to design the kind of the middle, you know, middle back and figure out how to get the server infrastructure. You know, in my mind, I had sort of like, you know, I looked at Meteor and Elm and a bunch of different things with Meteor, you have that, that really cool. I've got a database on the server and a client and
00:32:04
Speaker
and I can subscribe to things. And the downside, of course, is it's Mongo. It's your database. And then you look at the rendering, like if you play with Meteor in detail and you look at what you have to do to hack into the rendering, it's kind of nightmarish as well. And so that level of complexity, as I saw the React slash ClosureScript approach that people were taking, it really seemed quite powerful.
00:32:31
Speaker
And when I looked at reagent, that was what was available then. My mind went blank. What are the predecessors in the successors? Redux, reagent, ratoms, rum. Quiescent. Reframe. Reframe. That's what I was trying to think of. Reframe.
00:32:58
Speaker
Those weren't there yet. Basically, it was basically Reagent and Ohm were the ones that were around when I started working on this. With Reagent, it seemed to me that you were going to tend to have developers plopping these R atoms all over your UI and you're going to end up with this really state spread everywhere sort of thing. You didn't get the time travel capabilities unless you just used one R atom at the root, which I think is what a lot of people ended up
00:33:27
Speaker
doing I don't even I don't remember what patterns they ended up suggesting you use with with reagent. It was it was kind of kind of cool, but it didn't seem to lend itself to simplicity.
00:33:42
Speaker
Oh my liked until you got to the point of what if I want to display the same data in two different ways in the same UI, right? Then you had this weird reference cursor thing that was difficult to, it wasn't horrible, but when you looked at the kind of the general structure of Omen, it seemed pretty complex to me.
00:34:05
Speaker
And so we had started working on our own kind of data persistence, data interaction layer for Qiescent when OmNEXT came out. And David Nolan was exploring some things there that were very similar to what we were exploring. And I think, frankly, he had better ideas about solving them. He'd been thinking about it a lot longer. He'd done more research on what Netflix had done and what Facebook had done. And he came up with a model that was pretty nice.
00:34:34
Speaker
And so our initial take was, let's just adopt that. Let's not write our own. Let's just use omnext. And I don't know if either of you've tried using omnext, but omnext is a little difficult to get started with. It's building blocks. David Nolan has basically said, this is building blocks. You're going to have to build a lot of the, there's a lot of pieces to plug in that don't just come with it.
00:34:58
Speaker
And it's also meant to be very flexible. You can plug in any database you want on the client and any database you want on the server. And as soon as you do that, now you have to write the merge routines for getting the data in the database and a parser for pulling data out of the database, et cetera, et cetera. It's a lot of code to write. So as we started developing an application in Ohm Next, we realized that, oh, we're going to be rewriting this same thing over and over. Let's see if we can get the company to allow us to open source.
00:35:26
Speaker
these things that we're building. Because they're probably gonna be useful to other people. So that was the birth of Untangled is was let's make, let's make OmNEXT tractable to start with. Because if you sit down at a company and it takes you a month and a half before you have a screen up, they're probably not gonna let you use it. But if you can sit down and in a couple of days be pretty productive and get all these other cool benefits,
00:35:55
Speaker
Um, well, then, you know, that's pretty attractive. So that's, that's how it gets started. And that's why we ended up choosing what we chose. Just a small question that actually with, cause there are like, let's say two competing ecosystems enclosure, at least obviously react based is one with, uh, on next and all the reframe stuff. Um, and then there's the hop on people, um,
00:36:22
Speaker
who seem to be doing a bit more of what you're talking about, which is kind of like full stack form based applications. So did you look at that at all, the whole Hoplon ecosystem? I have not looked at Hoplon.
00:36:37
Speaker
Oh, okay. Not to worry. So that's another... Right. Can only be an expert on so many things. Yeah, that's right. They did the boot build too as well. Boot ecosystem. Yeah. Now I know about boot for sure.
00:36:56
Speaker
Okay it may be worth having a look at it you know as a sort of academic interest but obviously you're far down the path now so it doesn't matter. That's sort of the point is there's so many things constantly happening I mean that's a continual worry as well is you know you've got your head in the sand so to speak down
00:37:17
Speaker
down a path that you've set yourself on, it does make sense every once in a while to pull your head up out of the sand and look around. Yeah. Well, I think the React stuff is still the dominator anyway, so I don't think you've made a bad decision.
00:37:33
Speaker
No, I'm very happy with how the ecosystem works. I think it's extremely powerful. So I'm sure there are plenty of other libraries, like I haven't written a large thing in Reframe. It's entirely possible that people are doing really great things there and ending up with large scale applications that are simple and easy to reason about and wonderful. I think that's part of the evolution of the entire craft, right? Software engineering is about us continually inventing new tools that improve on something.
00:38:03
Speaker
And so it's a lot of us monkeys banging on typewriters until the works of Shakespeare come out. I think we're maybe up to the dime novel at this point. The quality of mercy is strained at the moment. So Ray, you had a question about security for this one, right?
00:38:28
Speaker
Oh, yeah, I was just one of the things that people do. Let's say in terms of like libraries versus frameworks, one of the things that people talk about is the fact that if you use the ring ecosystem, then you've got to plug together all of the security aspects as well. So I was wondering what you've done in that sense for for full crawl. So what I've done in the sense of handling rings problems,
00:38:59
Speaker
Well, could you say it's batteries included? So did you choose something and say, okay, we integrate very well with Buddy or something like that, you know?
00:39:06
Speaker
So we do integrate well with BIDI, but that's not really a security issue. No, BIDI. It's a BIDI. You're talking about the routing thing, or BIDI or? No, BIDI is the- Yeah, BIDI's the routing thing. Yeah, BIDI. Yeah. BIDI, BIDI. It's like that's an odd thing to ask me about. So back to what- We ask a lot of odd questions, by the way. If they seem like stupid questions, it's probably just-
00:39:36
Speaker
It's probably just a super question. So back to what we were talking about a minute ago about the balance between frameworks and libraries, I'm not trying to be a framework. I'm trying to include just enough of the batteries that you're almost certainly going to write. I have no idea what you're going to need to do with security. So I'm not including batteries for things like that. Right, right. There's a component for letting you handle server requests that's easy to plug in to whatever infrastructure you want.
00:40:03
Speaker
that gives you the plumbing that's necessary to make a nice, consistent story on the UI. And whatever you put between it and, you know, in the ring stack, whether you need, you know, whether maybe you need sessions, maybe you don't, you know, that's, that's really a decision you get to make that, that I don't try to make for you in any way, shape or form. Okay. I have some suggestions about making, for example, the query,
00:40:27
Speaker
you know, handling query security in an efficient way, but in terms of the other security issues that I leave to the developer. Okay, so you have like lithium-ion batteries rather than AAA. Rechargeable. Yeah. I'm not sure I understand your analogy, but...
00:40:45
Speaker
Lithium ion batteries are smaller. Oh, OK. The size has nothing to do with the chemical composition. Anyway, they're lighter. Lithium ion are lighter. They're higher energy density. You became Belgian and the British guy. So basically, I'm probably offending both countries now.
00:41:14
Speaker
Okay. Absolutely. You're offending both of you. You're offending me. Yeah. You put you up, unknowingly you're absolutely right. I think that that's the most annoying part, right? When somebody is right. That's very irritating. Like stop being right. Shut up. Yeah. It's like talking with my wife. Anyway, go on. Yeah. So I was looking at the backend as well. So you have these, these two modules, like easy server and module based server. I mean, what exactly are those things for the backend?
00:41:42
Speaker
So easy server is the one-liner. It's like I'm in development. I'm trying to get a server up. I don't want to read the docs yet. All right, write this one line of code and you're going. There's nothing else to do. The modular server is, I want to write that full stack. I want to see what every little level of the ring stack is.
00:42:01
Speaker
But I also want the plumbing of handling the server requests from the client in this clean, unified way that I can just stick in the stack. So those are the two modes. So one is you get to shape the stack on the server however you want to shape it.
00:42:18
Speaker
Basically, you've got a Stewart CR component. I do want to make it so that you can do dependency injection and such. That's the one that I chose back years ago. You have a component you can start that acts as a middleware piece that you can then place in that
00:42:38
Speaker
that server wherever you want, or like I said, you could stick it in a servlet and just hand it requests and take its response and morph it however you want. Whatever JVM environment server-based thing you want to do is kind of up to you.
00:42:52
Speaker
And so to get started, I haven't seen any Liningen templates or anything. Or maybe am I looking at the wrong one? No, you're not. There was originally a Liningen template. What I've switched to is a clone-based template. There's actually a Fulcro template Git repository.
00:43:12
Speaker
And you clone that. The reason I moved to that had everything to do with just my time. You know, developing and maintaining a line template is it's a lot more time consuming. It takes three or four times the amount of time. And I'm just one guy maintaining a fairly large ecosystem of libraries.
00:43:30
Speaker
It's much more straightforward to me to clone the template, update the versions, make changes, make evolutions, commit it, and then you, someone who has forked from it, you can even pull upstream changes. If there's some portion of that that's applicable that you've kept, well, you can't do that with a line template. So it has its pros and cons. The downside, of course, is you can't just say line new full-grow blah.
00:43:59
Speaker
But yeah, as soon as you get into the, well, do you want to give them the option so they can say plus SQL or plus Datomic or plus this or plus that? And it's just a lot of infrastructure to maintain. So I try to have a fairly full featured working application as a template that you can just clone, strip out the parts that you don't need, and move from there. Yeah, I think it's the modern way. Yeah.
00:44:24
Speaker
There seems to be a lot of different choices in web application development and enclosure these days. I mean, of course, you can start with, I'm going to go with the bare bones set up, like my own ring and then composure, and then I'm going to pick up all the stuff myself. Or there is Luminous, the collection of libraries working together. And we have Pedestal for the back end. And then we have Reagent based stuff, Reframe and everything.
00:44:54
Speaker
So there's a bit like proliferation of frameworks. I mean, there is so.
Clojure Web Development Frameworks
00:45:00
Speaker
Right. There's both a proliferation of frameworks and libraries. There's so many choices out there. And this is always the problem, right? When you go to develop something new, what of these do I pick? Which ones do I piece together? And there's a lot to be said for just being able to pick something off the shelf that has made all of those kind of analysis and decisions. And there's something to be said for, I want to fully understand every piece and pick it myself.
00:45:22
Speaker
A lot of us do tend to lean towards the ladder there we do wanna like know every little piece and pick it part and put it together. The downside is that takes a lot longer that's not something you're gonna you're gonna do very quickly for for a system with any complexity like for example just.
00:45:39
Speaker
A lot of things people don't think about when they're piecing these together. With FOCRO template, for example, when you clone that template, you've got a production build environment, you've got a development build environment, you've got a testing environment, you've got all of the tooling set up around, how do I put it on a staging machine? How do I put it on a production machine? How do I test my components? How do I do some of these different things?
00:46:04
Speaker
all those things are already there, you're ready to start writing a production application. But I've had the experience of, all right, let's clone a Luminous thing, or do a template with Luminous, and all right, let's start trying to build this. All right, what's that for? You're kind of in the dark about every, you've got this ball of code that you don't understand.
00:46:27
Speaker
And so I'm trying to address that by one keeping it as lean as possible. I'm trying to just provide the things that you absolutely have to have to get the thing to work. Unfortunately, that there are a lot of moving parts when you start talking about production software, right? You've got you've got a development mode, you've got a testing mode, you've got
00:46:45
Speaker
all those things. But I don't want to throw at you a bunch of these other pieces like handling REST. I don't want to tell you how to do that. I don't even want you to do it. I think REST is old school. Stay away from it. Yeah, but I think what you're saying is that if a particular developer or a team kind of, if their tastes line up,
00:47:10
Speaker
pretty closely to your tests and your kind of set of decisions, then they can save themselves many weeks or months of engineering effort just by getting started here. I think that's the main win, isn't it? Is that, you know, obviously you're not going to force someone in a particular set of directions, but if they happen to come to the similar kind of choices in terms of how to do things, then here's a bunch of like pre-made things that can get you started really quickly.
00:47:41
Speaker
Right, and there's an element to that that is misleading with FOCRO. Because if you've been in a Luminous environment, the thing you end up with is a choice of a bunch of other libraries. That's what your choice is with Luminous, is you're getting a bunch of libraries. That's not what you're getting with FOCRO. With FOCRO, what you're getting is a bunch of the decisions that you're going to have to make for OmNEXT.
00:48:05
Speaker
Right, right. There's there's a difference there. So what you're choosing with fulcro is I like the model of om next, but I don't want to have to write merge, I don't want to have to develop a database, I don't want to write a parser, I don't want to, I don't want to have to figure out all those things, just to make hello world.
Asynchronous Networking in Fulcro
00:48:21
Speaker
That's a big difference. Yeah, there are full stack elements in here because omnext also defines how you should be talking to the server, but it doesn't give you much code for it. So what you're getting with full-crow is decisions about all of those plugins that omnext needs. It needs a merge behavior. You need to do things like, for example, in omnext you have optimistic updates. So as you work with the UI, the UI responds immediately. Snap, snap, snap.
00:48:50
Speaker
All of the network traffic is kind of the, that's the only place asynchronous. As far as the UI programming goes, it all looks like the synchronous thing that's just in lockstep one after another. Well, if you go in and plug in networking that actually does async networking, then you could have out of order operation. You could have one server request get delayed on one of your servers with another one that the user executed second. Well, what if the first one created the thing that the second one is updating?
00:49:15
Speaker
right, now you've got a problem. So that's the kind of stuff that FullCrow solves. It says, oh, well, by default, what you want is, even though networking is asynchronous behind the scenes, you want a networking layer that serializes the requests, unless the UI specifically says, it's okay to make this one just go wherever, I don't care, right? You want those in a sequence so that as the user's gone six steps forward,
00:49:42
Speaker
You know that that that the third one doesn't run before the first one Yeah, right. Those are the kinds of pieces that folk rose applying to the puzzle So it's not like we're throwing together You've got you know, you're gonna get bitty and you're gonna get this and you're gonna get that You know, we do make like the the HTML 5 routing support library does take its data in a bitty format but it doesn't actually care that you use bitty that's just for convenience if you happen to use bitty and
00:50:09
Speaker
It's not a hard dependency on bitty. It just so happens that you can name the handler for the route and the parameters. Okay, well, any secretary can give you that. You just have to reformat the request. So there's not a whole lot of hard dependencies being pulled in. What it is, is a complete picture of how the full stack should work from next.
00:50:29
Speaker
Okay. So can we just, uh, you've mentioned that you don't like rest. I mean, obviously OmNEXT is talking about, you know, about the GraphQL basis. So have you made any choices about GraphQL? Cause we know Walmart have done this larcenia thing. Did you, did you look into that or have you, is it all basically your own, your own kind of QL on the back, on the backend?
00:50:52
Speaker
So it was already, Omnix already defined that. It's a subset of datomic pull syntax is the query language. All right, right, right, right. Right. Which is collated on components. That was nothing that FOCRO augmented or modified in any way. The one thing that I've added is FOCRO SQL, which is essentially a library that implements datomic pull for SQL databases. All right. So that you can run the datomic pull queries and get a graph result from a database without having to manually write all those queries.
00:51:19
Speaker
So you can compose the query as a sort of pull syntax as data and then throw that to a SQL database.
00:51:29
Speaker
Exactly. So your co-located query, you compose your tree of UI with queries that makes a graph query because it's really a tree query because you've got a tree of UI.
Datomic and SQL in Fulcro
00:51:43
Speaker
And you can take those little fragments of query tree from the different parts of the UI because the different parts of the UI are unrelated. You might have a part that talks about users, a part that talks about invoices, whatever.
00:51:54
Speaker
But for any given little piece of that tree, you've got some depth to that, and that generates a tree which is also a graph that you can pick up and just use as the query to the server to fulfill that data need. So you have this fan of tree query going out, a fan of data coming back, and then that data gets normalized into your local database, and then the UI refresh goes from there.
00:52:23
Speaker
So how do you define the relationships between the different things in, cause in the database, the relation, it's a relational database. So it's, you have to set up certain tables or do you have to, is it like, like essentially the entities in Datomic or tables in SQL or how does that work?
00:52:45
Speaker
You mean in terms of folk or SQL? Yeah, I mean it's just the idea is you set up relations in a relational database and you could think of those as a graph equivalently, right? When you do left joins or whatever from table to table, you are essentially, you're getting a table, a tabular result, but you're essentially walking a graph.
00:53:06
Speaker
And so the implementation tries to do that relatively efficiently. But that's essentially what it's doing is you describe what your joins mean in terms of the keywords that you'd put on your user interface. For example, if I had user slash phone, colon user slash phone is a keyword on a user entity that says I've got a phone number, but in the database,
00:53:26
Speaker
that's really a join to a phone numbers table because I want the phone numbers denormalized, I'm sorry, normalized. Then I can write that as a join in my graph. And then in my description of for folkresql, I just say, oh, well, phone number is this relation on the database, this edge, right, this relational edge. And then from that, that's all the information I need to derive that, oh, all right, first I start with a root set of objects, the people,
00:53:54
Speaker
right? I find all their IDs. And then for every one of those, I can do a sub query, you know, a select in basically, to get the phone numbers off the table that should join to those. Okay.
00:54:06
Speaker
Nice. So I was wondering, I mean, when we were chatting before the show, you said there were people who were in the Netherlands who were using FullCrow already, right? Yeah, a VC. They do an Atlas CRM to plug in for Atlassian that does CRM stuff. They're using FullCrow. OK. So how was their experience been? I mean, what did you hear from them? And what was the best thing for them to pick up FullCrow versus other things?
00:54:36
Speaker
Sure. So, um, and I'm trying to remember, I've got several commercial users actually. Um, and I, I've got, uh, testimonials from them on the website. So yeah, I was just going through as well. Yeah. Yeah. If you just want to hear exactly what they said, you could, you could look at that. I, I, uh, you know, uh, Mitchell, uh, who works there is, is the guy that I've, I've talked to the most. Um, they, I know they basically started out on, I think it was, it was either reagent or reframe. I think it was a reframe. Um,
00:55:02
Speaker
Um, and as their application got bigger, you know, whether this was, you know, design work on their part or whatever, like I said, I don't want to criticize other frameworks, but they had complexity problems. Um, and, uh, you know, when they started experimenting with, with omnex, then they had the problems of, oh my gosh, there's all this extra stuff to write. And they, you know, you know, he, he had told me at one point that he originally just kind of avoided full grow because it sounded like, you know, this heavy framework thing. Yeah.
00:55:26
Speaker
Then as he started to look deeper, he's like, oh, well, this is just like fixing all these things up and down next that I need. It was basically a big win for them because there was just a lot less to write. We've got co-located CSS at this point, specification writing system, server-side stuff, server-side rendering, internationalization, dev card integrations. There's just a lot of stuff there that you're just going to want.
00:55:56
Speaker
Yeah. So by the way, I'd like to first, not first, but at least thank Claudio. I'm sorry. I don't know how to pronounce the name. Claudio, probably. On Slack, he was the guy who prompted me to contact you for the episode. So he had a couple of questions about what is your opinion about compile to JS languages scene, because there seems to be a lot of other languages as well.
00:56:25
Speaker
So what do you think of like Elm or TypeScript or PureScript? Because you're a functional programming and you've experimented with Scala as well. So Scala.js, for example. Right. And I still write C better than English. So I mean, you know, a lot of different languages. I think JavaScript really should be treated as the assembly language of the web. It would be nice if we got a real assembly language for the web. But for the moment, this is what we've got.
00:56:54
Speaker
I've written enough JavaScript to know that I don't want to write in JavaScript. I think compiled JavaScript languages are the right way to go. They do just save you from all sorts of headaches. The cost is you need to make sure you're choosing something that interrupts well with the JavaScript ecosystem because you would like to leverage at least some of the libraries that you get out there.
00:57:22
Speaker
I really want to love Elm. It's got some really great features. The biggest one by far is their claim that evidently is backed up. I've not done it myself. If you can get it to compile, you're not going to get a runtime exception.
00:57:41
Speaker
Right, so it's got some nice features. It's not built with a full stack kind of unified, you know, it's front end. Exactly. And that would be my comment about, and this isn't a criticism, this is just, like I said, this is like what I'm weighing with my fulcrum, to get to where I want to be. I'm not writing just a front end. And I don't think anybody else is either.
00:58:11
Speaker
All of us are out there. We're writing distributed systems. We're writing a user interface that needs to get to data that we persist on a server. There are some people who might be writing front-end-only stuff, but at the end of the day, you're going to have to figure out how you get your data from your server, how do you get it on the screen, how do you get it back to the server when you change it. And I think the Omnix model for that is a superior model when you get to that full stack story.
00:58:38
Speaker
So what are your plans for fulcro then? What is in the future or near future or far future?
00:58:45
Speaker
So the near future, I'm running through a series of beta releases right now. I'm trying to get the documentation more polished up. I think there's quite a bit of documentation. We've got a developer's guide, a reference guide. It's about half done. The developer's guide is quite complete. There's a template, there's a number of YouTube videos. There's a bunch of old YouTube untangled videos that I'm trying to make updated versions.
00:59:11
Speaker
I've gotten better at teaching the system So I think the newer videos are probably better than the older ones in some ways and I don't know probably falling short and others So I'm basically trying to polish the entire ecosystem To the point where you know people can can understand What's there yeah and and can kind of self-serve because there's there's a lot of
Educational Materials for OmNEXT
00:59:38
Speaker
There's a lot to learn. The Omnix model, that's probably the biggest weakness of Omnix period is it's so different from what people are used to doing, both in terms of the data-driven aspect, the optimistic update by default aspect, the mutations as pure abstractions that become network data.
01:00:00
Speaker
It's just one thing after another, pure rendering. People aren't used to pure rendering, even though React enables it, and Reagent and such enable it as well. In terms of the pure, I'm going to pretend like I throw you the entire tree of data, and that gives me a keyframe of animation for my UI. That's not something people are used to. Most people aren't used to, unless they've been working already in a system like this. There's so many new things to learn.
01:00:28
Speaker
You know that the client data model as a database and normalized database on the client is something a lot of people haven't done. So i'm trying to create enough education materials so that when people come to it. They're gonna be overwhelmed to some extent because there's so much new.
01:00:44
Speaker
But I'm kind of hoping that there's enough of us nerdy guys out there who love to learn. I mean, most of us are self-taught programmers who sat in our bedrooms as teens and played with computers, right? So I'm kind of hoping that the majority of the audience is willing to undergo a little bit of the pain that it takes to learn new mechanisms. But I'm trying to make that as easy as possible. That's what's next. And as I get those materials to a point that I feel comfortable that
01:01:11
Speaker
a person coming to it for the first time, at least has a good chance. I think getting there pretty close to it. I don't really want to advertise it much more widely. Like I haven't, I've intentionally not been putting announcements up in much more visible places. You know, I announced to my local users that I know I already have. I announced on Slack and my Twitter channel and that's about it. I don't go to Reddit. I don't go, right.
01:01:33
Speaker
And part of that reason is, I think with JavaScript programmers in particular, you're probably going to get one chance, right? They might come look at it, and if they can't grok it, it at least gets Hello World working relatively rapidly, you've lost.
01:01:49
Speaker
Exactly. And we have it to do MVC. That's in fact, we have a full stack to do MVC with a support viewer, right? Where you can see the time travel support viewer in, in, in, in action. Um, so that's, that's what's next is I'm trying to push it to a larger audience, but I don't want to do that until, until I feel like the story is, yeah, is a good first look.
01:02:09
Speaker
Apart from writing code, what are the things that you do? I'm assuming most of the time you'll be spending in front of the computer like every other programmer. Do you have any hobbies? I do a little bit of gardening. I do a little bit of hiking and such.
01:02:26
Speaker
And then I also have, I've got kind of a back burner project I've been working on that has to do, and this is sort of, this isn't really in front of the computers, I'm not writing code for it yet, but I'm doing a lot of research around trying to do a company around restoration agriculture or some other environmentally positive
01:02:50
Speaker
uh, business related to that. Like I said, I'm still doing a lot of, of research around what the right approach is. I don't want to just go half cocked and do a bunch of work on something that doesn't actually help, but that's really where I'd like to be spending most of my time and most of my energy is trying to get a company that, I don't know, either helps, maybe it helps individuals do permaculture or maybe it helps farmers revamp their farms into, you know, more sustainable systems, something along those lines. That's, that's what I'd like to be doing.
01:03:18
Speaker
Wow.
Restoration Agriculture Research
01:03:18
Speaker
So from, I don't know. Sounds excellent, yeah. Culturing code to culturing environment. Yeah. Yeah. And FOCRO is going to be a primary tool in that. I think it's really well-suited for rapidly building first-class applications at this point. And I know it really well, obviously. So that's part of the reason why I'm continuing to maintain that tool set, is I want to use it.
01:03:45
Speaker
I think also you have a model for supporting you as well, doing full crows. Well, don't you, Tony, you have a page there where people can help to support the project financially and in terms of effort as well.
01:04:01
Speaker
Yeah, I've got a Patreon thing. I've got a one-time PayPal thing. You know, I get a whole lot of contributions off of that. I do get some. It's certainly not enough to support, to support myself for the project at the moment, but you know, I'm also trying to, I haven't, I haven't actually coalesced this yet, but I will probably put together a consulting company around it to offer, you know, actual paid consultancy time.
01:04:27
Speaker
Yeah, that's pretty nice. Well, best to look with it. I mean, I think it's really, like you say, you're serving people who want to experiment with this omNEXT approach a hell of a lot of time. And I think that it's very worthwhile. I mean, it's been a great discussion, to be honest. I think I just noticed that we've went over an hour. So I think we should start to
01:04:51
Speaker
wind things up a little bit now. But it's really interesting and also there's still a few things in that page where the CSS stuff and some of the bits and pieces that I think we could talk for even longer on. But anything else you want to talk about just before we wrap up the show for the night?
01:05:12
Speaker
No, I think what you just mentioned is the only thing kind of weighing on my mind. I feel like there are some really cool things in the ecosystem, like the co-located CSS, the server-side rendering, the internationalization, all those things that people can check out the website and see what's there. But these are exciting things that are happening. They're happening in a lot of frameworks. People in the React ecosystem have been experimenting for quite a while with
01:05:40
Speaker
you know, can we put the CSS for the component with the component? Because as soon as you do that, you start to evaporate a lot of the tool chain. You know, you no longer need the web pack plus the this plus the post CSS plus the that plus the, right? Some of these things have just nightmarish build systems. And when you get to something where it's all enclosure enclosure script and there's a closure script compile and there's a closure compile, that's it. There's your build system.
01:06:04
Speaker
And it seems like HTML5 is going that way as well. So you're kind of going with the grain a little bit as well.
01:06:12
Speaker
Yeah, I mean, it's interesting. I think it's kind of cool that the ClosureScript community has generated enough innovation that it's feeding back to JavaScript plant, right? A lot of these things that exist in, Redux, Redux credits ClosureScript for inventing a lot of the things that it's doing. And in fact, if you go and look at it, it looks very similar to a lot of what we're doing here. A mutable JS and stuff like this.
01:06:38
Speaker
Exactly. It's not a unidirectional thing. We're kind of feeding off each other. And I think, to be honest, we've got the better programming language. Unfortunately, we don't have the crowd. We don't have the numbers, but it's so much easier to work in Clojure and ClojureScript than it is in JavaScript land.
01:07:02
Speaker
I honestly think that we do have the numbers, but I think JavaScript has numbers of developers that are kind of counted as JavaScript developers, but really aren't JavaScript developers. This might be controversial, but I reckon that 90% of JavaScript developers are not developers. They happen to write JavaScript. No, I'm not even joking about that. No, it's not joking. Just like people who are used to doing CSS and HTML who want to make something anime. Yeah, they claim they're JavaScript developers, but all they know how to do is muck with the DOM a little bit.
01:07:32
Speaker
And there's nothing wrong with that. It's just, it's just to me, it's like, people say things like, Oh, when we can't get closure developers, we can get JavaScript developers. Well, you know, I've been on either side of that trying to recruit decent JavaScript developers. And they are very few and far between actually. You know, if you want people to understand JavaScript, what you want is a good developer level. Exactly. Yeah. Yeah. You don't care what language they write. You want a good developer. Yeah. And as soon as you've got a good developer,
01:07:58
Speaker
We've got a lot of them in Clojure, for sure. Yeah. As soon as you've got a good developer, handing them a good tool just makes them better. And we're trying to get them out of the woods.
01:08:09
Speaker
Yeah. No, we're trying to get him in the woods. Yeah. In the back woods. Whichever way you want to look at it. Yeah. I mean, even Ray lives in, I don't know, some god forsaken. Of course, Belgium is already, you know, kind of. God forsaken. Yeah. I mean, nobody cares about Belgium, but it's Belgium of Belgium, Europe. But he lives in a very remote Belgian place. So this is kind of a trend now, I think.
01:08:34
Speaker
Anyway, I also work remote as well. Yeah, I work for an American company in Belgium, in the middle of nowhere. So it's very good. I think I'll be soon, quote unquote jobless. So I'll be changing my job as well. We'll see what what is going to happen next. Good times. Or maybe we'll we'll ask for money for the two people who listen to closure podcast and then hey, can you send us money so we can buy cookies or
01:09:00
Speaker
Great, a beer. I think we'll start a Patreon thing. Okay, let's stop now. Yes. Before the listeners kill themselves. One final question. Are you a vegetarian?
01:09:21
Speaker
Yes, I am. Yes. Oh, Tony. Yeah, sorry. Yeah. You're asking me. Yes. I'm not. I'm not. Why? No, because our tagline is the best vegetarian closure podcast on this side of the pond run by a Belgian and an Indian guy. I mean, we're trying to make it so specific that we have our own niche that nobody can beat. So we both are vegetarians. So we usually ask this question. The guests will come in. And then if they say they're vegetarian, we're like, yeah. But if they say no, then, OK, fine. Moving on. So that's pretty much it.
01:09:51
Speaker
Fine, moving on. You probably do eat vegetables, though, at some point. Yeah. I eat a lot of vegetables, actually. I grow vegetables. That's perfect. We'll count that, yeah. Yes. All right. OK, so let's conclude. Tony. You haven't eaten any meat during this podcast, have you?
01:10:10
Speaker
No. Perfect. That's all. That works.
Closing and Future Support Plans
01:10:13
Speaker
That works, yes. So it is still a vegetarian podcast during the recording of the show. But Tony, thanks a lot for joining us. I know I just pinged you two days ago and you're very kind to say yes to joining this one.
01:10:29
Speaker
And it's really fun to talk to you. And I hope more and more people take a look at full crawl. Obviously, you're not trying to take over the world yet with full crawl. Yet. And ready to take over the world. But it looks really interesting. And I think I'll give it a shot as well. I mean, I have this habit of trying different things. So of course, making home next easy is not an easy task. But I'm sure you did a really good job there.
01:11:00
Speaker
I'm trying. Yeah. And that's it from us, I think. Ray, any conclusive remarks, or what do you call it again? Concluding. Concluding, yeah. Well, I like you. I agree. I mean, I think Tony has done a good job. Honestly, I mean, just as a little kind of, this is not really a puff piece, but it's so good to speak to Closure Developers, actually. Everyone that we've talked to on the show has always been like,
01:11:27
Speaker
super nice guys and super funny and it's no exception with you Tony so thanks very much. It's been a real pleasure and you know so easy to speak with. You make awesome software so you're best of luck with that but also just keep on rocking on it's really good.
01:11:44
Speaker
Yeah. Appreciate it. Keep testing. Keep testing. Keep testing. Just keep swimming. Just keep testing. Just keep testing. Breathing. Keep testing.
01:11:59
Speaker
Okay, that's it for the episode number 25 from us and I think we're gonna roll on the credits. The music that you hear is from Pizzeri on Soundcloud and I mean all the noise that we're making that is being fixed by Wouter who is a fellow Belgian from a fellow Belgian friend of race.
01:12:21
Speaker
And that's it from us for this episode. We soon are trying to get more and more episodes back on track after our lazy summer holiday. So we hope to talk to you soon via the podcast. Okay. Bye bye. Bye. Cheers. Thanks Tony. You're welcome. Thank you.
01:13:08
Speaker
you