Analyze using Vue vs. Django-Components

[mlissner]

Figure out:

• How do we do basic components using these libraries and what are the pros/cons
• What's the basic approach to getting them into our dev env?
• How would we deploy them?
• Etc.

Optionally: Can add a simple component to /components/ for each, if that makes sense.

[elisa-a-v]

Here's a very easy way to gradually start integrating Vue into our codebase; the only downside is you can't use Single File Components (SFC) when you include Vue via CDN cause they require a build step, and SFCs are extremely useful and one of Vue's key features, so I'd definitely look for an alternative that supports them.

One option would be to create a SPA from scratch. I think the hardest part would be creating the API, because if we use Vue the frontend would be fairly easy to develop, but idk most of the logic is already there and I think DRF makes it really easy too so it might not be that bad.

I love Quasar for this, it's a very underrated meta framework that works on top of Vue3 and provides several customizable components out of the box, besides taking care of many things for you. I believe it is HIGHLY underrated, and it provides several modes (SPA being one of them) that we could use which would even make it possible to eventually launch native mobile apps with the same codebase.

One of Quasar's modes is SSR, which I haven't used but from what I've seen that sounds like a viable option for this. I had a chat with ChatGPT about it if you want to read it, bottom line is:

Rebuilding your frontend using Quasar's SSR mode can offer significant benefits, especially regarding SEO and initial load performance. However, it comes with increased complexity and potential costs. If your project's success heavily relies on search engine visibility and delivering content quickly to users, SSR is a strong candidate.

On the other hand, if you prefer a simpler development process, lower server costs, and your application doesn't depend heavily on SEO (e.g., an internal tool or a user-authenticated app), an SPA might be more appropriate.

There are other alternatives I haven't used for SSR using Vue3, like Nuxt 3, so that's something we might want to consider too.

[mlissner]

Thanks Elisa, this is really helpful to get the conversation going. We're going to be figuring out our goals as we go a bit, unfortunately, but I'll highlight a few that I think help move this conversation forward:

1. Performance - We want the new site to be as fast as the current one, or faster. This means the less building of HTML and processing of Javascript (client or server side) that we do, the better. Right now, Django templates are what we use. If we make this too complex, we'll regret it.

2. CDN - The new site should be ready to go behind a CDN at least for people that aren't logged in.

3. SEO - We need to do well with SEO to achieve our goals. This means SPA's are probably out. I've heard that they can have good SEO, but it seems difficult.

4. Simplicity - I sort of like that CL is so simple, and I've heard from other folks that they like that about it too. It's ugly now, and we'll make it pretty, but we don't want to make it really complex in the process.

5. Dev experience - I think hot-reload is a must for this new project. I'm so tired of hitting refresh all the time! I'm sure there are other DX enhancements we can think of too.

6. Get it done - CL is really big with a LOT of features. The less change we make, the better, so I think every change we make needs to be justified.

7. Prefer Python? - Most of our devs are stronger in Python, so the more of that we use, the better? But maybe Vue is so simple, it's OK? I'm not sure. I just don't want to need expertise like we did with React.

8. Tailwind ease - Using Tailwind on free.law and bots.law is a dream. I hope we can have that for CL too. :)

---

I think for all of these reasons a SPA is probably out. The one reason I can think of to do an SPA would be to allow oral argument recordings to continue playing as the user navigates the site, but that's it, in my mind. I think most of our pages represent documents (except search, which should be more dynamic), and so they are well-served with SSR'ed HTML.

Single File Components look great.

I don't have time to look at Quasar atm, but my 30s glance makes me think it's going to be a fair bit to learn. I think we're also designing towards the tailwind component library too, not the Material Design library?

---

Thank you again for the thoughts. I'm really looking forward to seeing where we land with this.

[ashkonf]

PR for test components: #4800

[mlissner]

I've been mulling this for days, I studied django-components a bunch over the past few days, and I spent some time talking to @elisa-a-v today. I think my post above was about right, but I'll flesh it out a bit more here. I welcome other perspectives — this is a big proposal with a lot to think about.

I have growing confidence that when building front end functionality we should use the first of the following that will get the job done:

1. Tailwind for CSS
2. Tailwind UI as a component library.
3. Basic django templates enhanced with django-components for most things.
4. HTMX when we need basic dynamic features
5. Vue when we need complex features

Let me explain...

• I want to keep CL as simple and lean as possible. This means no SPA, and it means server-side rendering done by Python. This eliminates SSR by tools like Quasar (which would use Node for rendering), and it eliminates doing SSR using Vue itself. A few reasons for this:

  • SSR is better for accessibility. Hard to beat plain old HTML.
  • I don't want to deal with Python on JS dependencies and all the breakage that JS deps constantly cause. Python is bad enough.
  • Our devs aren't as good at JS, and it's hard to find people that are good at both JS and Python.
  • If we switch to using Node for rendering, we'd also need to keep Python around to serve as the API to Node, so we'd wind up with a more complicated stack (Django for API, Node/Quasar for front end).
  • Learning something like Quasar, keeping it secure, doing updates, and all that is a big thing, and we already have a lot of big complicated things in our brains.

• Vue seems simpler and better than React. We should slowly move to it for places where it makes sense to do so. Currently, we use React for tags and financial disclosures. Most of these two features could be replaced with basic django templates enhanced with HTMX. Some bits of these features might need Vue and should, eventually, get re-done with it.

• Hot reloading is a must. It's just lovely. I think django-components + tailwind will provide this.

• SEO is important to our mission. This means no SPAs and a preference for SSR whenever possible.

• Implementing a CDN this year is a must. Lots of notes about this over in https://github.com/freelawproject/infrastructure/issues/218. This again means simple pages are better.

• Using Vue would make the tailwind UI library easier to use, since it includes templates for Vue or React but most of our components don't need JS, so I think this isn't a huge bummer (it's a small one though).

• I did an analysis of the django-components repo:

  • Lots of activity, some of it quite formal.
  • Good vibes, but under-resourced.
  • I think the basic features are there.
  • Performance was a worry, but I think it's OK. I promised we'd evaluate this and provide some info for them.
  • The only risk I see is that it's not yet 1.0, so we'd be an early adopter and we might need to upgrade things down the road. Still, upgrading this feels better than the JS upgrade churn.

I'm going to go invite others to chime in on this via our Slack. If nobody convinces me otherwise within a day or two, let's proceed with the above approach.

[mlissner]

Closing. We will proceed with the architecture outlined above. Thanks all.