> I hope we get monthly or at least quarterly Ladybird Newsletter just to keep the attention of the project along with attracting those who still dont know.
I've heard people complain about Django many time on HN. I started using it back in the 0.96 version, so maybe its just a familiarity thing.
But I built 3 large successful applications in it in that time. I loved it. I don't use it regularly anymore since I mostly moved away from webdev, but I recently came back into contact with my largest project I build in 2018/2019 and its been running perfect this whole time and was a pleasure to dive back into.
Django just felt logically organized, documentation was on point, core was very readable (at least then).
I always just felt so productive in it. I know everyone has different opinions, experiences and products they are building, but I'm always surprised with the negative comments. I definitely prefer SSR with its reasonable though, so maybe thats part of it.
tbf it was borderline unusable until they added async DB query support in 4.1 (2022) - before that you had to wrap every DB query with sync_to_async, async_to_sync and it generated too much boilerplate code..., and even in 4.1 the DB queries themselves were still sync/blocking, not truly async because at that point they didn't yet rewrite their database "backends" to use async querying, and I believe that as of now the Django's DB engine still doesn't support natively async DB queries/cursors/transactions/...
Also, lots of the "batteries included" into Django don't have async interfaces yet.., for example the default auth/permission system will get async functions like acreate_user, aauthenticate, ahas_perm only in 5.2 which is expected in April 2025, so as of now these still have to be wrapped in sync_to_async wrappers to work...
My complaint with Django is/was that it's fantastic for building brand new apps starting from scratch, but less pleasure to integrate with existing databases. The last time I tried to add Django models to a DB we were already using, there was an impedance mismatch which made it hard to fully model, and I gave up trying to get the admin to work well with it. The ORM and admin are 2 of Django's biggest draws, perhaps the biggest. Without them, it's not so pleasant.
That's when I first came to love Flask. SQLAlchemy will let you model just about anything that looks vaguely database-like, and Flask doesn't really care what ORM (if any) you use.
TL;DR Django's opinionated. If those opinions match what you're trying to do and you can stay on the golden path, it's freaking great! Once you get off in the weeds, it quickly becomes your enemy.
> If those opinions match what you're trying to do and you can stay on the golden path, it's freaking great!
That's a great summary. I wrote a few significant flask apps many years ago as well and I'm a huge fan of SQLAlchemy. My flask apps were greenfield so I ended up building crappier versions of alot that Django provides. I still enjoyed it but I wasn't as productive. But with a legacy integration, it would be hard to beat SQLAlchemy (I think its great for greenfield too). I've basically landed on your comment above as well.
Sure but would they? Currently they get it totally for free. If they had to finance the development themselves then it would get real hard to justify real quick. $20bn is a lot of money even for Apple
It's not about whether or not Apple have the resources to make their own browser engine, it's about whether it makes sense from a business point of view to make their own browser engine. Currently it does, because Google pay them huge amounts of money to do so. But what business case would there be to pay that $20bn themselves if Google did not fund them? Would it be worth that just to avoid Chromium?
Tbf - they don't pay for WebKit, they pay to be the default search engine. If Apple wanted, they could switch to Chromium and still have the same captive audience and bargaining power (but a lot less control of the direction web standards go)
That’s not necessarily true, even Microsoft has its own tweaks of Chromium:
> We’ve seen Edge adding some privacy enhancements to Chromium pioneered by Safari. Edge shipped those, but Chrome did not. And as more browsers start using Chromium and large companies will work on improving Chromium, more of these disagreements will happen. It will be interesting to see what happens.
Just because a browser is based on Chromium, that does not mean it is identical to Chrome and that Google is in control. Even if the unthinkable happens and Apple is forced to adopt Chromium, that will only ensure that Google is not the only one having a say about Chromium and the future of the web.
Fwiw, I agree its problematic to lock down phones the way Apple does. I won't use them because I'm not buying a device where I don't get to decide what runs on it.
And for sure they would put their twist on Chromium, like Edge or Brave or Vivaldi.
I still think they have a lot more control the way it is now, for better or worse
This is insipid. Why would Apple adopt a fork of WebKit when they’ve been using WebKit just fine for so long? Why would Apple of all companies defer to something in Google’s realm besides search? Do you have a single technical justification for Apple to overturn decades of WebKit use that’s baked into its frameworks and its control over iOS to use Blink?
IE was too long in the tooth, Microsoft was behind by several trends at that point, mobile being one of them. Don’t think the situation with Safari and WebKit is comparable.
As a small correction that somewhat matters to this hypothetical, Microsoft had already moved away from Internet Explorer/Trident to Microsoft Edge/EdgeHTML. It was quite competitive and modern already.
So, they did not "move away from IE to catch up". They "dropped the Edge engine in favour of Blink (Chromium)". It feels very much like Microsoft just did not want to compete on the engine (run-to-stand-still) but rather just on the feature set. Who can blame them?
If you think about why Microsoft really switched, I think it is a fair question why Apple would not just do the same thing. I mean, as long as WebKit is the only engine allowed on iOS, it makes sense for them to control it. But as regulators force them to open that up, and perhaps put an end to the Google gravy-train, I think it is a fair question why Apple would spend that much money on a web engine when they do not have to.
You cannot fall behind the competition using Chromium as a base, because they are all using it too! It is the ultimate in safe corporate options.
While the Apple-Google rivalry seems to have waned compared to a decade ago, I just don’t see Apple completely capitulating their platform/browser engine like Microsoft did.
Not to mention even if Apple switched to Chromium, they’d just end up taking over that engine, even forking it later down the road:
> We can only imagine what would have happened if Chrome kept using WebKit. We probably ended up with a WebKit-monoculture. Trident is dead, and so is EdgeHTML. Presto is long gone. Only Gecko is left, and frankly speaking, I will be surprised to see it regain its former glory.
But Chrome did fork, and today, we can also see similar things happen in Chromium. I don’t expect somebody to fork Chromium, but it could happen.
We’ve seen Edge adding some privacy enhancements to Chromium pioneered by Safari. Edge shipped those, but Chrome did not. And as more browsers start using Chromium and large companies will work on improving Chromium, more of these disagreements will happen. It will be interesting to see what happens.
Just because a browser is based on Chromium, that does not mean it is identical to Chrome and that Google is in control. Even if the unthinkable happens and Apple is forced to adopt Chromium, that will only ensure that Google is not the only one having a say about Chromium and the future of the web.
And that is what is crucial here. The choice between rendering engines isn’t about code. It isn’t about the rendering engine itself and the features it supports or its bugs. Everything is about who controls the web.
There are plenty of scenarios which can be discussed in detail which have no possibility of coming to pass. Zombie apocalypse fiction, for instance.
I never had any beef against Ladybird. To bring this conversation to full circle, I merely clarified there are at least a few other promising new indie browsers that don’t use Chromium. In the event that Apple does abandon WebKit- which wouldn’t mean the termination of the project anyway!- I would simply use one of those alternative browsers.
Edit: while we are on the subject of wild hypotheticals, there’s also the DOJ suggesting Google split off Chrome into its own company for antitrust.
Safari is now the browser that is lagging the most behind. And it has not gotten better recently either.
Apple even got into "AI", so I would not put it beyond them to kill a browser team.
As per my reply to the sibling comment, I don’t think Apple is anywhere near to the capitulation that Microsoft was when it came to abandoning their browser engine.
Can you elaborate? I’ve been using it for over 10 years and it might just be my favorite piece of software. It’s central to all development I do.
I use many features of git that I probably wouldn’t otherwise due to having to remember flags and copying around hashes. It also makes discovering git functionality very easy.
Looking at OpenSSH tells a different story. It is a massive, overly configurable behemoth. The 'WireGuard of SSH' would be 1% of the LOC. It would not provide password auth, or let you log in as root with password auth, or let you use old insecure ciphers.
Maybe OpenBSD itself is better at sticking to these principles than OpenSSH. I haven't used (experimented with) it for ~5 years but read about various updates every so often.
> Normal OpenSSH development produces a very small, secure, and easy to maintain version for the OpenBSD project. The OpenSSH Portability Team takes that pure version and adds portability code so that OpenSSH can run on many other operating systems.
Unless you actually run OpenBSD, what you think is "OpenSSH" is in fact "OpenSSH Portable Release". These are very different things.
Here is a list of OSes[0]. Where do you draw the line on supporting these? Should every new project try to support all of these? Do you, doublerabbit, get to decide which OSes are important enough for support?
Or do you think the person who created the project and does all the work should be able to decide where to spend their free time?
Where those are still in active development. Where those exist you should attempt at least for. It's partly why they failed in the first place.
> Should every new project try to support all of these?
As said above, attempt. My projects in Perl work most places, my TCL programs do too. C and C++ all have been universes. Heck even Python.
It's only new fangled languages like Rust and Go that make an ball ache.
> Do you, doublerabbit, get to decide which OSes are important enough for support?
Yeah why not, at least allowed to voice an opinion. I'm so sick and tired seeing the world of IT on repeat. See it get abused, capitalised and freedom sucked from it. I give Linux five more years before it will be smothered in corporate.
After working as an sysadmin from the age of 13, to 35. I wish I could call done but other opportunities are not feasible at this time. The amount of bug reports I've submitted across the board is more than a dozen. Hand crafted brittle configuration files, been there done that. This isn't just me being edgy.
For more the past twenty years we've only dominated one bloody OS. Only then do we all bitch at each other because of fanboi or whatever cliche is at the moment. Systemd comes to mind.
I am so bored of the neo-Linux crowd and I've been working with it for it since 2.x kernel.
Only when you jump off the bandwagon do you see how clunky it really is.
First HN was shouting at me how a new browser could never be made and now HN is jumping up and down because one has yet won't acknowledge that other OS exist and that I personally feel developers should catered for.
> C and C++ all have been universes. Heck even Python.
> It's only new fangled languages like Rust and Go that make an ball ache.
is not even remotely accurate. The whole idea of the Rust and Go standard libraries is to abstract platform differences away, and in cases where they're unavoidable, to make them impossible to ignore. Python, by comparison, handles them badly. It does certified Bad Things like making POSIX operations silent no-ops on non-POSIX platforms. C doesn't even try. Any cross-platform C program is an #ifdef minefield, and you'll only find out whether it works on a given platform when you try to compile it and start getting obscure library header errors.
Just answering for myself, but it's because I like the programming/engine aspects. Not the creative aspects of the art/music/level-design/rules/balance/etc. I can use an existing games art/content and just focus on the part I like.
