No five-level hamburger menu, you can actually see stuff without scrolling and panning. And, probably, the most horrific of all: the text has enough contrast so you can actually read it!
Text contrast is actually one of the most common issues with the Django admin. Just on the screenshot in the article, the white text against the light blue breadcrumb and nav headers background is too low contrast as per WCAG 2.0 calculations.
"Ugly" might not be the best one-word description but there are a lot of basic accessibility issues with the Django admin. The general user experience could also really benefit from using more modern design patterns (for example modal windows over pop-up windows).
I’d say because you can lose context more easily when having to move to a separate browser tab / window to complete a task? And I suspect the multi-window paradigm is also harder to navigate for keyboard / screen reader users (as opposed to an in-page modal which correctly captures the keyboard focus while open).
Is that a real problem for professional users or just a kluge to work around the ever-decreasing IT skills of today's generation that can no longer do basic things such as window management?
I think an OS-managed popup window is superior to a page-managed modal since it allows you to move the window out of the way or even switch away from it, where as a page-managed modal is generally fixed in place, blanks out the parent page, and the only way to get back that parent page would be to dismiss the modal which discards your input.
I'm also not sure whether the accessibility concerns are substantiated - surely window management would be a well-trodden path for any screen-reader user and whatever you build yourself in-browser would have different and unexpected semantics that would require the user to get used to it.
Sorry I’m not sure I understand your question? I wasn’t on the internet before web 2.0, by modals I mean things like custom-styled <dialog> element[1] and the `dialog` ARIA role, which I would say are a more recent pattern than pop-up windows. "Modern" might not be the best term here, I should have just said more "usable" perhaps.
The HTML <dialog> element is used to create both modal and non-modal dialog boxes. Modal dialog boxes interrupt interaction with the rest of the page being inert, while non-modal dialog boxes allow interaction with the rest of the page.
The modal dialogs are easier for the programmer to use but they're quite inconvenient because generally, they ask you a question you can answer only by looking at/interacting with the rest of the page. Which you can't do (the modal dialogs on web also almost never can be dragged around).
The term "modal" pre-dates <dialog> by a huge amount, and generally refers to a popup within the same window that prevents interacting with what's behind the popup (I believe the term comes from how you "change modes" when it appears). On the web they used to be implemented using <div> and CSS, often with some sort of javascript library so you didn't have to do it yourself.
I think you remembered it wrong. Going from pop-ups was earlier than modals. Pop-ups were supported by things like window.open() which has been around forever (perhaps NetScape 2.0?). In contrast designing a modal requires some slightly more recent CSS like absolute positioning (I believe CSS2 so still within the previous century).
The only thing I’ve noticed is that the “ADD POST” text is at a different height than the “+” next to it, which is a bit jarring. It’s also the only button shaped as a rectangle with rounded corners on the page (aside from “Go” which is styled differently as well). Overall, I see 4 different styles of buttons on this page. But other than the buttons, it seems fine to me.
Yep, the different button styles for no clear reasons is one. This is even more apparent on other views. On that screenshot, you can also spot questionable alignment between e.g. checkboxes and the title text in the table. Contrast issues with text against different background colors. And I’d also question whether UPPER CASE TEXT is necessary.
In the screenshot I only see 1 button on the page... The two styles of "Add" are links to another page, and I'm not seeing at all whatever the 4th one you're seeing is. Is the 4th below the screenshot?
It isn't. It's simple and functional and designed for its purpose of being a starting point UI bundled with the framework. You can extend with other admin interfaces really easily, but including that as default adds bloat for users that don't need that extra eye candy.
It is certainly simple but I’d disagree it’s functional _enough_, because of the numerous basic accessibility issues with the fundamental UI components.
On extending the admin – perhaps there’s something to be said about the admin coming with more UI components built-in? For example it lacks any dialog / modal window implementation, or an "accordion" / disclosure pattern. Or things like support for keyboard shortcuts.
Isn’t part of the point of the article that it is not a starting point UI? “[The admin] is not intended for building your entire front end around.” Or have a misunderstood what the author is saying?
FWIW, pretty sure it's _also_ intended for the developer (and "admin") to use the admin interface to interact with the database even after the frontend is complete..
Perhaps, yes, I'm referring to the question being posed more than anything. I understand the point, but imho the default admin is to administer the models and state, not (out of the box) intended for end users. Some don't require an admin interface anyway. I understand the sentiment though, I think :)
Yep. You’re on the money. Look at it this way. The product I worked on got acquired, and we went from a 5 person bootstrapped company that knew the product intimately, to all sorts of far less familiar customer support, sales, etc people needing to do various sorts of “admin” actions. I flat-out refused to subject these newbies to Django admin, and prioritised building proper administrative tooling. That decision has paid dividends. Django admin by its nature is always going to expose idiosyncrasies of your data model and by its own admission doesn’t give you infinite opportunity to insert your business logic layer.
Cue someone used to working in “scale until you die” startups telling me that any time not spend on juicing MAU is time wasted. I like working in sustainable businesses.
I’ve worked with Django for a decade. I’ve done ungodly things with Django admin. Things most people wouldn’t dream of. I am completely over doing any of that. This isn’t a fault of Django admin. It’s very good at doing what it’s intended to do. It’s just a very common beginner’s trap to try to push it further than it wants to go.
There’s plenty to critique Django admin for. I fought with it just last week. At the same time, most complaints I see about it tend to be people (IMO) misusing it. It’s the service panel. And yes, people other than the engineers that built the thing have reason to pop open the service panel. These are your mechanics. But, and especially for SaaS products, don’t conflate “user” with “customer”, and not think about your other audiences.
The most brilliant thing about it is how simple and plain it is. I was a dev team of one for years and basically got a mountain of free work because the admin panel exists and is generic enough not to be weird for internal company users.
The simplicity also makes extension simple. I could add a few features.
I actually love the way the Django Admin UI looks, but it does go against the grain of the current trends in UI design by being a bit explicit. For example, the "add post" button looks like a button rather than just being words and there are borders demarcating boundaries between sections. I think it's both good looking and a lot more usable than the current trends in UI design which favor minimalism to the point that it can be hard to discern what is clickable.
Agreed. If the rest of new sites looked more like Django admin and less like current trends, I certainly would like the web a lot more.
I'm soooooo sick of React doing completely hostile things like flashing incorrect information for empty widgets or completely breaking page location when hitting the back button.
Seems like every few years it becomes accepted to make the web worse for users because of front end fashions.
> I'm soooooo sick of React doing completely hostile things
This isn't really React's fault. Avoiding the things you mention is entirely possible when using React. It's all up to the developer to handle such scenarios, just as it was without React.
I don't think it's always that the dev is choosing to implement these quirks. They're choosing to add extra functionality, but not always implementing it well.
You can choose to have higher latency for the initial request and just display static HTML. Or if you want to load content on demand, then you do have to deal with what happens before anything loads, but I don't think that's the fault of React. Any framework which does this is going to have the same problem that needs to be solved.
Similarly to React "breaking" the back button. If you want user interaction without another page load, you have to deal with the consequences such as needing to track page history more explicitly than you might have otherwise. But that's because the dev chose to change the page content without moving to a new URL, not because that was implemented using React.
What you say would actually indicate that yes, it is React'a fault, would it not?
It's not possible to flash misinformation with normal front ends before React, without going to extreme extra effort to enable such misbehavior. Whereas with React, the easiest programming path is the user hostile path. And React is adopted only to make it "easier" on programmers.
Asynchronous data loading is the core of the problem. React without any other addons like redux, where state is dumped into the page and just passed down through props would avoid the issue (though it can have a different one where the page is blank for a moment before the javascript renders the page). Same with HTML and no frontend framework, it's all loaded synchronously with page load so there's no "empty data" state.
Redux encourages loading data like that, and the easy way to use Router makes it easy to do that - all URLs get sent to the same backend view to render the app, then the frontend takes the URL args and triggers ajax to get the data. During that interim when the ajax is running is when you get this empty-data state.
The overhead is only the latency of the ajax call on the first load (since you are going to the server to fetch the app code, then going to the server again to fetch the data, instead of going to the server and fetching the app code + the data).
For every consequent page transition the performance is actually slightly higher than a full page load since (a) you're probably only fetching JSON instead the entire resulting rendered HTML and (b) you don't have to load the app code any more.
With jquery, you'd have to put in a lot of work to do this. And I'm not a front end engineer, so I went from knowing enough jquery to be dangerous to doing React tutorials,
where I saw how the design of this system was enabling bad default behavior.
If my irrational hatred has a better target than the term "React" I would like to know it. I do despise the usability of nearly every SPA I have used. It is perhaps possible to program an SPA so that the deficiencies are not noticed, which is great, but that does not appear to be the norm nor is it made easy by SPA frameworks.
The flash of inconsistency you see is because the client eagerly modifies state before the server persists it (or some form of this problem).
The routing issue is because the application (SPA) is using business logic to control the browser's navigation state. Sometimes opening a modal will be a new push on to the nav stack so you can hit back, sometimes it isn't, sometimes they forget things, etc..
All of it though is just too much state being managed on the client by the application and that state being managed poorly. This isn't only related to React. It's always been possible to screw up with managing state in any framework.
Perhaps, but then make the other add buttons in the sidebar look like buttons as well to be consistent. At least, that's what I would do. I hate having to guess what's selectable without hovering.
The content of the Django admin is also basically the applications understanding of the database, making it very verbose at times. The admin has some tricks, for instance it replaces booleans with checkmarks and you can deep reference relationship fields or directly link to their preferred record.
Either way, it's a lot of text that shows up in a consistently stylized and clean way, which is tough to achieve for something like an admin panel.
I too dislike the current UI trends and I still think Django Admin is an ugly piece of software. It was ugly 10 years ago and it's still ugly today. It gets a lot of simple design things like margins very wrong.
It's purely visual though. It's a great piece of software to get out of the box.
Open source software and not nailing margins/padding - name a more classic combo.
All joking aside, I like that the Django admin still looks the same after almost 20 years. Cannot begin to impart how much value that thing has provided me.
I've been places where the admin tool ends up being a frontend for the backend. Like you get so much for free, so it's tempting to just add a simple widget to extend the admin with one small feature you're missing to make it possible to edit whatever. Instead of building a dedicated frontend for it. So then you give editors or whatever access to modify stuff there. And then they request some changes, and rather than building a frontend from scratch you again tweak the admin panel for some model. And suddenly you've got tens of people doing their daily work in the admin panel and a mess you will have a hard time getting out of.
It being ugly is a feature. Don't fall for the temptation of giving non-devs access!
(But it could have kept it's look while still being more friendly to use, though. So many huge selects and difficulties to fill in valid data in some cases)
Happened to me: a coworker asked for help while using a webapp where she needed to upload some files and fill some forms, but the frontend was confusing for her. When she opened the web... it was the Django Admin! The programmer just coded the models, put them in the admin.py and gave everybody "staff" status.
You're very right, "the Django Admin is so useful that we use it for everything" seems like key context that's being under-discussed in this thread. Most all of the user-complaints in the linked sources seem to focus on how people are using the Django Admin for many many things and "just want to make small changes" or "they just want validation to be better" or they "want it to look nicer for our customers (!!!)", and they want that because the Django Admin is so useful and ubiquitous that they seem to be trying to use it for everything.
I think the django admin is quite an accomplishment of software engineering and functionality. The amount of functionality you can build quickly is impressive. Sure it might not have the slickest UI, but a lot of those slick frontend features in modern UIs have half thought out semantics and take ages to implement vs django. Django lets you concentrate on the actual business problem , but becomes painful to do extreme customization on. There are multiple styling extensions for django that help.
I think there is Trader UI, and VC UI. Trader UI, built for wall st packs every bit of information into every pixel possible. VC UI has rounded corners, nice fonts, drop shadows and half the information on the screen. Django UI actually splits the difference nicely.
You can just go download some trading software like thinkorswim or IBKR TWS to see what's trader UI. VC UI probably means some UI in a VC-funded company whose goal is to reach high number of users as quickly as possible, and the UI is optimized for that goal.
A more charitable way of putting it is, you can make a pretty presentation when you know the data that you are trying to present and the story you are trying to tell. I can't imagine a 3 column pricing table that wasn't done in bootstrap (Venture Capital UI)
Traders look at screens searching for meaning across a bunch of different data. They are trying to construct a story and as much context as possible is important.
The problem comes when VC UI is applied to a Trader problem where you want to see as much information as possible to understand, but there is padding, rounded corners and other stuff forcing you to scroll.
I'm building a small startup and wanted to have some semi-automatically generated admin for it. After looking at all the modern React-based solutions, Django still looked like the easiest way to go. Ugly and non-SPA? Sure. But still very simple to keep working, google has answers to most little tweaks one wants, and easy to manage. Loving it.
It depends on your skillsets, but I'd highly recommend https://directus.io/ especially if you need "slickness" to raise money otherwise try a pyhat stack if you hate javascript.
In UI design, developers perennially mistake the aesthetics of a design with how well the design functions, generally. Interfaces are a form of communication, and the most important pieces of it are things like visual hierarchy, gestalt, and implied lines to show relationships between elements. Just like any other sort of communication, lay people tend to either say all the right things in a way most people find confusing, or not say enough because the other way is too confusing and assume the problem is what's being communicated rather than how it was communicated. Developers putting an interface together ad-hoc tend to do the former, blowing off complaints as people not trying hard enough or reading the docs or whatever. Other developers trying to gussy up the mess the first developer made assuming the problem is aesthetic tend to do the latter, and dismiss complaints by saying things like 'design is subjective' entirely disregarding the possibility that they did a bad job.
An aesthetically pleasing interface is a side effect of someone fluent in that language working hard to figure out how to communicate information, action, cause and effect, etc to the end user. It's not an easy language to learn, it's important even in relatively trivial cases, and developers trying to wing it are about as good at it as designers cargo-cult assembling PHP to modify a WordPress deployment: It might get the job done in a very basic way, but nobody should convince themselves it's a real solution. Just like a developer might look at their interface and say "read the docs" or "design is subjective," that designer might see how slow their 5-deep for looped set of database queries is and say "this server is too slow" or "why can't those damned developers make WordPress faster?"
So why does everything look the same (even to the same colours, locations (responsive & fixed) and sizes) after spending all that money and effort? And when something looks/behaves different, 'normal' (not in IT) people find it annoying to use? How can my wife find trivial operations in our shite IT banking site, but is lost on Instagram for some of the same settings? Our bank has an IT spending which is a rounding error on Insta's budget.
I agree with what you say somewhat, but I believe about the massive difference between UI/UX. If I have to sign up to something for the first time or have to buy something, I want pretty pictures. If I have to work with something often (all day let's say), I want UX and I couldn't give a shite about UI; I want things easy to find, fast (not latency) etc. Combined would be great, but tell me what has that, because I always see one, never both done to perfection. If there is a 50/50 mix, it's usually annoying as hell on both sides.
My most productive interfaces are ugly as hell ; no animations, no overhead and everything crammed on a screen and very fast. I would never 'sign up' for an application like that seeing it first, but I would never use any application long term for productivity like most people say is 'beautiful' because it's inefficient.
> I agree with what you say somewhat, but I believe about the massive difference between UI/UX.
There's bo difference. The GUIs have started rapidly going downhill right after some idiots decided they are different and the rest of idiots believed it to be true.
How can you have a UI without understanding how it functions and how it's used?
When looking at the aggregate you can get things like the two political party system in the US that is a perfect compromise but doesn't function for anyone in the aggregate.
They've A/B tested Meta's goals of increasing user time on site and ad views, not user goals like discovering how to change the setting for something that annoyed them.
A/B testing isn't immune to being as broken as the UX in some of the gnarlier bits too. Perhaps some of the links that simply don't work on the Facebook mobile app are busy signalling that they get way more clicks than the one that successfully loaded the content...
I don’t agree with this viewpoint. Major companies with billions in R&D and some of the smartest people on the planet are not making fundamental ux mistakes.
Google's terrible at UX. I once spent about five full minutes figuring out how to navigate my dad's phone app on his Android phone, so I could help him use it, after an OS upgrade. There were some tabs that didn't look like tabs and didn't indicate which was active, turns out. He'd have had no hope of figuring it out on his own.
Once was helping my grandma add contacts in Gmail. She had failed repeatedly. Kept hitting "add contact" and it'd blank the form she was on, without adding the contact. This was because there were two same-color-and-weight add-contact buttons on the page, with the same copy, and one submitted the form, while the other gave you a blank contact form. You pretty much had to be familiar with how HTML nesting worked to have good shot at guessing which was the one you wanted, just by looking at it.
That second one's an older version of the UI, but holy shit it was bad. They definitely make mistakes, and really obvious ones at that. Money and "smart" doesn't mean shit.
I read GP as saying they intentionally make the UX dysfunction for actually features (e.g. privacy settings, finding the “most recent” feed - I didn’t even bother to look for that one recently), and only optimize for eyeballs on the main feed and therefor monetization.
One important caveat: Defining good UX is subjective. Ensuring the user has the best possible experience using the product how they want to use it is very different from ensuring they have the best possible experience using the products how the company wants them to use it. I agree that they're not likely making many technical design mistakes in implementing their strategies, but whether or not it yields "good UX" depends on if you're willing to accept the X boundaries applied by the company as "good." You can have a seamless, perfectly implemented, smooth and appealing process that leads users into a dark pattern pushing them towards an action that doesn't work in their best interest: great UX work from the company marketing perspective, shitty from the user perspective.
Yeah, good example is Preply. All the site and interactions seem to be geared into tripping you up. I don't use it but sometimes help people here who are learning a language and it's infuriatingly bad, making sure that you are booking the wrong (more expensive) thing. And support acting like they don't get it 'it should work'. Could be bugs, but if bugs, why does the amount always come up higher, never lower?
> So why does everything look the same (even to the same colours, locations (responsive & fixed) and sizes) after spending all that money and effort? And when something looks/behaves different, 'normal' (not in IT) people find it annoying to use?
Really though? Does your web browser interface look the same as your sms/messaging interface, look the same as your car's annoying infotainment interface, look the same as your mail client, look the same as this website, look the same as your search engine? Do all of those things really look the same as they did 10 years ago? We use so many interfaces that are subtly shifting and being improved that the ones that work well for right now don't even stick out to us, and that's part of the problem. If you don't really notice that you're using an interface and are entirely focused on solving the problem you need to solve with that tool, then that's probably a really well designed interface. It's probably so smooth and intuitive that it seems like designing it that way would be obvious, but it's really, really not.
> If I have to work with something often (all day let's say), I want UX and I couldn't give a shite about UI; I want things easy to find, fast (not latency) etc. Combined would be great, but tell me what has that, because I always see one, never both done to perfection. If there is a 50/50 mix, it's usually annoying as hell on both sides.
You don't have an particularly accurate understanding of these roles. If a UI doesn't let advanced users solve their problems efficiently, then it's a shitty UI. "Pretty Pictures" where not appropriate is bad UI design no matter how pretty it is and people who don't think so are visual designers (at best) trying (and failing) to be UI designers. A well designed UI is an effective UI. All of those pretty UI mockups you see on sites like Dirbbbbbbble and behance are nothing more than aesthetic explorations. There's no way you could even know if they were good or bad UIs because you don't know exactly what problems they were trying to solve, for whom, and in what context.
UX encompasses the entire experience. If you have a great UI but the world's shittiest email confirmation workflow, then you have a UX problem with a great UI. This misconception is why developers think adding the ability to select color themes in their application with a horrible UI will address UX problems-- which to any actual software designer is complete nonsense.
> My most productive interfaces are ugly as hell[...]
A couple I'm friends with had a broken kitchen faucet handle for ages-- it would just fall off unless you held it on while operating the faucet. Unfortunately, one of the necessary connector pieces was no longer available, so it wasn't a trivial fix. Once, when I was pet sitting their rabbits, I got so annoyed by the thing that I went home and made a wooden piece to fit in where the missing part went, and fixed it while they were still on vacation. It was supposed to be a surprise but I totally forgot about it, and a few months later my wife said to them "hey do you like having your kitchen faucet fixed?" They looked at her, perplexed, walked over to the kitchen faucet, tried to pull it off, and it obviously didn't come off. They were shocked! Why? Because they were so used to holding that damned handle on the faucet that it just became an part of their using that faucet.
So not to be flip, but, the sky is blue, water is wet, and technical people are tolerant of and used to using shitty interfaces. Open source user interfaces are almost exclusively used by technical people; there are a few exceptions like Firefox, but Firefox's interface is managed by a team of foundation-funded full-time professional designers, (actually they do a lot of really great open usability work.) One exception I can think of is Inkscape. Most open source interfaces are ...
I don't know, but also this is not a question that interests me. I'm not looking for tech for the sake of tech. I'm looking to solve my problems, and this solves my problems - that's all I care about.
Django is an artifact from another time period of the web, and I'd argue it's in decline.
If you want an admin wrapper around your database, you have better many modern alternatives (I use directus).
If you want low code and easy platform, you have bubble.io.
If you want an easy api for your database, you can use things like hasura.
If you want python frameworks, try fastapi (its third party admin is great).
If you want an orm, sqlalchemy gives you more bang for your buck.
Many of Django's third party packages are out of date.
The data science python community has settled on Gradio.
The sweet spot of Django seems to have disappeared.
Jobs for Django are lower paying, and often more high stress than .net or other languages.
Django has a great outreach with it's Django Girls, Afro-Django and Django Foundation. However I feel like it's technical side needs far more love, the source code needs some major refactoring and cleanup.
I thought about this indepth on whether to send my daughter to django girls, or just train her in .net and c# myself.
It's usage is mostly rest api's in silicon valley.
It's third party ecosystem is basically dying (especially noticeable when compared to ruby on rails). Job hiring for Django is disappearing from the non startup arena, which is especially bad for career developers since you need a career pathway.
i use it everyday and i'm nowhere near silicon valley. i've also noticed a lot of startup hiring posts for django developers. we are both speaking anecdotally, but here is the HN hiring post from october 2023 that includes 9 posts: https://hnhiring.com/search?q=django
> It's usage is mostly rest api's in silicon valley.
This partially matches my experience.
I see Django mostly being used for prototypes, which then become "the monolith" that allows the company to grow to the point where smaller services - or dare I say "microservices" - are more appropriate. There are a couple of things that stand out to me about that use case, though.
First, Django allowed the company to build a product and grow its business to this point in the first place. Without Django, it would take significantly longer to build things. Early stage startups are all about implementation speed; they often end up building several iterations before finding traction. Django's "batteries included" approach means you end up with experienced developers who can very quickly build out a green field services with it. You also get a hiring pool of people who are able to come into a project and be productive very quickly, since the architecture is well-defined and shared by projects they've worked on in the past.
Second... monoliths rarely die. I've been doing this for almost twenty years now. I've been through multiple rewrites and initiatives to break up an existing monolith. They very rarely succeed. My recommended (and by far, my preference) approach is to impose an informal "new feature freeze" on the monolith, build out new functionality as new services using the most appropriate tool for each, and slowly shrink the monolith. Over time, as core features are maintained, they can be more cleanly separated conceptually from the rest of the monolith. Eventually you'll get to a point where it makes sense to split off some existing features into their own services... but you'll likely never get to the point where the monolith is actually gone. Once the tech debt is reduced to the point where reducing it further is no longer the most impactful thing you can be doing, it doesn't make sense to "finish". The result is that even very mature companies that were once startups end up still needing people to work on Django projects.
> It's third party ecosystem is basically dying (especially noticeable when compared to ruby on rails).
Is it?
Sure, there are fewer shiny new projects these days. If you only look at tech news, you might see fewer Django extensions and such being announced - but that doesn't mean the ecosystem is dying. It means that the ecosystem isn't rapidly growing. In this case, I'd argue that's because both Django itself and the ecosystem surrounding it are mature. There aren't a bunch of exciting new packages being released because the packages that we already have are working well enough that there isn't a need for more.
> Job hiring for Django is disappearing from the non startup arena, which is especially bad for career developers since you need a career pathway.
I'm ~40. I've been a professional developer for twenty years, and have worked for startups exclusively for ten years. I feel absolutely no need to "settle in" and specialize in a single framework. Or even a single language. While most of my experience is in Python, I've built (work) projects in Clojure/Clojurescript.
I've taken jobs where I'd never even encountered the stack they were using. I recall one interview in ~2018 where the job was leading a team refactoring a Scala monolith into microservices. The first of those were in were in Scala as well, but they were having trouble hiring. Very few candidates had Scala experience, and not many more were both capable of learning it quickly and interested in doing so. I literally searched for Scala examples in my Zoom interview, while sharing my screen. After skimming the Wikipedia page I confidently told them it wouldn't be a problem. They seemed shocked at that, and the rest of the interview was my collaborating with them on a minor ticket they were currently working on - I was able to s...
> Django is an artifact from another time period of the web, and I'd argue it's in decline.
If it's able to survive other 3 or 5 years, I'd argue the pendulum will just swing back to the "django's way".
> If you want an admin wrapper around your database, you have better many modern alternatives (I use directus). If you want low code and easy platform, you have bubble.io. If you want an easy api for your database, you can use things like hasura. If you want python frameworks, try fastapi (its third party admin is great). If you want an orm, sqlalchemy gives you more bang for your buck.
And your requirements.txt or poetry.lock file grows and grows. The thing I really like about django is that I don't need any external packages to start. I have basically everything I need to start inside a single package and don't need to bother about how to integrate sqlalchemy with flask, how to add auth and authorization to my stack or how to check that all of my tens of dependencies are safe and regularly updated.
The only thing I really miss is something like LiveView. I know there's htmx and similar, but i hope they will be some "official way".
What you mention as weaknesses would be considered strengths by other people though. I'm sure it's indeed possible to replace every single bit of Django functionality with a third-party package or service, but there's value in not having to do that.
Most of the alternatives you list wind up having to be cobbled together with other things to create a full application, I think Django still delivers very well on the promise of being an extensible unifying layer that keeps development focused on differentiated work rather than reinventing too many wheels.
Having used Django on and off for ten years or so I don’t perceive the ecosystem to be dying–the last large project I worked on used dozens of third party Django plugins and only one or two were unmaintained, and even those had some active forks happening.
This reeks of personal taste and bias. “Django jobs pay less”? Yes, I suppose in comparison to C#/.NET jobs in corporates. To not send your daughter to Django Girls because of your personal language bias is completely lost on me. Django Girls isn’t even about learning Django. The benefit your kid is getting from that, the skills they’re really learning, are transferable. C#/.NET is just about inarguably a less approachable platform for a beginner looking to develop rapidly and have fun doing it. Python by itself just has a much lower barrier to entry. Again…it sounds like you’re not taking your personal tastes and familiarity into consideration nearly as much as you should be.
You’ve also entirely missed the point of Django admin. It is not your app. It is not your project. It’s intended as a crutch. The fact that it integrates with your ‘front-end’ code, in a way that a no-code platform popped in front of your database does not, is literally its main selling point.
I've worked in the industry for over 20 years now, skills are transferable only to a degree. If you are applying to a corporate job, the person with c#/.net has the edge over someone with the equivalent experience in python/django.
Developers hate admitting this, but tech stacks matter to your hiring potential.
My daughter can learn teamwork and other skills from the billion other kid oriented groups, for programming skills I'm going to help her get the easiest best paying job.
> If you are applying to a corporate job, the person with c#/.net has the edge over someone with the equivalent experience in python/django.
If.
I spent seven years working a corporate job. My pay is higher today working for startups than it would have been if I'd climbed the corporate ladder. I've had a couple of windfalls in that time: a ~$50k payout when an investment round occurred prior to an IPO, and a ~$125k payout when that IPO happened after I left. If I had joined that company earlier, more aggressively exercised my RSOs when I had them, or had stayed until the IPO occurred, I would have seen a ~$1.5m profit. I learned from that, and now choose my employer based on my estimation of their chances at a successful exit in the time period I want to commit to the company. For me, that means choosing earlier-stage companies where I can accumulate more equity. A happy side effect of that is that I have a much larger relative impact on the company's direction, which keeps me interested and engaged in their success.
In other words... I have no interest in a corporate job. I know I'm far from alone in that.
> “Django jobs pay less”? Yes, I suppose in comparison to C#/.NET jobs in corporates.
Broadly speaking, corporate jobs offer a higher salary relative to startup jobs.
This is by design. Being engineer #0 at a startup is far less stable (i.e. riskier) than being engineer #65535 at BigCorp. The salary is somewhat lower because the company simply doesn't have the cashflow to pay more. Startups have one thing to offer employees to offset that lack of stability and lower salary: equity.
The vast majority of the time, that equity ends up being worthless. Every once in a while, it becomes worth a life-changing amount of money. It's not fair to say that Django jobs pay less. Those types of jobs are an opportunity to trade a portion of your earning potential for a few years for a chance at a much larger prize.
I don't have numbers in front of me to be able to prove it, but I'm of the opinion that when you include this in your calculations, the expected value of your labor is higher working for startups than at large, established companies. While the chance of any given startup succeeding is relatively low, it's not unreasonable to think you'll be able to join up to a dozen or so over the course of your career. The chance of _one_ of those having a successful exit is high enough that I've staked a big part of my financial future on it happening.
You may or may not be correct about it being in decline. Who knows. What I am sure of is this: engineering managers that hire candidates primarily based on which framework they've used most recently are trash. I just got hired into a biotech job which uses a framework I had never touched before the coding exam. The process was the most intense thing I have ever experienced with nine separate screenings/interviews in which I had to beat out at least 500 other applicants. Being able and willing to learn enough to solve unfamiliar issues is so much more valuable than tooling experience in this field.
I mean, the Lawrence paper has been on WordPress for like half a decade now. It's just in a hard spot because the niche it was made for got squeezed out of the market from the middle. If you have enough money for a developer, you probably also have enough money for a real backend UX.
I like it so far, I've used it for my personal projects but it hasn't even hit 1.0 and is basically only developed by one guy, so there are still major dangers with using it.
Very easy to get started though, and even comes with stuff like cron jobs and email sending triggers built in and able to use in super simple manner https://pocketbase.io/docs/js-jobs-scheduling/
according to his benchmark you can serve 10,000 realtime connections on a 4 dollar a month server https://pocketbase.io/faq.
I wish more sites were "ugly" like Django Admin, Craigslist, and Hacker News. We end up with visually "slick", but low usability, interfaces elsewhere because frontend designers can learn a million different frameworks, but you can't teach taste.
Wagtail ModelAdmin is kind of a separate beast. It sits alongside the admin. It's not exactly a replacement, but is more of an end-user tool, whereas the Django admin is more of a developer tool. For managing more complicated models such as those with foreign keys, exporting a list of objects to Excel, etc. it can be a bit easier to use for the average office worker.
After reading all of the post I'm a little confused as to what's wrong with it. It looks fine for a UI bundled with a webframework. I can understand some of the comments in the thread mentioning accessibility issues due to colour/contrast(only example I saw in the comments here)
(Author here) I personally don't think the visual style of the Django admin is ugly. I'd agree that it looks dated, and also agree that it could use a few minor color and accessibility improvements.
My perspective is that we have a new generation of Django devs among us, who grew up using fancy JS frameworks, SaaS dashboards, A.I.-assisted code tools, etc. So for a newcomer seeing the Django admin for the first time, it's a bit different.
My goal of the article was to capture the tribal knowledge that seems to have not gotten passed down to this new generation.
I don't see any tribal knowledge being passed on here. It seems django's admin panel is ugly because nobody has interest, enough, in investing to make it beautiful. And you were looking for a fancy answer with wisdom as "it's to discourage its use for consumer blabla" while the obvious answer is the right one. It's ugly and there isn't enough interest to change it, because it works well enough to cover the intended usecases. The other usecases would need more investment, and nobody invested.
I think there's also the aspect that it wasn't built with ever being restyled in mind. It looks fiddly to make changes to (even if it actually might not be), so people don't feel inclined to dig in.
It’s also really hard to change look and feel in a mature product. You have to have a good vision and then fight against a horde of people who have their own ideas, resist change, or will bike shed you into submission. And you need to have good taste and design principles to begin with; it has to be a real upgrade. And it has to be worth it.
You don’t just submit a pull request called “Redesign”. The with is more political and organizational in nature
I see three quotes from past contributors in the article, that seems like valuable knowledge to me? Anecdotally as someone who contributes to the Django admin I see the interest is there. I’d say it being clunky is for other reasons (for example there being more back-end developers contributing to the project than other skillsets).
Not sure if English is your native language, but quotation marks usually land on the outside of any other punctuation. (Yes, it does look goofy.)
Now, the quote above is kind of special because you have a portion of it quoted within a statement. However, if you are paraphrasing all but the "ugly" part. In that case, I would drop the outer quotations marks.
A few quotes from the top results on DuckDuckGo for "quotation marks and punctuation":
Question marks are a little different. If the question mark is part of the quote, place it inside the quotation marks. If the question mark is not part of the quote, and instead the quote is part of a question, place it outside of the quotation marks. This rule also applies to exclamation points.
Place a question mark or exclamation point within closing quotation marks if the punctuation applies to the quotation itself. Place the punctuation outside the closing quotation marks if the punctuation applies to the whole sentence.
Different varieties and styles of English have different conventions regarding whether terminal punctuation should be written inside or outside the quotation marks. North American printing usually puts full stops and commas (but not colons, semicolons, exclamation or question marks) inside the closing quotation mark, whether it is part of the original quoted material or not.[14][15] Styles elsewhere vary widely and have different rationales for placing it inside or outside, often a matter of house style.
Based on my internet experience (...) and among this particular HN audience, I'd say you're fighting an uphill battle given our collective preference for where to place and how to treat quotes.
IIRC this is mostly a US/UK distinction (maybe even US/rest of world). I tend towards putting the punctuation outside the quote, especially if the original quote didn't have that punctuation.
People underestimate the amount of work it takes to tweak aesthetics, much less come up with a coherent design language that is intuitive and straightforward for users to learn.
One of the eye openers for me personally was the realization that the Mastodon organization contracted a UX engineer firm. It shows.
162 comments
[ 3.4 ms ] story [ 228 ms ] threadI think an OS-managed popup window is superior to a page-managed modal since it allows you to move the window out of the way or even switch away from it, where as a page-managed modal is generally fixed in place, blanks out the parent page, and the only way to get back that parent page would be to dismiss the modal which discards your input.
I'm also not sure whether the accessibility concerns are substantiated - surely window management would be a well-trodden path for any screen-reader user and whatever you build yourself in-browser would have different and unexpected semantics that would require the user to get used to it.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
The devil is the details for real world usage on your data and it's relationships.
On extending the admin – perhaps there’s something to be said about the admin coming with more UI components built-in? For example it lacks any dialog / modal window implementation, or an "accordion" / disclosure pattern. Or things like support for keyboard shortcuts.
> The admin’s recommended use is limited to an organization’s internal management tool. It’s not intended for building your entire front end around.
https://docs.djangoproject.com/en/4.2/ref/contrib/admin/
Cue someone used to working in “scale until you die” startups telling me that any time not spend on juicing MAU is time wasted. I like working in sustainable businesses.
I’ve worked with Django for a decade. I’ve done ungodly things with Django admin. Things most people wouldn’t dream of. I am completely over doing any of that. This isn’t a fault of Django admin. It’s very good at doing what it’s intended to do. It’s just a very common beginner’s trap to try to push it further than it wants to go.
There’s plenty to critique Django admin for. I fought with it just last week. At the same time, most complaints I see about it tend to be people (IMO) misusing it. It’s the service panel. And yes, people other than the engineers that built the thing have reason to pop open the service panel. These are your mechanics. But, and especially for SaaS products, don’t conflate “user” with “customer”, and not think about your other audiences.
The simplicity also makes extension simple. I could add a few features.
I'm soooooo sick of React doing completely hostile things like flashing incorrect information for empty widgets or completely breaking page location when hitting the back button.
Seems like every few years it becomes accepted to make the web worse for users because of front end fashions.
This isn't really React's fault. Avoiding the things you mention is entirely possible when using React. It's all up to the developer to handle such scenarios, just as it was without React.
You can choose to have higher latency for the initial request and just display static HTML. Or if you want to load content on demand, then you do have to deal with what happens before anything loads, but I don't think that's the fault of React. Any framework which does this is going to have the same problem that needs to be solved.
Similarly to React "breaking" the back button. If you want user interaction without another page load, you have to deal with the consequences such as needing to track page history more explicitly than you might have otherwise. But that's because the dev chose to change the page content without moving to a new URL, not because that was implemented using React.
It's not possible to flash misinformation with normal front ends before React, without going to extreme extra effort to enable such misbehavior. Whereas with React, the easiest programming path is the user hostile path. And React is adopted only to make it "easier" on programmers.
Nothing about React specifically enables that kind of design.
Redux encourages loading data like that, and the easy way to use Router makes it easy to do that - all URLs get sent to the same backend view to render the app, then the frontend takes the URL args and triggers ajax to get the data. During that interim when the ajax is running is when you get this empty-data state.
For every consequent page transition the performance is actually slightly higher than a full page load since (a) you're probably only fetching JSON instead the entire resulting rendered HTML and (b) you don't have to load the app code any more.
jQuery, Backbone, Angular, etc.. You can / did do this in other frameworks prior to React.
I think, from reading your comments, you think client side routing and single page applications equals React. That's... an interesting take.
If my irrational hatred has a better target than the term "React" I would like to know it. I do despise the usability of nearly every SPA I have used. It is perhaps possible to program an SPA so that the deficiencies are not noticed, which is great, but that does not appear to be the norm nor is it made easy by SPA frameworks.
The flash of inconsistency you see is because the client eagerly modifies state before the server persists it (or some form of this problem).
The routing issue is because the application (SPA) is using business logic to control the browser's navigation state. Sometimes opening a modal will be a new push on to the nav stack so you can hit back, sometimes it isn't, sometimes they forget things, etc..
All of it though is just too much state being managed on the client by the application and that state being managed poorly. This isn't only related to React. It's always been possible to screw up with managing state in any framework.
Mission accomplished?
Either way, it's a lot of text that shows up in a consistently stylized and clean way, which is tough to achieve for something like an admin panel.
It's purely visual though. It's a great piece of software to get out of the box.
All joking aside, I like that the Django admin still looks the same after almost 20 years. Cannot begin to impart how much value that thing has provided me.
It being ugly is a feature. Don't fall for the temptation of giving non-devs access!
(But it could have kept it's look while still being more friendly to use, though. So many huge selects and difficulties to fill in valid data in some cases)
Only one rounded button?
I think there is Trader UI, and VC UI. Trader UI, built for wall st packs every bit of information into every pixel possible. VC UI has rounded corners, nice fonts, drop shadows and half the information on the screen. Django UI actually splits the difference nicely.
A more charitable way of putting it is, you can make a pretty presentation when you know the data that you are trying to present and the story you are trying to tell. I can't imagine a 3 column pricing table that wasn't done in bootstrap (Venture Capital UI)
Traders look at screens searching for meaning across a bunch of different data. They are trying to construct a story and as much context as possible is important.
The problem comes when VC UI is applied to a Trader problem where you want to see as much information as possible to understand, but there is padding, rounded corners and other stuff forcing you to scroll.
Look at this screenshot of a Bloomberg terminal
https://www.investopedia.com/thmb/trBFMDD8xeZkhLiLscngql3FV_...
Is it the shiniest UI? No, but a well configured Django admin is a power tool that stays out of your way.
Django Ninja is a breath of fresh air.
An aesthetically pleasing interface is a side effect of someone fluent in that language working hard to figure out how to communicate information, action, cause and effect, etc to the end user. It's not an easy language to learn, it's important even in relatively trivial cases, and developers trying to wing it are about as good at it as designers cargo-cult assembling PHP to modify a WordPress deployment: It might get the job done in a very basic way, but nobody should convince themselves it's a real solution. Just like a developer might look at their interface and say "read the docs" or "design is subjective," that designer might see how slow their 5-deep for looped set of database queries is and say "this server is too slow" or "why can't those damned developers make WordPress faster?"
I agree with what you say somewhat, but I believe about the massive difference between UI/UX. If I have to sign up to something for the first time or have to buy something, I want pretty pictures. If I have to work with something often (all day let's say), I want UX and I couldn't give a shite about UI; I want things easy to find, fast (not latency) etc. Combined would be great, but tell me what has that, because I always see one, never both done to perfection. If there is a 50/50 mix, it's usually annoying as hell on both sides.
My most productive interfaces are ugly as hell ; no animations, no overhead and everything crammed on a screen and very fast. I would never 'sign up' for an application like that seeing it first, but I would never use any application long term for productivity like most people say is 'beautiful' because it's inefficient.
Are they settings that Meta wants you to change?
There's bo difference. The GUIs have started rapidly going downhill right after some idiots decided they are different and the rest of idiots believed it to be true.
How can you have a UI without understanding how it functions and how it's used?
A/B testing isn't immune to being as broken as the UX in some of the gnarlier bits too. Perhaps some of the links that simply don't work on the Facebook mobile app are busy signalling that they get way more clicks than the one that successfully loaded the content...
Google's terrible at UX. I once spent about five full minutes figuring out how to navigate my dad's phone app on his Android phone, so I could help him use it, after an OS upgrade. There were some tabs that didn't look like tabs and didn't indicate which was active, turns out. He'd have had no hope of figuring it out on his own.
Once was helping my grandma add contacts in Gmail. She had failed repeatedly. Kept hitting "add contact" and it'd blank the form she was on, without adding the contact. This was because there were two same-color-and-weight add-contact buttons on the page, with the same copy, and one submitted the form, while the other gave you a blank contact form. You pretty much had to be familiar with how HTML nesting worked to have good shot at guessing which was the one you wanted, just by looking at it.
That second one's an older version of the UI, but holy shit it was bad. They definitely make mistakes, and really obvious ones at that. Money and "smart" doesn't mean shit.
Really though? Does your web browser interface look the same as your sms/messaging interface, look the same as your car's annoying infotainment interface, look the same as your mail client, look the same as this website, look the same as your search engine? Do all of those things really look the same as they did 10 years ago? We use so many interfaces that are subtly shifting and being improved that the ones that work well for right now don't even stick out to us, and that's part of the problem. If you don't really notice that you're using an interface and are entirely focused on solving the problem you need to solve with that tool, then that's probably a really well designed interface. It's probably so smooth and intuitive that it seems like designing it that way would be obvious, but it's really, really not.
> If I have to work with something often (all day let's say), I want UX and I couldn't give a shite about UI; I want things easy to find, fast (not latency) etc. Combined would be great, but tell me what has that, because I always see one, never both done to perfection. If there is a 50/50 mix, it's usually annoying as hell on both sides.
You don't have an particularly accurate understanding of these roles. If a UI doesn't let advanced users solve their problems efficiently, then it's a shitty UI. "Pretty Pictures" where not appropriate is bad UI design no matter how pretty it is and people who don't think so are visual designers (at best) trying (and failing) to be UI designers. A well designed UI is an effective UI. All of those pretty UI mockups you see on sites like Dirbbbbbbble and behance are nothing more than aesthetic explorations. There's no way you could even know if they were good or bad UIs because you don't know exactly what problems they were trying to solve, for whom, and in what context.
UX encompasses the entire experience. If you have a great UI but the world's shittiest email confirmation workflow, then you have a UX problem with a great UI. This misconception is why developers think adding the ability to select color themes in their application with a horrible UI will address UX problems-- which to any actual software designer is complete nonsense.
> My most productive interfaces are ugly as hell[...]
A couple I'm friends with had a broken kitchen faucet handle for ages-- it would just fall off unless you held it on while operating the faucet. Unfortunately, one of the necessary connector pieces was no longer available, so it wasn't a trivial fix. Once, when I was pet sitting their rabbits, I got so annoyed by the thing that I went home and made a wooden piece to fit in where the missing part went, and fixed it while they were still on vacation. It was supposed to be a surprise but I totally forgot about it, and a few months later my wife said to them "hey do you like having your kitchen faucet fixed?" They looked at her, perplexed, walked over to the kitchen faucet, tried to pull it off, and it obviously didn't come off. They were shocked! Why? Because they were so used to holding that damned handle on the faucet that it just became an part of their using that faucet.
So not to be flip, but, the sky is blue, water is wet, and technical people are tolerant of and used to using shitty interfaces. Open source user interfaces are almost exclusively used by technical people; there are a few exceptions like Firefox, but Firefox's interface is managed by a team of foundation-funded full-time professional designers, (actually they do a lot of really great open usability work.) One exception I can think of is Inkscape. Most open source interfaces are ...
It's not uncommon when starting a new project that I pick Django just to have Admin, and then ignore its usual views altogether.
If you want an admin wrapper around your database, you have better many modern alternatives (I use directus). If you want low code and easy platform, you have bubble.io. If you want an easy api for your database, you can use things like hasura. If you want python frameworks, try fastapi (its third party admin is great). If you want an orm, sqlalchemy gives you more bang for your buck.
Many of Django's third party packages are out of date. The data science python community has settled on Gradio.
The sweet spot of Django seems to have disappeared. Jobs for Django are lower paying, and often more high stress than .net or other languages.
Django has a great outreach with it's Django Girls, Afro-Django and Django Foundation. However I feel like it's technical side needs far more love, the source code needs some major refactoring and cleanup.
I thought about this indepth on whether to send my daughter to django girls, or just train her in .net and c# myself.
can you please expand upon this argument? you didn't really try to convince anybody.
This partially matches my experience.
I see Django mostly being used for prototypes, which then become "the monolith" that allows the company to grow to the point where smaller services - or dare I say "microservices" - are more appropriate. There are a couple of things that stand out to me about that use case, though.
First, Django allowed the company to build a product and grow its business to this point in the first place. Without Django, it would take significantly longer to build things. Early stage startups are all about implementation speed; they often end up building several iterations before finding traction. Django's "batteries included" approach means you end up with experienced developers who can very quickly build out a green field services with it. You also get a hiring pool of people who are able to come into a project and be productive very quickly, since the architecture is well-defined and shared by projects they've worked on in the past.
Second... monoliths rarely die. I've been doing this for almost twenty years now. I've been through multiple rewrites and initiatives to break up an existing monolith. They very rarely succeed. My recommended (and by far, my preference) approach is to impose an informal "new feature freeze" on the monolith, build out new functionality as new services using the most appropriate tool for each, and slowly shrink the monolith. Over time, as core features are maintained, they can be more cleanly separated conceptually from the rest of the monolith. Eventually you'll get to a point where it makes sense to split off some existing features into their own services... but you'll likely never get to the point where the monolith is actually gone. Once the tech debt is reduced to the point where reducing it further is no longer the most impactful thing you can be doing, it doesn't make sense to "finish". The result is that even very mature companies that were once startups end up still needing people to work on Django projects.
> It's third party ecosystem is basically dying (especially noticeable when compared to ruby on rails).
Is it?
Sure, there are fewer shiny new projects these days. If you only look at tech news, you might see fewer Django extensions and such being announced - but that doesn't mean the ecosystem is dying. It means that the ecosystem isn't rapidly growing. In this case, I'd argue that's because both Django itself and the ecosystem surrounding it are mature. There aren't a bunch of exciting new packages being released because the packages that we already have are working well enough that there isn't a need for more.
> Job hiring for Django is disappearing from the non startup arena, which is especially bad for career developers since you need a career pathway.
I'm ~40. I've been a professional developer for twenty years, and have worked for startups exclusively for ten years. I feel absolutely no need to "settle in" and specialize in a single framework. Or even a single language. While most of my experience is in Python, I've built (work) projects in Clojure/Clojurescript.
I've taken jobs where I'd never even encountered the stack they were using. I recall one interview in ~2018 where the job was leading a team refactoring a Scala monolith into microservices. The first of those were in were in Scala as well, but they were having trouble hiring. Very few candidates had Scala experience, and not many more were both capable of learning it quickly and interested in doing so. I literally searched for Scala examples in my Zoom interview, while sharing my screen. After skimming the Wikipedia page I confidently told them it wouldn't be a problem. They seemed shocked at that, and the rest of the interview was my collaborating with them on a minor ticket they were currently working on - I was able to s...
If it's able to survive other 3 or 5 years, I'd argue the pendulum will just swing back to the "django's way".
> If you want an admin wrapper around your database, you have better many modern alternatives (I use directus). If you want low code and easy platform, you have bubble.io. If you want an easy api for your database, you can use things like hasura. If you want python frameworks, try fastapi (its third party admin is great). If you want an orm, sqlalchemy gives you more bang for your buck.
And your requirements.txt or poetry.lock file grows and grows. The thing I really like about django is that I don't need any external packages to start. I have basically everything I need to start inside a single package and don't need to bother about how to integrate sqlalchemy with flask, how to add auth and authorization to my stack or how to check that all of my tens of dependencies are safe and regularly updated.
The only thing I really miss is something like LiveView. I know there's htmx and similar, but i hope they will be some "official way".
Having used Django on and off for ten years or so I don’t perceive the ecosystem to be dying–the last large project I worked on used dozens of third party Django plugins and only one or two were unmaintained, and even those had some active forks happening.
You’ve also entirely missed the point of Django admin. It is not your app. It is not your project. It’s intended as a crutch. The fact that it integrates with your ‘front-end’ code, in a way that a no-code platform popped in front of your database does not, is literally its main selling point.
I've worked in the industry for over 20 years now, skills are transferable only to a degree. If you are applying to a corporate job, the person with c#/.net has the edge over someone with the equivalent experience in python/django.
Developers hate admitting this, but tech stacks matter to your hiring potential. My daughter can learn teamwork and other skills from the billion other kid oriented groups, for programming skills I'm going to help her get the easiest best paying job.
Why would anyone want that? This sounds bland and boring.
If.
I spent seven years working a corporate job. My pay is higher today working for startups than it would have been if I'd climbed the corporate ladder. I've had a couple of windfalls in that time: a ~$50k payout when an investment round occurred prior to an IPO, and a ~$125k payout when that IPO happened after I left. If I had joined that company earlier, more aggressively exercised my RSOs when I had them, or had stayed until the IPO occurred, I would have seen a ~$1.5m profit. I learned from that, and now choose my employer based on my estimation of their chances at a successful exit in the time period I want to commit to the company. For me, that means choosing earlier-stage companies where I can accumulate more equity. A happy side effect of that is that I have a much larger relative impact on the company's direction, which keeps me interested and engaged in their success.
In other words... I have no interest in a corporate job. I know I'm far from alone in that.
Broadly speaking, corporate jobs offer a higher salary relative to startup jobs.
This is by design. Being engineer #0 at a startup is far less stable (i.e. riskier) than being engineer #65535 at BigCorp. The salary is somewhat lower because the company simply doesn't have the cashflow to pay more. Startups have one thing to offer employees to offset that lack of stability and lower salary: equity.
The vast majority of the time, that equity ends up being worthless. Every once in a while, it becomes worth a life-changing amount of money. It's not fair to say that Django jobs pay less. Those types of jobs are an opportunity to trade a portion of your earning potential for a few years for a chance at a much larger prize.
I don't have numbers in front of me to be able to prove it, but I'm of the opinion that when you include this in your calculations, the expected value of your labor is higher working for startups than at large, established companies. While the chance of any given startup succeeding is relatively low, it's not unreasonable to think you'll be able to join up to a dozen or so over the course of your career. The chance of _one_ of those having a successful exit is high enough that I've staked a big part of my financial future on it happening.
Very easy to get started though, and even comes with stuff like cron jobs and email sending triggers built in and able to use in super simple manner https://pocketbase.io/docs/js-jobs-scheduling/
according to his benchmark you can serve 10,000 realtime connections on a 4 dollar a month server https://pocketbase.io/faq.
my basic deployment was just rsyncing my pocketbase folder into my vps and creating a systemd service. i'm now adding some github actions and docker files but it might not be necessary https://www.programonaut.com/pocketbase-as-a-framework-deplo...
My perspective is that we have a new generation of Django devs among us, who grew up using fancy JS frameworks, SaaS dashboards, A.I.-assisted code tools, etc. So for a newcomer seeing the Django admin for the first time, it's a bit different.
My goal of the article was to capture the tribal knowledge that seems to have not gotten passed down to this new generation.
You don’t just submit a pull request called “Redesign”. The with is more political and organizational in nature
Not sure if English is your native language, but quotation marks usually land on the outside of any other punctuation. (Yes, it does look goofy.)
Now, the quote above is kind of special because you have a portion of it quoted within a statement. However, if you are paraphrasing all but the "ugly" part. In that case, I would drop the outer quotations marks.
> why is the Django admin so "ugly?"
Bring on the downvotes.
Question marks are a little different. If the question mark is part of the quote, place it inside the quotation marks. If the question mark is not part of the quote, and instead the quote is part of a question, place it outside of the quotation marks. This rule also applies to exclamation points.
- https://www.grammarly.com/blog/quotation-marks/
Place a question mark or exclamation point within closing quotation marks if the punctuation applies to the quotation itself. Place the punctuation outside the closing quotation marks if the punctuation applies to the whole sentence.
- https://owl.purdue.edu/owl/general_writing/punctuation/quota...
Different varieties and styles of English have different conventions regarding whether terminal punctuation should be written inside or outside the quotation marks. North American printing usually puts full stops and commas (but not colons, semicolons, exclamation or question marks) inside the closing quotation mark, whether it is part of the original quoted material or not.[14][15] Styles elsewhere vary widely and have different rationales for placing it inside or outside, often a matter of house style.
- https://en.wikipedia.org/wiki/Quotation_mark
One of the eye openers for me personally was the realization that the Mastodon organization contracted a UX engineer firm. It shows.