>> .. and vanilla JS with some jQuery

If I could I'd buy you a beer and cheers you for relieving my JS anxiety a bit. I love jQuery, and I'm tired of feeling ashamed of it, damnit!

I don't think that quote justifies your love of jQuery. The keywords are "some" and "sprinkled in". In my experience jQuery always trends towards a huge mess the more it is used.

Sure, it could be used but it really shouldn't.

Interacting with the DOM in a procedural way, and storing state on the DOM is always going to be harder to manage than using a reactive pattern when you trend towards more complexity.

It's s CRUD app! You don't need everything to be a SPA with a heavy weight framework!

You can use something like Preact for little widgets here and there. It's not one or the other!

Really depends on what level of complexity we're talking about. Simple form with a couple of fields or something like gmail?

jQuery is no better ( these days ) than Vanilla JS, which you will love as well especially if you choose to use ES6 syntax.

`document.querySelectorAll` is amazing. It's a unification of the css syntax and javascript. No more filtering it your self, and your standard javascript stuff still works. It's wonderful.

All of this except Django, overkill for many small and mid sized projects. I use a lightweight Bottle/uwsgi api to get json into _underscore templates. Up and running in ten mins :)

I have a CloudFormation template that sets it all up for me in about 5 minutes (gets a little tiresome to do the same thing over and over again). Booting an EC2 instance and installing the necessary packages takes the bulk of that time. I spend about 30 seconds setting the project name and domain name, make some coffee, and by the time I'm done everything is up and running. The template sets up the GitHub repository, provisions the entire stack, and sets up auto-deployment, amongst a lot of other things.

Shameless plug: I'm currently looking for beta testers to use this provisioning tool, so if you're interested in trying it out for your stack, send me a note (email in profile).

Another commenter mentioned that EC2 was relatively expensive. Technically, that's true, but the sheer power of being able to automate everything in the infrastructure is pretty awesome.

I always had a question I wanted to ask an experienced Django dev. After trying this framework for a couple of hobby projects (I'm a client game developer primarily and never worked on "serious" web project), I kinda got the impression that it's architecture is created for two main user roles: admins who create most of the content and have marvelous admin forms in front of them to input all the data, and users, who mostly consume the content and only occasionally input some data. When I tried to create complex input forms with a lot of complicated, relational data that users would be able to input and modify, it felt so much harder than exposing the data models in the admin panel — it really felt that this wasn't the use case this framework was designed for.

Did I get the right impression, or may be I just didn't learn to use Django correctly?

From the Django tutorial:

> Generating admin sites for your staff or clients to add, change, and delete content is tedious work that doesn’t require much creativity. For that reason, Django entirely automates creation of admin interfaces for models.

> Django was written in a newsroom environment, with a very clear separation between “content publishers” and the “public” site. Site managers use the system to add news stories, events, sports scores, etc., and that content is displayed on the public site. Django solves the problem of creating a unified interface for site administrators to edit content.

> The admin isn’t intended to be used by site visitors. It’s for site managers.

https://docs.djangoproject.com/en/2.0/intro/tutorial02/

It sounds like the "out-of-the-box" expectations created by the admin app are the problem. I mean, hey, Django makes exposing data models in the admin interface trivial! You can certainly create more complicated forms for relational data, but in those cases you can't rely on Django's default functionality to do as much for you. I've written or worked on more than a few serious apps including those with more complex user facing data and Django's worked beautifully. Happy to answer any specific questions you might have.

> When I tried to create complex input forms with a lot of complicated, relational data that users would be able to input and modify, it felt so much harder than exposing the data models in the admin panel

Hmm, really interesting. I can't say I've ever run into this, and maybe it's just that Django is so good at the admin stuff, it makes everything else look hard in comparison.

Most forms I have start off as subclasses as ModelForm. If I need to combine two forms on one page, I just give the form a prefix and populate them both within the same <form> tag. I'm not sure if this is the sort of more "complicated" use case you were thinking of, but y4mi's suggestion of breaking forms into sections with wizards is another great way to go about it.

i'm not an experienced django dev but i asked the same question some time ago. The answer i got back then was essentially 'one form per object, if you want to create two interdependent objects, just chain the forms into a "wizard"'

it kinda makes sense, considering how easy it is to create form views

Oh hey, you already made my post for me!

I do prefer React for when a frontend framework is appropriate, but I also think that's not always the case.

I think there's a lot to be said for familiarity. Rails instead of Django? Sure, if you and the folks you're working with know it better.

Looks like exactly what I would suggest, although I’d argue EC2 might be slightly overkill. You’d get more for your money with Linode/DigitalOcean/OVH or even Hetzner’s new cloud offering. Will help save some pennies early on.

In-memory cache: Redis.

Do you typically run Redis on the same host as your web server? Treating it as "in-memory" can have interesting side effects as you centralize it and introduce network delays.

> Do you typically run Redis on the same host as your web server?

Yes, at least initially.

> Treating it as "in-memory" can have interesting side effects as you centralize it and introduce network delays.

I'd love to hear more about this!

Sorry, totally missed this because there is no notification system here...

Let's say you have a large, tight loop in which Redis is used. If it's local, great, no problem. Now when it's centralized, you introduced a network delay you hadn't planned for. This "gotcha" comes up when you mess around with cache locality and didn't account for the delay changes in all areas of code.

Is there any way you could create (or link) a small, open source app that uses these technologies.

Something good for beginners? I realize I'm asking for a lot but I might as well ask.

What parts of jquery do you use today? I ask because my impression is that it's simply not needed anymore with the better DOM interface methods like querySelector

A lot of it has been simplified thanks to API improvements, but simple element manipulation, event handling, etc. is just a little bit easier with it than without. The special ":hidden" selector is just one example I grabbed from opening a recent JS file (e.g., `$(selector).is(":hidden")`).

I picked all of these things for my startup 6 months ago except I'm using Vuetify with Vue. just like it doesn't make sense to rebuild everything that Django provides it doesn't make sense to rebuild all the UI components Vuetify provides.

what does this mean in English?