At least it wasn't acquired Fung Wah. Their busses would routinely break down or even catch fire but what would you expect at $10 for a ride from Boston to NY.
That's one of the teachings of feminist privacy classes, that the biggest threats are usually very close to you, such as a jealous lover setting up spyware on your phone to track your movements.
I don't know Phoenix enough to make a fair comparison, but I'd say it have major features Django doesn't have (like LiveView), but the opposite is probably true.
But as soon as you go to the JS world, you won't find any full-featured framework like Django or Rails. The Django's philosophy is that all components are built by Django team itself whereas in the JS world, existing frameworks tend to gather independent components and define conventions to make them work together in an elegant way, which is very different.
I just wanted to provide an alternate viewpoint; I also switched from Django to Rails, but much preferred Django. In my opinion the documentation is much better (the Rails documentation sites drive me bananas daily for both reasons of their content and UIs) and I very much appreciate the slow pace of changes to the framework.
I’m not disagreeing with you at all (as you’re expressing your valid opinion!) but wanted to leave a note to say Django is still great and still preferred for many of us. I also agree with you that it’s probably not worth switching if you’re already on one framework or the other; they both have their strengths and good communities.
I'd argue it's not the same thing. Bike-shedding happens over trivial, subjective things where any opinion is as valid, and hard to rebuke because of the subjectivity.
When it comes to arguing over large projects, the difficulty to rebuke comes not from subjectivity, or trivial-ism, but from the project being so complex there are few with the context/experience who can properly compare the two.
There is tons of subjectivity in software development; people can't even agree when types are better than duck typing and vice versa. Even if there is some definite answer to all these questions we are not all ever going to agree on it in big numbers, so yes I think language framework wars can be called bikeshedding in most cases. Especially considering comparing Rails and Django is comparing two very very robust, "old" and proven solutions with about equal performance and feature set. Even the syntax is pretty similar. If one is objectively "better" it's not gonna be by much. It's not gonna matter at all to your average project which one you choose.
Here’s my subjective suggestion and a list of things I like about it in no particular order:
As someone who has used Django, Rails, and Node, I’d recommend Elixir and Phoenix. Elixir has excellent tooling and dependency management, is functional and therefore easier to write concurrent applications with, it stores threads in private memory and uses the actor model for interprocess communications, and since it is truly concurrent, it is much more scalable than the other options I just mentioned.
Phoenix is a flexible, clean, and easy to use framework with very little, if any, magic. LiveView lets you create things like SPAs, without the use of a front-end JS framework, using standard message passing. Phoenix is also scalable as hell.
One of my favorite things about Elixir and Phoenix is the ability to handle issues in a very atomic way. If you compare an Elixir cluster with a Kubernetes cluster, Elixir is able to handle an issue with tweezers where Kubernetes would handle the same issue with a bulldozer.
Phoenix/Elixir is so niche I don't know how you can put it in the same line as Django/Rails/Node. There are major consquences to picking something so niche most companies will not go along no matter how awesome the tech is.
Niche? Maybe in some areas. There are at least 10 companies using Elixir within biking distance of my house. I've been working with Elixir professionally for six years and have never had an issue getting a job or hiring people. Things may be different in your area.
Yes, niche, as in not in the top 50 in Tiobe index, as in less than 25k people on the Elixir subreddit, as in around 1000 jobs in the whole of the U.S which is a fraction of the popular stacks.
Niche. No matter which measurement I go with Elixir isn't anywhere near the top 20. The third one (spectrum) is actually a combination of 11 measurement metrics, so before you yell at me that Elixir devs don't use Stackoverflow - Elixir isn't niche only on Stackoverflow. It's just niche, period.
I don't think this question is answerable so abstractly. It really depends what you're trying to build and what the technical constraints are.
There are so many architectures, API approaches, frameworks, and languages these days. Almost any one could be argued as being better or worse off of different criteria.
Also Django being batteries included makes most comparisons very apples to oranges. Even comparing a basic CRUD web app / API in Django + DRF to Flask means pulling in like a dozen packages to help vs just the one with Django.
In the world of Python web frameworks specifically, FastAPI is really nice these days for a lot of REST API type use cases.
You beat me to this exact reply: as "dead" frameworks go, getting real work done for real tangible value rocks, with Django, with Plone. I can't wait for the follow-up post explaining why FastAPI is dying, make tiangolo proud! ;-)
I really like the Genshi templating language, which TurboGears uses by default. Genshi is a descendent of the Kid templating language, but it uses a (debuggable) streams-based api instead of compiling templates to (undebuggable) Python code. You can use Genshi with Django, of course.
I like the templating languages that remain valid HTML. It makes it much easier to integrate with other tools like HTML formatters or HTML plugins for JavaScript bundlers.
The beauty of Genshi is that its templates are pure clean valid standard XML, so it interoperates perfectly with all XML tools, and it has independent serializers for all the dirty quirky variants of HTML. So you can render your templates in XHTML, or any other version of HTML you want, and edit and process templates with off-the-shelf XML tools, that don't need to know about any special non-standard syntax.
Templating languages that use almost-but-not-quite-entirely-unlike-XML or -HTML don't work well with standard XML and HTML tools, because they don't recognize XML-or-HTML-with-some-magic-non-standard-syntax-sombody-nailed-on-to-the-side.
I second FastAPI! In my mind it's, "Flask, but better." The killer feature in my mind is that it leverages type hinting and dataclasses, using Pydantic, to take away a lot of the grindyy, boilerplate parts of writing an API, like type checking, dependency injection, generating good error messages, generating API documentation, ...
Even when I'm not using FastAPI now, I use Pydantic everywhere. Types in Python, while not nearly as useful as in a strongly typed language, are a dream come true.
And Docker secrets! It's also pretty easy to rig them up with YAML files! BaseSettings is amazing.
The only gripe I have with Pydantic is that sometimes it has really opinionated type coercion that can get you in trouble sometimes. For instance, `Union[int, float]` will accept either an int or a float, sure, but it will always output an int. This isn't difficult to fix but may only realize it after having shot yourself in the foot.
Either is good if what you are building is something small and very focused or if you already know exactly what you want to build and want to have freedom making decisions about most aspects of the application.
But if you don't know yet what the product will be, a battery included framework like Django is very nice to get out the door quickly without having to worry too much how to structure the code, what library to use for x, etc.
To be fair, I'm familiar with Flask and (some) of its complimentary modules. FastAPI has a lot of buzz right now, but it's also fairly new - I'll probably experiment with it first.
Also, I think that Django is a good choice over Flask if you've never done anything in flask. But if you have an existing Flask site that can serve as a skeleton, I think it's just as good as Django as a starting point; details such as code structure and common library choice is then already handles - in fact just following https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial... will get you a lot of this too; Do you have any other batteries in mind? Ialso see Django having plenty "gotchas" (although it maybe have changed since I last used it). I definitely much prefer SQLAlchemy over DjangoORM.
I agree. Maybe a was bit unclear. I think the nice thing about micro frameworks like Flask is that you can build your own Django. Or your own whatever it is you need.
But you need to spent at least once quite significant time following mega-tutorials, thinking about how to structure your application, what libraries to use for x, how to integrate them etc.
If you do that, it's great. But what I have seen in practice in various large flask app developed over years is, that in the very beginning people just jump in hacking away because it is so simple, just an app.py and a requirements.txt. Then over time they slap on the same thing Django has, but in a much less robust, hard to maintainable way. I'm guilty of the same, often simply not having time due to reality to really think things trough (the mega tutorial and similar didn't exist when I last started a Flask app).
If you're trying to write an api, yes absolutely it is more suitable.
If you're trying to write a CRUD app with a lot of admin screens, no, unless you're happy to roll your own auth, admin screens, mailer etc. (I use Go for building web apps like this and am very happy with it, but it's definitely more work thank something like Django or Rails).
It's just really pragmatic about the upsides of functional programming. It describes itself as "functional-first", but isn't afraid to fall back on OOP in situations where OOP really does model the situation better.
In my mind, it's taken the easiest 80% of the features of a true functional language, but then picked a pragmatic point at which to stop; the result is a language which is easy to learn and also makes it easy to use "most" of the good things you want from a functional language.
It is a mechanism to provide type safe access to structured data and data services with almost no code. It feels like magic.
Like other ML-derived languages (F# is an OCaml dialect) it has algebraic data types and pattern matching to make code simple and complete without missing edge cases.
Also, it is arguably the best functional language on .NET, so it has a great platform with a large ecosystem to build on. And the tooling is great (Jetbrains, Microsoft IDEs).
I haven't done as much as I would like with them, but I feel like until someone tries type providers they don't get just how powerful they are. Being able to point to an example .csv file and have it generate the classes for you, and update them if you change said format, in a way that it ensures the types still work, is amazing. And you can do it for ANYTHING as long as you have a way to extract the data to feed it to the compiler.
I still need to learn how to write a type provider just so I can.
> it is arguably the best functional language on .NET,
it is also the only real one. On .NET we have C#, C++ and vb.net then there are some other fringe langs like IronPython or IronRuby and I think there is a PHP one too.
For me is that pratically every time, if compile, it works.
It's really easy to express a domain (with discriminated union and type) and the defaults (immutability, option, removal of boilerplate, high order function to manipulate data, structural comparison not reference) allow me to write correct code, who is readable without too much friction.
Support a repl as first class, so that works too if you like repl driven development
Well, they might be able to use some of that infinite money to build a chip factory of their own. However, it would take years to become online, so the situation is likely to be resolved until that anyway. And it would be very expensive indeed, as it seems to be extremely difficult and expensive even for companies that already are in the semi business, such as Intel.
