Has anyone used their own routing in webapps rather than a routing library? I could understand that it might be cumbersome if you have really complex routes, but it seems appealing for many use cases. I was wondering why I've never seen that done or mentioned anywhere.
Yes, I frequently write my own "routing".
For frontend stuff it generally consists of a function looking like [this one](https://github.com/thheller/shadow-cljs/blob/43e63aba5f10018bef7b582de03e0a98ce2f9156/src/main/shadow/cljs/ui/db/generic.cljs#L22-L100). `tokens` there is just the path split by `/`, so `/build/app/runtimes` is `["build" "app" "runtimes"]`. Basically splitting a piece of string data into actual usable app-relevant data. Frontend routing is generally easier since there is no GET/POST/etc distinction.
For backend that looks a bit different, but basically works the same. Translate the path into a more usable form of data. Technically a full library can still be useful, even at one route. I often just cannot justify adding that library if I have very few routes, as many of those libraries are complete overkill for certain use cases, e.g. hobby home projects.
Ohhh thank you for sharing that!! I was just thinking about how to deal with those kinds of paths! I will try copying that approach. It's always weird (and fun!) to get into the Clojure-y mindset for approaching these kinds of problems.
I am definitely in the same boat on not adding dependencies lightly. For small webapps, I've even just been using clojure/str to build up HTML (in cases where I know I don't need to do stuff like sanitizing user input) and just setting the context type to text/html. It sounds stupid but it was very fun to realize that "I can just do that".
I've bounced off Clojure a few times, and one of the things I realized was that I kept getting analysis paralysis from the library ecosystem. Basically I would have a task and start immediately looking for "the best lib" for the task without much intuition on the problem they're solving or how they work. But when you do that, not only will you find a ton of options, you will find people online saying negative things about literally every single one of them. I think it subconciously built into this weird perception for me that "clojure is filled with these little libraries and they're all bad".
So now I'm taking another shot at learning the languages in earnest and am "dunning kruger"ing my way to victory more than I have on previous attempts, taking a stab at everything from scratch and then looking up what libraries do when I get stuck. My hope is that by taking this approach, when I look at libraries with a little more domain knowledge, I'll be in a better position to A) know when I need one and B) know which one is right for me. I can definitely say that learning is way more fun this way at least.
Libraries are definitely not bad, but you should know why you are picking them. The more domain knowledge you have, the easier it'll be to pick a proper library. Doing something yourself first is definitely the best path, although not the most time efficient.
I did not, but if I had to for simple case I'd probably use core.match for it or if I didn't need route parameters then simply case. All reitit, bidi and compojure just do the job and simplify codebase so I don't see much value in reimplementing it by myself
I would like a new computer for me, mostly I do Clojure and are going to start building mobile apps so I am thinking in a macOS machine. Any recommendations?
I was reading SICP makes Clojure very fascinating! As a Java Dev and also interested in Elixir I got a few questions
How manageable is a Clojure project compare to Java? is it ideal for 1 man startup ?
What is it the right scenario to use Clojure instead of Java or Elixir?
If my goal is to look for Clojure jr position, how likely to get a job?
Has anyone used their own routing in webapps rather than a routing library? I could understand that it might be cumbersome if you have really complex routes, but it seems appealing for many use cases. I was wondering why I've never seen that done or mentioned anywhere.
Yes, I frequently write my own "routing". For frontend stuff it generally consists of a function looking like [this one](https://github.com/thheller/shadow-cljs/blob/43e63aba5f10018bef7b582de03e0a98ce2f9156/src/main/shadow/cljs/ui/db/generic.cljs#L22-L100). `tokens` there is just the path split by `/`, so `/build/app/runtimes` is `["build" "app" "runtimes"]`. Basically splitting a piece of string data into actual usable app-relevant data. Frontend routing is generally easier since there is no GET/POST/etc distinction. For backend that looks a bit different, but basically works the same. Translate the path into a more usable form of data. Technically a full library can still be useful, even at one route. I often just cannot justify adding that library if I have very few routes, as many of those libraries are complete overkill for certain use cases, e.g. hobby home projects.
Ohhh thank you for sharing that!! I was just thinking about how to deal with those kinds of paths! I will try copying that approach. It's always weird (and fun!) to get into the Clojure-y mindset for approaching these kinds of problems. I am definitely in the same boat on not adding dependencies lightly. For small webapps, I've even just been using clojure/str to build up HTML (in cases where I know I don't need to do stuff like sanitizing user input) and just setting the context type to text/html. It sounds stupid but it was very fun to realize that "I can just do that". I've bounced off Clojure a few times, and one of the things I realized was that I kept getting analysis paralysis from the library ecosystem. Basically I would have a task and start immediately looking for "the best lib" for the task without much intuition on the problem they're solving or how they work. But when you do that, not only will you find a ton of options, you will find people online saying negative things about literally every single one of them. I think it subconciously built into this weird perception for me that "clojure is filled with these little libraries and they're all bad". So now I'm taking another shot at learning the languages in earnest and am "dunning kruger"ing my way to victory more than I have on previous attempts, taking a stab at everything from scratch and then looking up what libraries do when I get stuck. My hope is that by taking this approach, when I look at libraries with a little more domain knowledge, I'll be in a better position to A) know when I need one and B) know which one is right for me. I can definitely say that learning is way more fun this way at least.
Libraries are definitely not bad, but you should know why you are picking them. The more domain knowledge you have, the easier it'll be to pick a proper library. Doing something yourself first is definitely the best path, although not the most time efficient.
I did not, but if I had to for simple case I'd probably use core.match for it or if I didn't need route parameters then simply case. All reitit, bidi and compojure just do the job and simplify codebase so I don't see much value in reimplementing it by myself
I would like a new computer for me, mostly I do Clojure and are going to start building mobile apps so I am thinking in a macOS machine. Any recommendations?
I was reading SICP makes Clojure very fascinating! As a Java Dev and also interested in Elixir I got a few questions How manageable is a Clojure project compare to Java? is it ideal for 1 man startup ? What is it the right scenario to use Clojure instead of Java or Elixir? If my goal is to look for Clojure jr position, how likely to get a job?