5 ms·

The Django community goes out of its way not to learn JavaScript. I’ve been a Django developer since 2008; I was allergic to JavaScript (for good reasons) too.

The Django community goes out of its way not to learn JavaScript. I’ve been a Django developer since 2008; I was allergic to JavaScript (for good reasons) too. After almost five years of front-end development I can tell you that most of those reasons stopped being valid sometime between 2017 and 2020. JavaScript is a great experience now. I didn’t do it willingly. Front-end developers are expensive and hard to size up if you don’t know what Flexbox or a Promise is. If you’re going to be doing anything web related you might as well get comfortable with the fact that learning JavaScript, TypeScript, CSS, Sass, HTML, and something like RxJS is going to make you a better developer and your life easier.

mutagen 3y ago
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.
- miiiiiike 3y ago
  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.
- mattmanser 3y ago
  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.
  - em-bee 3y ago
    but that's a browser problem, not a frontend framework issue. you'd have the same limitation without a frontend framework, wouldn't you?
  - miiiiiike 3y ago
    > 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.
  - mutagen 3y ago
    Those are great examples, there's still work to be done.
- berkes 3y ago
  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.
andrewstuart 3y ago
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.
- pier25 3y ago
  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.
- leetrout 3y ago
  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?
  - andrewstuart 3y ago
    >> 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 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 }
gmt2027 3y ago
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.
- miiiiiike 3y ago
  > 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.
PrimeMcFly 3y ago
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.
deleted 3y ago
[deleted]
mythrwy 3y ago
Disagree on RXJS. Oh how I loathe it.

mutagen 3y ago

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.

miiiiiike 3y ago
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.
mattmanser 3y ago
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.
- em-bee 3y ago
  but that's a browser problem, not a frontend framework issue. you'd have the same limitation without a frontend framework, wouldn't you?
- miiiiiike 3y ago
  > 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.
- mutagen 3y ago
  Those are great examples, there's still work to be done.
berkes 3y ago
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.

andrewstuart 3y ago

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.

pier25 3y ago
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.
leetrout 3y ago
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?
- andrewstuart 3y ago
  >> 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 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 }

gmt2027 3y ago

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.

miiiiiike 3y ago
> 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.

PrimeMcFly 3y ago

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.

deleted 3y ago

[deleted]

mythrwy 3y ago

Disagree on RXJS. Oh how I loathe it.