This isn't quite fair. The problem is that JavaScript expertise is still volatile. It is a use it or lose it skill. It quickly becomes alien unless you stay on the threadmill and keep up with the developments, patterns and tooling. I admit syntax is not actually difficult to relearn but patterns take time to acquire.

I've been programming for over 20 years and the languages and frameworks I favour have a sticky quality. These are the ones I can put away for years, return, get back into it and pick up new features in a few hours at most. The cognitive load of getting back into them are low.

I picked up django around 2011 and moved on to other things including JavaScript at the time. When I needed to build a Django project in 2016, there were some improvements and new features but the syntax, tooling and patterns were the same. It was possible to just jump right back in after a quick skim of the docs. It is possible to develop mastery of this stack, set it down for a few years and return to it with familiarity and continue on that journey.

The JavaScript ecosystem in that period however has pulled off a massive amount of transformation. I learned the basics of jQuery, yui, knockout, emberjs, backbone, coffeescript, ecmascript X, knockout, baconjs, rxjs, react with classes, react with hooks, redux, typescript, nextjs, react server components, react native, graphql, assemblyscript and on and on. It has been impossible for me to develop any deep mastery of anything in the JavaScript space. This does not even include the insane tooling with vague overlapping responsibilities. The closest I have found to reasonable stability in this area has been clojurescript with reagent.

I am constantly stuck in tutorial mode when I need to dive back into the frontend. I recently upgraded a 4 year old Django codebase in 2 hours. I am ripping out all of the react code because it is just not worth the effort any more. The tooling, dependencies and patterns are now outdated. HTMX has that simplicity and elegance that will keep the cognitive load manageable while I focus on the real problems.

> This isn't quite fair. The problem is that JavaScript expertise is still volatile. It is a use it or lose it skill.

This is true of most of almost all living technologies.

> When I needed to build a Django project in 2016, there were some improvements and new features but the syntax, tooling and patterns were the same.

Python and Django both underwent major transformations between 2011 and 2016. That was the 2->3 transition, class based views, channels, packaging was heating up, async came, and there were several syntax and libraries improvements. Were you more comfortable with Python at the time, is that why it was easier to get back into it?

Most Angular 2+ apps written in 2014 have essentially the same architecture as an Angular app written in 2024 (Directives, Components, Services, Pipes, etc, etc).

What you're describing reads like putting down any living technology and picking it back up again a few years later.

> This is true of most of almost all living technogies.

It's not really true for any other programming language. If I'm an expert in Java 8, I can build and ship a product using it. I don't need to be up-to-date in my knowledge of Java 17. Same holds for almost every language.

Javascript is an exception because you don't get to decide which version to deploy, so you have to constantly be keeping up with it.

It’s the opposite problem with JavaScript. JavaScript almost always going to be backwards compatible. But, you’re right, because you can’t control the environment you’re going to be perpetually using “new” features that are 2-5 years old.

For example, I can still run my projects from 2004 but I'll have to wait until 2028 to widely deploy my bleeding edge projects from 2024.

Not just Django, the .NET and some other traditional server side communities have done their best to avoid JavaScript.

Despite the churn, there are some great core technologies for the front end. Native browser functionality is much better than it used to be.

Oh yeah, .NET [0] too. Layers upon layers of abstractions in C# just to be able to accomplish a fraction of what you could easily do in JavaScript.

[0]: I was a C# developer for five years, but, with Mono, because I wanted to make sure I wouldn’t be employable.

I don't feel that's really true.

Try using the native date control or the number control.

You also still can't easily style the select component. In React MUI, for example, they completely give up on it and use styled divs instead.

But what would I know, I'm one of those incompetent .Net developers.

> But what would I know, I'm one of those incompetent .Net developers.

C# and the .NET Framework were some of my favorite tools. I thought LINQ was neat.

> You also still can't easily style the select component.

Forgoing JavaScript and CSS for a .NET abstraction wouldn't make the situation any better. You'd just get whatever the select component's library gave you until the browsers standardize a way to do it.

but that's a browser problem, not a frontend framework issue. you'd have the same limitation without a frontend framework, wouldn't you?

Those are great examples, there's still work to be done.

It's very true for Ruby on Rails. Rails' (not so) benevolent dictator for life, DHH, has been inventing and pulling in abstractions on abstractions so that Rails Devs don't need to touch JavaScript.

Hmm. I'm not primarily a web developer but when I do do web stuff that needs a database, Django is my go to.

I also try to avoid JS as much as possible. I honestly feel like it's a good design approach/directive - use HTML and CSS as much as possible, and JS only when needed and sparingly.

I'm not against it at all, I use it to expand menus, or to change a hidden field to visible based on which option in a dropdown is selected, maybe even some AJAX stuff.

But mostly if I can avoid it I do. My sites still look modern, but they are fast, and often the entire front page can load in 0.3 seconds or similar (according to various online speed tests).

I haven't ever needed TypeScript, Sass or whatever RxJS is.

The trouble is, you learn javascript and discover it’s a better back end for website building.

I say this as a python dev with experience of bottle flask falcon Django Starlette abs FastAPI.

I’ve written reams of JS over the years–web frontends with a dozen frameworks, Node backends, mobile apps, you name it. It’d probably make sense for me to use it more often on the backend, but the trouble I run into when committing to it for a new project is that… I just don’t like it.

I know how to avoid all of the “wat” stuff that people typically trot out to criticize the language. I can write a quality piece of production software with it. At the end of the day, though, I still just have this feeling like I’m cooking in someone else’s odd and disorganized kitchen with not quite all of the right tools and ingredients.

Ehhh yes and no.

I still run into a lack of "it just works" and stays that way in JS land. It is likely I have not found the right combination of tools or the right framework but nothing has been as reliable as django and the builtin contribs (auth, admin, sessions).

What would you recommend I look at in JS land knowing I love django and dislike flask?

>> What would you recommend I look at in JS land knowing I love django and dislike flask?

I just use typescript and nodejs and the database.

No framework except the express web server.

It's incredibly raw and close to the metal, which I like.

Here's a throwaway example of register and login from ChatGPT to illustrate how easy it is. Totally unchecked but it's just to show approximately what's involved - and it's not much at all.

    import express, { Request, Response } from 'express';
    import bcrypt from 'bcrypt';
    import db from './db';
    
    const router = express.Router();
    
    router.post('/register', async (req: Request, res: Response) => {
      const { username, password } = req.body;
    
      // Hash the password
      const saltRounds = 10;
      const hashedPassword = await bcrypt.hash(password, saltRounds);
    
      // Insert user into the database
      db.run('INSERT INTO users (username, password) VALUES (?, ?)', [username, hashedPassword], (err) => {
        if (err) {
          console.error(err.message);
          return res.status(500).json({ error: 'Internal Server Error' });
        }
        return res.status(201).json({ message: 'User registered successfully' });
      });
    });
    
    router.post('/login', async (req: Request, res: Response) => {
      const { username, password } = req.body;
    
      // Check if user exists
      db.get('SELECT * FROM users WHERE username = ?', [username], async (err, row) => {
        if (err) {
          console.error(err.message);
          return res.status(500).json({ error: 'Internal Server Error' });
        }
    
        if (!row) {
          return res.status(401).json({ error: 'Invalid username or password' });
        }
    
        const isPasswordValid = await bcrypt.compare(password, row.password);
    
        if (!isPasswordValid) {
          return res.status(401).json({ error: 'Invalid username or password' });
        }
    
        return res.status(200).json({ message: 'Login successful' });
      });
    });
    
    export { router as routes };

For database I use the postgres.js library which is super nice https://github.com/porsager/postgres

examples from postgres.js front page:

    import sql from './db.js'
    
    async function getUsersOver(age) {
      const users = await sql`
        select
          name,
          age
        from users
        where age > ${ age }
      `
      // users = Result [{ name: "Walter", age: 80 }, { name: 'Murray', age: 68 }, ...]
      return users
    }
    
    
    async function insertUser({ name, age }) {
      const users = await sql`
        insert into users
          (name, age)
        values
          (${ name }, ${ age })
        returning name, age
      `
      // users = Result [{ name: "Murray", age: 68 }]
      return users
    }

Respectfully, and thank you for taking the time to reply, this is why I clarified I like Django and dislike Flask.

I'm not interested in writing all my sql for every operation. I will gladly take the overhead of an ORM for the convenience in centralizing query building, table definition, object mapping and (in the case of django) migration tooling. Knowing it's battle tested saves me from my own silly mistakes.

I do love sql alchemy so I can imagine enjoying something like Prisma but I suspect express is going to leave me wanting more.

I think my next project will use Go to force myself to avoid Django and pick up a nice perf boost with much better type safety than Python + MyPy.

Well, for me this is less way readable than python. And I know JS for a long time, yet IMHO its syntax and structure seems clunky.

Readability and unfamiliarity are two different things.

It doesn't seem that close to the metal, and not enough to justify the lack of convenience and readability.

It's like using C++ instead of C#. Still pretty removed.

I'm not sure you can call one or the other "better".

Python is more type safe due to run time type checks (less lolwut). Also, less typing. But, you also get the Django ORM which is great for productivity (good for complex but low volume apps).

JS has some great features: async/await, deconstructing objects, nice JIT, same language as in browser. However, it's also very lisp-y, which is a pro and a con :)

>> I'm not sure you can call one or the other "better".

I should have said "better for ME".

>> you also get the Django ORM

I decided the best way (for me) to write back end application is:

* typescript

* nodejs

* postgres

* plain old SQL

I realised I hate using ORMs and much prefer the raw power and directness of SQL. Postgres is an incredibly powerful database - I find it's a problem to have any sort of abstraction between me and the DB.

And honestly typescript is a real pleasure to write.

I still use Python extensively for other stuff, but for web servers, typescript/node/postgres is my preference.

I found the best way for me to write backend applications is with an ORM.

Because SQL is super slow to write.

The exception is sqlx in Rust when I want something super correct.

>> Because SQL is super slow to write.

ChatGPT writes SQL incredibly well - presumably because there is so much training material out there.

Seriously, ChatGPT is the single best reason to change your architecture away from ORM to plain SQL.

That's interesting. But no. I can write queries so fast with the Django ORM it's silly. Especially dealing when dealing with relationships...

Pycharm will auto complete like 4 levels of joins in two seconds. That's faster than you tabbing to chatGPT let alone writing the prompt.

Writing the code is only part of the equation though - especially if you are not very fluent in SQL. I imagine it gets annoying quite quickly if you need to ask ChatGPT what different fragments of SQL do 6 months after you have generated them.

Ah. So you're not writing the SQL, ChatGPT is.

Yeah, no thanks. I'll stick with Django.

Sounds like you still see ChatGPT as a bad thing in some way.

I can almost hear the subtext "AHA GOTCHA! you don't understand the code being written!"

ChatGPT is a programming assistant - it is an advantage that assists in your programming.

You still have to understand the code, and more often than not you need to debug it and refactor it to make it work or make it work nicely.

If you are not using ChatGPT as a programming assistant then you're wasting time and doing yourself a disservice.

> Sounds like you still see ChatGPT as a bad thing in some way.

Not really, it can be a useful tool, I'm not ready to just delegate all my code writing to it and no professional developer should either.

You're talking about using raw SQL because it's "closer to the metal" (it isn't really), but then really you're just using ChatGPT to write your code so in a way, you're much further removed from the metal than framework developers.

If I had to choose between an OS written in C++ by skilled humans vs an OS written in ASM (because it's 'closer to the metal') by someone who had ChatGPT write most of the code and "checked" it, I know which I'd choose.

Do you ever find yourself building utility functions etc which start looking like a lightweight ORM?

Nope.

Always raw SQL. I move the SQL statements into minimal functions that live in their own files to separate them out from the code as much as possible.

I'd be curious how your apps stand up to a WAPT.

> Python is more type safe due to run time type checks

How could Python's runtime type checks be more safe than Typescript's completive type checks? Nobody sane uses typeless Javascript for serious business logic now anyway.

Also, TS type checking is not at run time (with NodeJS). So some library could allow unsanitized data as a wrong type etc. at least with Python it'd fail fast.

Libraries like io-ts make it trivial to write type definitions once and use them both for both static and runtime checking.

> Libraries like

But this is already solved by so many other runtimes... Without a library..

That's why I love js ecosystem. If something is implemented in language itself, runtime or standard library, it will never meaningfully develop.

It doesn't need to be developed... An int isn't going to store a String in Java because of a bug, that doesn't require further development.

FastComments main backend is around 200k lines of plain JS. I do extensively use JSDoc however.

Is there anything like django admin?

I'm open to JS or Java tbh, but django is just so productive because of admin, forms, user management and DB migrations.

Give me those in a more performant language and I'll be interested, but I just can't find them. Add to that that django has all those under one roof so you can hire a django dev who doesn't need to spend 2 weeks learning your libraries, and I'm just wondering why the faster languages ignore such a value proposition.

not sure what you are asking here. if you use a frontend framework with django as a backend to build your site, you still use django admin as before. there is no need to replace that. you are only replacing the end-user facing frontend.

The GP was suggesting chucking out django entirely as I read it.

oh, right, sorry, then that's a fair question.

I'm a JS guy but I'm not sure I would agree.

Backend frameworks in JS are not as mature as Django, Rails, or Laravel.

Out of curiosity, what do you perceive as the main advantages of JS on the server vs Python?

It's personal preference that's all.

To be honest it's more that I prefer TypeScript to Python. Python and JS have been my main programming languages for 14 years or so.

Either are good - I'm not totally off python. I still write async web servers in Python for various reasons. I'm not much of a fan of Python's type system probably because I haven't yet spent enough time to really learn it.

I definitely use Python for Linux systems programming or non-web server stuff - Python is really great for more systems oriented stuff.

I really liked Django at first but after a while some things really started to bother me about it.

The ORM I found complex and clunky - any time I wanted to do something I kept thinking "Ugh this would be dead simple in SQL".

Needing to add plugins to Django - I often felt like it took me the same amount of time to work out how to install and configure a plugin, as it would to write the same functionality from scratch, with the disadvantage that at the end of the process I'd often still feel like the plugin was a black box that I'd managed to make work but was never sure I had done it right.

And the thing that really annoyed me most about Django is it's meant to be "batteries included", but the very first thing you need to do is work out how to implement users and signin and forgot password and signout - all stuff that should be the very definition of "batteries included". Instead, at the start of every Django project you're left to try to work out what is the right plug and how to install it and did you do it right. If I have to do all that stuff yet again for every project then why bother with Django at all? Why not just use a minimal web server and implement it myself because I'm going to have to anyway.

And then, after forming these hesitations about Django, I started doing async web programming with Starlette and FastAPI and found I really liked async web server programming and Django isn't async.

So at this point I'd pretty much lost interest in Django.

Or you get hung up on how bad JavaScript is compared to Python.

I still like using Python on the back-end. But, I've also been waiting for what, 10 years, for Django to get async support.

Here here. The same app built in Django was worse frontend, worse package management, and worse deployment than a Next app.

So it’s a kind of survivor bias: those who learned JS stopped using Python for web backend.

I still like Django on the backend.

Yep, the future is JS full-stack. Especially with stuff like Trpc, Next, Server Components. These frameworks just have much more options to integrate the frontend and backend nicely.

Disagree on RXJS. Oh how I loathe it.