Clojurians Log v2

I'm not sure what that would look like

I suppose I could just return the entire cache-bundle and go from there

any thoughts on this when you get a chance @lee?

a UI in cljs would be nice for the community but it's hard to pass up all the mature, accessible UI libraries out there these days

examples: https://mantine.dev/

https://nextui.org/

https://tailwindui.com/

I'm not nearly as good a UI/UX person as all the collective hours put into these UI libraries, it's hard to just say no to all of this

yep, the cache-bundle is basically all you would need to render the UI using any given frontend

@lee https://github.com/cljdoc/cljdoc/pull/756

Counterpoint, the site loads instantly for me right now when I’m out of data in my phone. The lack of any fancy javascript framework makes browsing fast and natural. I’d hate to lose that

we do use a fancy javascript framework, but for only a few things

and server-side rendering has improved that story significantly. it's certainly lighter than using cljs

but it's hard to argue with the lighthouse report on the current site: 98

(98 on desktop, 70 on mobile)

yeah, I'm looking at a jira clone built using remix.run right now and it's scoring a 97 on desktop and 65 on mobile...

Theoretically, if there was an API, is that something that could be used by IDEs or desktop apps?

Heya, sounds interesting!

Be cool to get the dewey data in there too, but maybe that would just be to think about not do yet.

This would allow front-end-smart folks to iterate quickly on different uis, ya?

@smith.adriane I don't see why not.

@corasaurus-hex not sure what API you had in mind, but if we aren't doing anything dynamic, I guess we could just generate static edn.

that's true!

I mean, we could content negotiate

Is a goal a major redo of cljdoc, or are you just wanting to iterate faster on front end experiments, or maybe both?

Not sure how practical static data is, but worth a think. We probably still want to support search and that would likely still be a dynamic server-side service, ya?

If we are thinking of a major cljdoc redo, we could also brainstorm on any new features we'd like.

I just wanted to experiment with it and maybe provide an api for others to do the same

For example, I miss https://twitter.com/crossclojure?lang=en, but I don't know if its features are a fit for cljdoc.

so a major redo of the ui in my case, just to see what I can do with a clean slate and some modern ui frameworks

and for others, maybe ide stuff like @smith.adriane said

I guess what I mean to say is I wanted to experiment with a new ui and it kind of prompted me to think about unlocking the data we have so others can experiment how they want as well

I wouldn't think we'd get a ton of API traffic, but if we do, we'd have to figure out to deal with that.

for sure

there are options. given how static things are you could throw it on disk, on s3, in a cache, a cdn, etc

likely easiest to try it and if we get too much traffic try sticking it on an object store that's cheap enough like s3

ya, sounds fine to me.

I guess we should ask our @martinklepsch what he thinks of all this. Cljdoc is his baby.

for sure

Nice to have your energy back here @corasaurus-hex!

Oh and @nbtheduke, yeah good point.

On Tailwind... I'm guessing when Tachyons was chosen for cljdoc, they were both equal in popularity. That changed a bit, ya?

oh definitely

I'm not a huge fan of utility css stuff and probably won't try another one of those

I'm personally fine with that. It might just be the way we used Tachyons but I find the repetition a bit much. Maybe if we created and reused more components (fns, really). Dunno. Again @martinklepsch might have opinions on utility css! simple_smile

Luckily https://github.com/cljdoc/cljdoc/issues/571 back then!

yes, the repetition gets to me, too

Hey! An api sounds like a great idea, definitely sounds like a good idea to allow people to build new or alternative UIs

@corasaurus-hex I had been working on understanding our current cljdoc endpoints. And it is a bit confusing. Some endpoints are clearly API, others serve HTML and less obviously also act as API. Error returns are almost always unstructured (usually a single string). 500 returns do not respect content negotiation. These things are natural for a project that has grown organically over the years. But moving forward, we could probably define a clearer strategy for API endpoints. For an API that supports single-page apps, not too much to think about, maybe. Just maybe how we return errors? And if you are planning a cljdoc redo, probably best for me to pause on any cleanup (which is fine, I've been distracted by other work anyways).

I wouldn't pause on cleanup, anything I do will be a longer-term effort and I'd probably want it to live alongside the current version for a while

but only put in work you feel like putting in

I didn't feel like putting in the work to revamp some of the parts of the UI, kind of wanted to start fresh and see what I could throw together, maybe spend some time in figma

maybe it goes somewhere, maybe it doesn't, but exposing the cache-bundle seems like something useful in a broader sense, the information we have there is super valuable to the community

I feel like the name needs some work. doc-bundle? analysis-bundle?

"cache" is really an implementation detail and not a property of the data itself

yeah, that name is definitely not great 😄

both analysis and doc bundle seem like appropriate names

we use "docsets" for the search api you built @corasaurus-hex, would that fit here?

I think I used searchset for that?

hmm maybe docset, too?

docset is probably fine

figuring out the cache bundle types is hard