10 ms·

Notes from building a blog in Django

214 points by theptip 3y ago

turbobooster 3y ago
[dead]
clivestaples 3y ago
This is great and I love the simplicity and speed (of page load and development). Curious, I ran it through Lighthouse and received a performance score of 100. By way of comparison, some of the more notable blogs on cloud edge were consistently between 60-80. Just checking my perceptions.
danpalmer 3y ago
For building CRUD web apps Django and Rails are truly in a league of their own[^1]. Many frameworks try to be good at this but finish development at a level of abstraction below these frameworks, leaving the last level to a plugin ecosystem that requires so much more work to wrangle into a fully working web app (see: Flask and its modern successors in Python). Other systems come at this from the opposite end, trying to be low-code or less-code, like headless CMSs or static site generators. The problem at that end always seems to be a lack of flexibility and over-reliance on proprietary systems or SaaS products. Django is just Python. Rails is just Ruby. There's nothing special to them and extending when necessary is often trivial, particularly because they have such mature extension points. There's a lot of criticism that can be levelled at these ecosystems for not keeping up with whatever the hype of the year is, or failing to "scale" in various ways, but damn do they get you a very long way with very little work. [^1]: Phoenix may be just about in this category, I don't have personal experience with it though, just going on the fact it seems to be very Rails inspired.
- deleted 3y ago
  [deleted]
- deaddodo 3y ago
  > Django is just Python. Rails is just Ruby. There's nothing special to them and extending when necessary is often trivial, particularly because they have such mature extension points. Eh, I wouldn't agree with that. Both Django and Rails extend the languages quite a bit with deep class overloading, reflection and fluidic approaches. Especially Rails, which pushes Ruby's DSL-like abilities to an extreme. If you go from learning RoR to then having to make a standard Ruby script, you quickly realize how much of what you built relied on Rails-specific functionality. Django, more or less, is just Python with a bunch of logic built for you, relative to that.
- Daishiman 3y ago
  As someone who's been using Django for the past 12 years in apps big and small, it blows my mind the trends towards microframeworks and minimalist frameworks that are objectively less productive in pretty much every metric. Sometimes it feel like a minor superpower in just how much more productive it is over pretty much everything, especially in the early stages of development. Even later on things like working auth and permission systems and API frameworks are huge timesavers. Proof that we are a fad-driven industry.
  - mordae 3y ago
    And in exchange for a free auth system and a automatically generated basic admin interface you gain: - inability to use static type checker without writing most of the annotations yourself - half jinja2 functionality - ORM that makes it impossible to get your query count down to a manageable level - 3rd party modules that break the types even more I am lobbying for moving to FastAPI with Jinja2 and SQLAlchemy. We write our admins in Vue anyway.
    - simonw 3y ago
      I've not seen another ORM with tools as powerful as Django's select_related() and prefetch_related() when it comes to addressing the N+1 query problem, but maybe I haven't been looking hard enough. Jinja2 is a supported template backend for Django these days: https://docs.djangoproject.com/en/4.2/topics/templates/#django.template.backends.jinja2.Jinja2 https://docs.djangoproject.com/en/4.2/topics/templates/#djan...
    - selcuka 3y ago
      I believe these complaints may be caused by lack of experience with Django: - There is nothing wrong with the ORM, you may be resorting to using deferred attributes too much. There are ways to eliminate them (select_related, prefetch_related) if you are having performance issues. - Jinja2 has been a supported templating engine for years. - I don't understand the question about static type checking. Can you elaborate?
    - danpalmer 3y ago
      > We write our admins in Vue anyway And with Django you often don't need to write anything. You're right to some extent with all of your points (jinja2 is available, not default, ORM is equivalent to SQLA most but not all of the time), but they're one side of the trade-off. The other is that you're writing admin views that you likely wouldn't need to with Django. It's not perfect for everything, but it is much faster to write with than anything else for reasons like this.
- EdwardDiego 3y ago
  Django is Python, but very heavily leans on Python's metaprogramming, which can make things complicated to understand.
D13Fd 3y ago
If you want a more "out of the box" solution, you can run Wagtail and Puput on top of Django. The Puput default template is a bit dated, but it's pretty easy to update and tweak to your preferences.
WD-42 3y ago
This is how simple Django is for CRUD apps. The author could go even sparser. Love them or hate them, the views could have been replaced with class based model views for even less lines of code.
- theptip 3y ago
  Fewer lines of code, perhaps, but in terms of explicitness, clarity, and ease of maintainability I find myself strongly favoring the functional approach for this case.
- izak30 3y ago
  Just for kicks I ran `git log | grep "Author: Simon" -C 20 | tail -n 50` ``` commit 53eddd4a0f8786e23f511a653d8d7ffa947ad8db Author: Simon Willison <simon@simonwillison.net> Date: Mon Apr 23 21:24:41 2007 +0000 Added HTTP_HOST example header git-svn-id: http://code.djangoproject.com/svn/django/trunk@5063 bcc190cf-cafb-0310-a4f2-bffc1f526a37 ``` There are earlier references as well, but I think the author was making pretty deliberate choices.
  - deleted 3y ago
    [deleted]
  - toyg 3y ago
    Yes, Simon Willison was part of the Django core development team very early on, when he was ungodly young. Absurdly talented guy.
dabeeeenster 3y ago
Be interested to know how/where it's deployed!
- simonw 3y ago
  It's running here, hosted by https://fly.io https://fly.io - https://www.datasette.cloud/blog/ https://www.datasette.cloud/blog/
  - 0xDEF 3y ago
    Does Datasette Cloud also run on Fly.io? How is Fly.io stability nowadays?
    - simonw 3y ago
      Yes, it does. Each Datasette Cloud user gets their own dedicated container, run using Fly Machines. The core Django app manages SSO and team creation, then calls Fly APIs to create volumes and machines for each team. I'll be writing this up in a lot more detail soon. I'm finding stability on Fly is excellent for my deployed containers. The problems I've seen are more around deployment - occasionally there will be incidents where fresh deploys can't go out for a few hours, all of which are reflected on https://status.flyio.net/ https://status.flyio.net/
davepeck 3y ago
This is great and showcases Django's talent for basic CRUD apps with handy admin interfaces. One catch: I like to deploy static sites to GitHub Pages. It turns out the Django ecosystem has an answer for that in the form of Django Distill [1]. Distill adds a new management command that generates static content by repeatedly invoking your views. I've used Distill to build quite a few static sites. It's great to be able to deploy to Pages but use Django's admin UI locally. Typically, for these sites, I check in my 'production' SQLite database directly to my git repo. (Combine this pattern with GitHub actions and you can do a lot with a little. For instance, here's a toy I built to summarize upcoming Seattle city council meetings [2].) [1] https://github.com/meeb/django-distill https://github.com/meeb/django-distill [2] https://scc.frontseat.org/ https://scc.frontseat.org/ -- source at https://github.com/front-seat/engage https://github.com/front-seat/engage
- deaddodo 3y ago
  I say this as someone that does like Django. I had the opposite opinion. If you were trying to convert Rails, Laravel or CakePHP users, this would just convince them that Django was more manual and involved than those frameworks. It would be better to utilize extensions like `scaffolding` to give a more equivalent workflow. It does demonstrate general MVC benefits and architecture, however.
- reidjs 3y ago
  Your links may be broken I was recently looking for a static site generator for a local relay race I help organize and django-distill was the top of my list. I ended up writing my own SSG because I had very little HTML that actually had to be generated on the site. But might check out django-distill in the future if you found it worth learning.
- lylejantzi3rd 3y ago
  Can you think of a complicated app that utilizes Django to its fullest extent? I'm trying to get a better view of what Django is capable of and I find it's helpful to see both the simplest example possible and the most complicated example possible. "Design for the extremes" as Don Norman would say.
gv83 3y ago
god i love django. it could use a little bit of modernization and modularization to ease the json api and deploy pain points, but it's still the best python web framework by a long shot and it would be deserving of way more manpower than it has. but emoji laden docs and 500/month patreon pay better than contributing to established things i guess
- eYrKEC2 3y ago
  With regard to JSON API aspects of Django, have you used https://www.django-rest-framework.org/ https://www.django-rest-framework.org/ on top of Django? I find it to be very satisfactory.
  - tfeldmann 3y ago
    Django-Ninja is fantastic and based on pydantic.
    - winrid 3y ago
      This. I found DRF gets very confusing with all the abstraction for complicated stuff. For simple APIs, it's very nice (I used it on govscent.org). SidewaysData uses Ninja and I love it so far.
      - gv83 3y ago
        DRF becomes hard to understand when you use magical stuff like class based controllers and so on. stick to functions and it's actually very simple!
        winrid 3y ago
        You're absolutely right - however I did not even know I could use functions. I didn't see that in the docs somehow. Also I think I remember with DRF I had trouble generating a good openapi client. With ninja it works really well.
    - 3y ago
sneak 3y ago
It's really not a good idea to use dynamically generated pages to run a blog. There's a reason static site generators exist. This should be made clear that this is just a toy/example app to demonstrate Django, not something someone should actually use. Generating the pages on each request is madness, and is why Wordpress in the default configuration (without WP Total Cache, which allows the httpd to bypass Wordpress entirely for most requests) falls over as soon as it's linked from any media site. Let's stop repeating these engineering mistakes in language after language. Compile your blog to static pages and deploy those. Hugo, Jekyll, and a million others await you, as well as CF Pages, S3, GitHub Pages, Netlify, and others.
- simonw 3y ago
  If you're worried about traffic spikes, stick your site behind a caching proxy like Varnish or Cloudflare. My main blog https://simonwillison.net/ https://simonwillison.net/ runs as a Django+PostgreSQL app on Heroku behind Cloudflare, with a 15m cache TTL for every page. This works perfectly. I survived a surprise Elon Musk tweet a few months ago which the server didn't even notice, because Cloudflare absorbed all the traffic: https://simonwillison.net/2023/Feb/17/analytics/ https://simonwillison.net/2023/Feb/17/analytics/
  - frankwiles 3y ago
    Same, a bit of caching and the REVSYS blog survived being on the front page of Slashdot (back when that was a thing), Reddit and HN all at the same time. No Elon tweet for sure, but caching like Varnish, Cloudflare, Fastly etc go a LONG way.
- lyjia 3y ago
  There are other ways one can cache dynamic blog pages, like with CLoudflare. Some frameworks will automatically cache database calls as well, like with Rails.
- AdamCraven 3y ago
  As someone who uses a mixture (django, Hugo), I say it’s fine use dynamic sites to run a blog - there’s millions of them out there. They are usually easier to administer for less professional users, as well as being able to quickly modify from standard web interfaces. If it’s backed by a cache like redis it’ll easily handle Hackernews level traffic, even at very short cache times.
stuckinhell 3y ago
I wouldn't recommend people use anything that requires a database for a blog in 2023. Edit: Since I got extremely downvoted for this comment. Here is why: You should use static site generators for new blogs in 2023. Performance: Static sites typically load faster than database-driven ones. Security: Without a database, the risk of SQL injection attacks is eliminated. Scalability: Static sites can handle high traffic without complex hosting solutions. Maintenance: No database means fewer maintenance tasks and potential failures. Hosting and Costs: Static sites often have cheaper and more flexible hosting options. Decoupled Architecture: Modern trends prefer separating frontend and backend, reducing the need for databases. Development Simplicity: Static site generators offer a straightforward content writing environment. Backup and Portability: Static sites are easier to backup and migrate. Edge Hosting: Static sites benefit from faster load times with distributed hosting solutions.
- Mimmy 3y ago
  for people disagreeing with this comment, mind elaborating?
  - smarx007 3y ago
    I think 800+ million Wordpress blogs are not planning to shut down in 2023 after reading GP's comment.
    - Cyphase 3y ago
      I don't think there are 800+ million WordPress blogs. WordPress is used for lots and lots of websites that are not blogs at all.
      - smarx007 3y ago
        Thank you, I stand corrected, 800M+ WordPress installations.
    - Heloseaa 3y ago
      This doesn't provide a counterpoint to the original comment's point. IMHO, it's true that a static site generator should be the way to go in 2023, instead of using a web framework with a db. I am personally running a hugo blog, on netlify, with netlify CMS. I have 0 costs, great performances, everything needed out of the box. What else to ask for ?
sc68cal 3y ago
I have been using Django for 10 years and it still is my tool of choice when I need to build something quickly that needs a full HTML and form handling interface. There is an excellent tool - https://djangobuilder.io/ https://djangobuilder.io/ that can also really speed up the boilerplate even more.
BiteCode_dev 3y ago
While this is a good example of all the good stuff raw django brings to the table, if you build a blog with django, you should go for wagtail in 2023: https://wagtail.org https://wagtail.org - It's incredibly more productive. - Seamlessly integrates with any django website, or hold your hand to create one from scratch. - Play nice with the whole django ecosystem. - Is easy to pick up because under the hood "it's just django". It uses django models, routing, auth, etc. It's uses standards, best practices, and is a good citizen. - The blog admin and the provided block editor are good out of the box. - It still gives you all the flexibility you want: it doesn't force any template on you, any page structure, workflow, nothing. You get to decide how simple or complex you blog is. - The team behind it is super nice.
- sgt 3y ago
  Will wagtail work in 10 years from now? Being Python and Django, it just might. In the node ecosystem, things are broken after 10 weeks or 10 months. The benefits of static site generations...
  - lastofus 3y ago
    Wagtail first shipped 9 years ago in 2014. It's already old/boring, and great!
- game_the0ry 3y ago
  Thanks for the comments. Did not know much about wagtail until now. Looks worthy of consideration for a side project I am considering. If you don't mind answering a couple of questions: - I have a requirement for basically a CMS with the capability of serious extensibility, built in either python or javascript (I considered ghost but it does meet my requirments). Main job is for a membership based cms but to potentially add functionality outside of standard cms stuff. Would you say wagtail / django combo would meet that requirement? (Sounds like "yes") - How does wagtail compare to django cms? (Less interested in feature comparisons, more interested in your developer experience with both) Thx in advanced!
  - 3y ago
tumidpandora 3y ago
Nice, built bravoboard ideas blog with Django as well. Nothing too fancy. Django gets the job done! https://www.bravoboard.xyz/ideas/ https://www.bravoboard.xyz/ideas/
KolmogorovComp 3y ago
Nice and simple. I feel the only lacking feature for a basic blog is having unlisted blog posts, which is very handy when you want to share it to proof-readers. This can be done on google doc/hedgedoc [0] for sure, but then when porting there are very often typos creeping in. [0] https://hedgedoc.org/ https://hedgedoc.org/
- wolfskaempf 3y ago
  The functionality exists in the author's implementation. If you search for 'is_draft' you'll come across the places in the code where this is implemented.
synergy20 3y ago
https://www.django-cms.org/en/ https://www.django-cms.org/en/ has blog with authentication etc, just a wordpress in python
ajhai 3y ago
Django has been my go to framework for any new web project I start for more than a decade. Its batteries-included approach meant that one could go pretty far with just Django alone. Included admin interface and the views/templating setup was what first drew me to the project. Django project itself has kept pace with recent developments in web development. I still remember migrations being an external project, getting merged in and the transition that followed. Ecosystem is pretty powerful too with projects like drf, channels, social-auth etc., covering most things we need to run in production. https://github.com/trypromptly/LLMStack https://github.com/trypromptly/LLMStack is a recent project I built entirely with Django. It uses django channels for websockets, drf for API and reactjs for the frontend.
Mimmy 3y ago
This might be a dumb question, but would you use the deployed version of the admin interface for writing your blog? And what if you weren't online but wanted to work on a new essay or make edits to an existing post?
- simonw 3y ago
  I usually write posts in Markdown these days, directly in VS Code with the preview pane open. The blog described in this article renders Markdown directly. My https://simonwillison.net/ https://simonwillison.net/ blog doesn't do that yet, instead I paste my Markdown into https://til.simonwillison.net/tools/render-markdown https://til.simonwillison.net/tools/render-markdown and then paste the HTML into the admin interface.
bodge5000 3y ago
I've been using Django for a number of years now and it's my go-to for any web app that requires any kind of dynamic content (especially user generated). DRF similarly for any REST related work fits in perfectly, but aside from that it's really refreshing to have a framework which doesn't require a tonne of other dependencies to get something decent off the ground.
Saphyel 3y ago
For a blog I prefer static site generators to be honest. Fast, cheap, secure and better for the environment. Django and Wordpress are still valid use case for a blog.
- stavros 3y ago
  I agree, I had my blog on Django, and the dynamic stuff was just minimal. Then again, with Django-Distill (linked above), you can get the best of both worlds.
- nicbou 3y ago
  I write and maintain content for a living. Switching to a static site generator is the best thing I have done for my productivity since I started that website. Powerful text editing tools I'm familiar with, source control, fully offline work, and very lightweight tooling that starts quickly (just a python script). I wrote a bit about the experience here: https://nicolasbouliane.com/projects/ursus https://nicolasbouliane.com/projects/ursus
colesantiago 3y ago
Just a question, is it possible to have a website built with Django and still work like the speed of a static site. I've seen all these JAMStack websites marketed as 'fast' when the only reason they are fast is that these web frameworks (11ty, Astro, Hugo, Gatsby, etc) are essentially static generators to HTML which is pretty much the same as creating a plain html file if you want to. I'm mainly interested in the SEO and speed side of things but does using a web framework like Django or an SSG make a difference?
- simonw 3y ago
  Computers are fast these days. If you write efficient code I don't see any reason the difference between a Django site and static files couldn't be imperceptible. Or... run a Django app behind a caching proxy like Varnish or Fastly or Cloudflare. I do that for my https://simonwillison.net/ https://simonwillison.net/ site (Cloudflare) and helped implement Varnish at Eventbrite - it's a really solid pattern.
  - nicbou 3y ago
    The advantage of a static site is that your server is simple, fast and secure, and requires little to no maintenance.
- EdwardDiego 3y ago
  Depends on how much work your Django app is doing. There's built-in caching support to make it faster. https://docs.djangoproject.com/en/4.2/topics/cache/ https://docs.djangoproject.com/en/4.2/topics/cache/
- nicbou 3y ago
  Caching can make it really fast, and this is good if you expect your website to change often (e.g. due to comments). Otherwise static is 100% the way to go, if only to reduce how much code to deploy.
waynesonfire 3y ago
Do your notes include how to recover from being hacked?
- simonw 3y ago
  Do you know something I don't know?
  - waynesonfire 3y ago
    No, just PTSD from my WordPress blog. I would use a static site generator if possible.
    - simonw 3y ago
      Hah, yeah securing something like WordPress can be a challenge, especially if you're running a bunch of plugins. My blog is a pretty straight-forward Django setup without many other dependencies, so it's a lot less of an attack surface: https://github.com/simonw/simonwillisonblog https://github.com/simonw/simonwillisonblog
nine_zeros 3y ago
How do people feel about Django vs flask in 2023? Just trying to farm for other's experiences because I find flask easier to start off with but I suspect I am biased.
- Daishiman 3y ago
  Every sufficiently large Flask app reimplements half of Django, badly. I’m the sole maintainer of a Flask app that uses SqlAlchemy, and the experience is similar except that I really miss the admin and auth. However every single flask app ends up using slightly different libraries and architecture, which means that onboarding always takes longer than an equivalent Django app. Also, I have over a decade of Python experience; I wouldn’t count on people with little Python experience to produce well architected apps in Flask, whereas Django does a lot of guiding the user towards established patterns. Some parts of Django are antiquated and I do not recommend them (specifically the Forms API really has been superseded by pretty much any newer forms library), but that’s still way less baggage than having to pick up a new stack for every new Flask app.
  - canadiantim 3y ago
    Curious why you think Django Forms API has been superseded? Are you recommending people use something like WTForms directly?
    - Daishiman 3y ago
      When I started using Rest Framework as I had more need for API endpoints than HTML pages I realized the Serializer API was way easier and more intuitive and pulled more weight. Then I began using Pydantic and its API design does pretty much the same except for the rendering part. I think the rendering aspect in the Forms API has always been a PITA and the validation aspects always left something to be desired. Rendering and validation/serialization should be decoupled IMO, and in that sense the Forms API fails. Sometimes I wish for the Django admin to be reimplemented in FastAPI/SqlAlchemy as a more modern approach to the same problems.
- 3y ago
fbdab103 3y ago
That's a cute trick with the ATOM feed content-type. Simple idea, that probably(?) will not trip up any dedicated readers, but makes a nice usability win.
- b0in 3y ago
  I wonder if it's possible or worth applying an xsl stylesheet or transform on this? Or would it create usability issues for dedicated readers?
  - simonw 3y ago
    I remember seeing people try that fifteen years ago - it was a feature of FeedBurner, which ... apparently continued to work until 2021! https://www.ctrl.blog/entry/feedburner-2021.html https://www.ctrl.blog/entry/feedburner-2021.html
  - toyg 3y ago
    In order for that to work, the browser would have to actually implement an XSLT engine. I thought they all stopped shipping such engines about 10 years ago. If you mean postprocessing the feed server-side with an XSLT sheet, to then serve the resulting page: sure, that would work, and a lot of people used to do things like that around 2003. It fell out of fashion because XSLT is just hard to safely combine with advanced JS-based features.
    - b0in 3y ago
      Strange, Chrome and Safari on OSX still render xml with referenced xsl stylesheets just fine (pointing to 192.168.x address). Browsers still have XSLTProcessor accessible in javascript too so I'm guessing they still have XSLT engines. xsl-stylesheet with css works for me as well.
  - ttepasse 3y ago
    There was a discussion here about that in June: https://news.ycombinator.com/item?id=36401854 https://news.ycombinator.com/item?id=36401854
gregsadetsky 3y ago
Big Django user and fan here! Ask HN: I plan on developing and deploying a bunch of Django apps in the coming months as I’m doing a 3 month stint at https://recurse.com https://recurse.com GitHub Pages is great for purely static content - but what is the preferred/""best""/cheapest option for django/postgres hosting? I know there’s tons of options - I used to be a Heroku fan until recently. Now am on Render (where things get expensive) Is Pulumi/Terraform/IaC on AWS the way? I want git-deploys, not have to write .sh scripts to restart nginx and pip dependencies that auto un/install if possible. I also thought of deploying one mega django project and having everything be a django app under that - it doesn’t feel sustainable/clean but maybe it’s ok for a bunch of small projects? Thanks!
- bredren 3y ago
  I use GitHub actions to automate test / build / deploy of django / Postgres / nginx docker orchestrations. I prefer digital ocean for VPS and have found you can get pretty far on the smaller droplets. I’ll typically have two environments, one getting auto deploys from anything on a feature branch, and production which gets deployed when there are changes to main. For my setup, I initially learned using blog entries from the folks who blog at: https://testdriven.io/blog/ https://testdriven.io/blog/ I blended multiple entries to achieve just the setup I wanted. I haven’t gone up to terraform though, finding it sufficient to use a pre built image of ubuntu / docker at the initialization. My oldest projects still use .sh to handle deploys but I’d never go back to that stuff.
- theptip 3y ago
  If you're not deploying at large scale, I'd go with something elastic in the same vein as Render (I haven't used that one though). Heroku used to be my go-to recommendation here of course. Fly.io gets a lot of love as a Heroku replacement and they have a generous free tier (though they have had some uptime troubles recently). Alternatively GCP and AWS both have elastic compute options that should work as well. (App Engine and Beanstalk? respectively.) Running a VM is going to be annoying (way more ops toil) and cost you more than you need, if you're making on the order of requests-per-hour instead of requests-per-minute. But if a VM is cheaper than your best elastic option you can make it work. I would not recommend sharing apps within a project as migrations can be annoying and you'll get downtime on every app whenever you deploy or break any of them. But you could have one VM serving up lots of projects, and give one port per project, then wire up a load balancer & DNS name for each project/port. It's possible to do git-deploys with a VM but it's a little work to wire up. You'd set it up with GitLab, and you can wire up a simple deploy script that effectively does a `docker stop && docker run` to launch your new app container.
tiffanyh 3y ago
Mojo? Has anyone heard if Django (or FastAPI, etc) will be ported to Mojo programming language? https://www.modular.com/mojo https://www.modular.com/mojo
- GVRV 3y ago
  According to the docs, Mojo is supposed to be a superset of Python, so technically nothing will need to be ported.
teleforce 3y ago
IMHO Django is what really catapults Python as one of the leading contender of interpreted programming languages for web development in the presence of the other popular ones namely Perl, Ruby, TCL and PHP. After many people started using Python for web development made popular by web framework like Zope and Django, then they stay and keep using it because it's relatively easy to program. Above all it's easier to grok and maintain due to its ancestor being ABC language. It also adopted identation and made it mandatory mainly for readability reason since most of the popular programs has more than one programmer or maintainer. Initially though Python got a lot of flak for this mandatory identation feature but later it's really its main advantage against other interpreted programming language of its time and programmers consider it a language with pseudo-like codes, but with functionality. Then come the era of data science and analytics popularity where Fortran and Matlab were kings, but the former is too primitive and the latter is a proprietary language. Interestingly, Guido himself was involved with new Python matrix operation syntax in order to make it more intuitive. Due to the rise of AI and machine learning where matrix operations are pervasive, Python becoming the best open source alternative and the rest is history. This is a very interesting read on HN for the reasons why Python win over its competitor and now the most popular language on the planet: [1] Ask HN: Why did Python win? https://news.ycombinator.com/item?id=37308747 https://news.ycombinator.com/item?id=37308747
HermanMartinus 3y ago
Bear Blog is a whole blogging platform running tens of thousands of blogs and is build in Django and running on pretty simple hardware. Django really is beautiful. https://bearblog.dev https://bearblog.dev
mediumsmart 3y ago
I really like Django and rails but here is how you make a blog: you choose a hosting package and pick your domain name for about 48 dollars per year. Then you create an index.html file and upload it. This file is your blog, you add <sections> that start with the date and below that you write your stuff for that date and each time you reupload the index.html. When around 365 days have passed you rename index.html to lastyear.html and start a new index.html that has a link to lastyear.html and that’s basically it. Have fun and don’t put too many images on the page.

214 points by theptip 3y ago

[dead]

This is great and I love the simplicity and speed (of page load and development). Curious, I ran it through Lighthouse and received a performance score of 100. By way of comparison, some of the more notable blogs on cloud edge were consistently between 60-80. Just checking my perceptions.

danpalmer 3y ago

For building CRUD web apps Django and Rails are truly in a league of their own[^1]. Many frameworks try to be good at this but finish development at a level of abstraction below these frameworks, leaving the last level to a plugin ecosystem that requires so much more work to wrangle into a fully working web app (see: Flask and its modern successors in Python). Other systems come at this from the opposite end, trying to be low-code or less-code, like headless CMSs or static site generators. The problem at that end always seems to be a lack of flexibility and over-reliance on proprietary systems or SaaS products. Django is just Python. Rails is just Ruby. There's nothing special to them and extending when necessary is often trivial, particularly because they have such mature extension points. There's a lot of criticism that can be levelled at these ecosystems for not keeping up with whatever the hype of the year is, or failing to "scale" in various ways, but damn do they get you a very long way with very little work. [^1]: Phoenix may be just about in this category, I don't have personal experience with it though, just going on the fact it seems to be very Rails inspired.

deleted 3y ago
[deleted]
deaddodo 3y ago
> Django is just Python. Rails is just Ruby. There's nothing special to them and extending when necessary is often trivial, particularly because they have such mature extension points. Eh, I wouldn't agree with that. Both Django and Rails extend the languages quite a bit with deep class overloading, reflection and fluidic approaches. Especially Rails, which pushes Ruby's DSL-like abilities to an extreme. If you go from learning RoR to then having to make a standard Ruby script, you quickly realize how much of what you built relied on Rails-specific functionality. Django, more or less, is just Python with a bunch of logic built for you, relative to that.
Daishiman 3y ago
As someone who's been using Django for the past 12 years in apps big and small, it blows my mind the trends towards microframeworks and minimalist frameworks that are objectively less productive in pretty much every metric. Sometimes it feel like a minor superpower in just how much more productive it is over pretty much everything, especially in the early stages of development. Even later on things like working auth and permission systems and API frameworks are huge timesavers. Proof that we are a fad-driven industry.
- mordae 3y ago
  And in exchange for a free auth system and a automatically generated basic admin interface you gain: - inability to use static type checker without writing most of the annotations yourself - half jinja2 functionality - ORM that makes it impossible to get your query count down to a manageable level - 3rd party modules that break the types even more I am lobbying for moving to FastAPI with Jinja2 and SQLAlchemy. We write our admins in Vue anyway.
  - simonw 3y ago
    I've not seen another ORM with tools as powerful as Django's select_related() and prefetch_related() when it comes to addressing the N+1 query problem, but maybe I haven't been looking hard enough. Jinja2 is a supported template backend for Django these days: https://docs.djangoproject.com/en/4.2/topics/templates/#django.template.backends.jinja2.Jinja2 https://docs.djangoproject.com/en/4.2/topics/templates/#djan...
  - selcuka 3y ago
    I believe these complaints may be caused by lack of experience with Django: - There is nothing wrong with the ORM, you may be resorting to using deferred attributes too much. There are ways to eliminate them (select_related, prefetch_related) if you are having performance issues. - Jinja2 has been a supported templating engine for years. - I don't understand the question about static type checking. Can you elaborate?
  - danpalmer 3y ago
    > We write our admins in Vue anyway And with Django you often don't need to write anything. You're right to some extent with all of your points (jinja2 is available, not default, ORM is equivalent to SQLA most but not all of the time), but they're one side of the trade-off. The other is that you're writing admin views that you likely wouldn't need to with Django. It's not perfect for everything, but it is much faster to write with than anything else for reasons like this.
EdwardDiego 3y ago
Django is Python, but very heavily leans on Python's metaprogramming, which can make things complicated to understand.

D13Fd 3y ago

If you want a more "out of the box" solution, you can run Wagtail and Puput on top of Django. The Puput default template is a bit dated, but it's pretty easy to update and tweak to your preferences.

WD-42 3y ago

This is how simple Django is for CRUD apps. The author could go even sparser. Love them or hate them, the views could have been replaced with class based model views for even less lines of code.

theptip 3y ago
Fewer lines of code, perhaps, but in terms of explicitness, clarity, and ease of maintainability I find myself strongly favoring the functional approach for this case.
izak30 3y ago
Just for kicks I ran `git log | grep "Author: Simon" -C 20 | tail -n 50` ``` commit 53eddd4a0f8786e23f511a653d8d7ffa947ad8db Author: Simon Willison <simon@simonwillison.net> Date: Mon Apr 23 21:24:41 2007 +0000 Added HTTP_HOST example header git-svn-id: http://code.djangoproject.com/svn/django/trunk@5063 bcc190cf-cafb-0310-a4f2-bffc1f526a37 ``` There are earlier references as well, but I think the author was making pretty deliberate choices.
- deleted 3y ago
  [deleted]
- toyg 3y ago
  Yes, Simon Willison was part of the Django core development team very early on, when he was ungodly young. Absurdly talented guy.

dabeeeenster 3y ago

Be interested to know how/where it's deployed!

simonw 3y ago
It's running here, hosted by https://fly.io https://fly.io - https://www.datasette.cloud/blog/ https://www.datasette.cloud/blog/
- 0xDEF 3y ago
  Does Datasette Cloud also run on Fly.io? How is Fly.io stability nowadays?
  - simonw 3y ago
    Yes, it does. Each Datasette Cloud user gets their own dedicated container, run using Fly Machines. The core Django app manages SSO and team creation, then calls Fly APIs to create volumes and machines for each team. I'll be writing this up in a lot more detail soon. I'm finding stability on Fly is excellent for my deployed containers. The problems I've seen are more around deployment - occasionally there will be incidents where fresh deploys can't go out for a few hours, all of which are reflected on https://status.flyio.net/ https://status.flyio.net/

davepeck 3y ago

This is great and showcases Django's talent for basic CRUD apps with handy admin interfaces. One catch: I like to deploy static sites to GitHub Pages. It turns out the Django ecosystem has an answer for that in the form of Django Distill [1]. Distill adds a new management command that generates static content by repeatedly invoking your views. I've used Distill to build quite a few static sites. It's great to be able to deploy to Pages but use Django's admin UI locally. Typically, for these sites, I check in my 'production' SQLite database directly to my git repo. (Combine this pattern with GitHub actions and you can do a lot with a little. For instance, here's a toy I built to summarize upcoming Seattle city council meetings [2].) [1] https://github.com/meeb/django-distill https://github.com/meeb/django-distill [2] https://scc.frontseat.org/ https://scc.frontseat.org/ -- source at https://github.com/front-seat/engage https://github.com/front-seat/engage

deaddodo 3y ago
I say this as someone that does like Django. I had the opposite opinion. If you were trying to convert Rails, Laravel or CakePHP users, this would just convince them that Django was more manual and involved than those frameworks. It would be better to utilize extensions like `scaffolding` to give a more equivalent workflow. It does demonstrate general MVC benefits and architecture, however.
reidjs 3y ago
Your links may be broken I was recently looking for a static site generator for a local relay race I help organize and django-distill was the top of my list. I ended up writing my own SSG because I had very little HTML that actually had to be generated on the site. But might check out django-distill in the future if you found it worth learning.
lylejantzi3rd 3y ago
Can you think of a complicated app that utilizes Django to its fullest extent? I'm trying to get a better view of what Django is capable of and I find it's helpful to see both the simplest example possible and the most complicated example possible. "Design for the extremes" as Don Norman would say.

gv83 3y ago

god i love django. it could use a little bit of modernization and modularization to ease the json api and deploy pain points, but it's still the best python web framework by a long shot and it would be deserving of way more manpower than it has. but emoji laden docs and 500/month patreon pay better than contributing to established things i guess

eYrKEC2 3y ago
With regard to JSON API aspects of Django, have you used https://www.django-rest-framework.org/ https://www.django-rest-framework.org/ on top of Django? I find it to be very satisfactory.
- tfeldmann 3y ago
  Django-Ninja is fantastic and based on pydantic.
  - winrid 3y ago
    This. I found DRF gets very confusing with all the abstraction for complicated stuff. For simple APIs, it's very nice (I used it on govscent.org). SidewaysData uses Ninja and I love it so far.
    - gv83 3y ago
      DRF becomes hard to understand when you use magical stuff like class based controllers and so on. stick to functions and it's actually very simple!
      - winrid 3y ago
        You're absolutely right - however I did not even know I could use functions. I didn't see that in the docs somehow. Also I think I remember with DRF I had trouble generating a good openapi client. With ninja it works really well.
  - 3y ago

sneak 3y ago

It's really not a good idea to use dynamically generated pages to run a blog. There's a reason static site generators exist. This should be made clear that this is just a toy/example app to demonstrate Django, not something someone should actually use. Generating the pages on each request is madness, and is why Wordpress in the default configuration (without WP Total Cache, which allows the httpd to bypass Wordpress entirely for most requests) falls over as soon as it's linked from any media site. Let's stop repeating these engineering mistakes in language after language. Compile your blog to static pages and deploy those. Hugo, Jekyll, and a million others await you, as well as CF Pages, S3, GitHub Pages, Netlify, and others.

simonw 3y ago
If you're worried about traffic spikes, stick your site behind a caching proxy like Varnish or Cloudflare. My main blog https://simonwillison.net/ https://simonwillison.net/ runs as a Django+PostgreSQL app on Heroku behind Cloudflare, with a 15m cache TTL for every page. This works perfectly. I survived a surprise Elon Musk tweet a few months ago which the server didn't even notice, because Cloudflare absorbed all the traffic: https://simonwillison.net/2023/Feb/17/analytics/ https://simonwillison.net/2023/Feb/17/analytics/
- frankwiles 3y ago
  Same, a bit of caching and the REVSYS blog survived being on the front page of Slashdot (back when that was a thing), Reddit and HN all at the same time. No Elon tweet for sure, but caching like Varnish, Cloudflare, Fastly etc go a LONG way.
lyjia 3y ago
There are other ways one can cache dynamic blog pages, like with CLoudflare. Some frameworks will automatically cache database calls as well, like with Rails.
AdamCraven 3y ago
As someone who uses a mixture (django, Hugo), I say it’s fine use dynamic sites to run a blog - there’s millions of them out there. They are usually easier to administer for less professional users, as well as being able to quickly modify from standard web interfaces. If it’s backed by a cache like redis it’ll easily handle Hackernews level traffic, even at very short cache times.

stuckinhell 3y ago

I wouldn't recommend people use anything that requires a database for a blog in 2023. Edit: Since I got extremely downvoted for this comment. Here is why: You should use static site generators for new blogs in 2023. Performance: Static sites typically load faster than database-driven ones. Security: Without a database, the risk of SQL injection attacks is eliminated. Scalability: Static sites can handle high traffic without complex hosting solutions. Maintenance: No database means fewer maintenance tasks and potential failures. Hosting and Costs: Static sites often have cheaper and more flexible hosting options. Decoupled Architecture: Modern trends prefer separating frontend and backend, reducing the need for databases. Development Simplicity: Static site generators offer a straightforward content writing environment. Backup and Portability: Static sites are easier to backup and migrate. Edge Hosting: Static sites benefit from faster load times with distributed hosting solutions.

Mimmy 3y ago
for people disagreeing with this comment, mind elaborating?
- smarx007 3y ago
  I think 800+ million Wordpress blogs are not planning to shut down in 2023 after reading GP's comment.
  - Cyphase 3y ago
    I don't think there are 800+ million WordPress blogs. WordPress is used for lots and lots of websites that are not blogs at all.
    - smarx007 3y ago
      Thank you, I stand corrected, 800M+ WordPress installations.
  - Heloseaa 3y ago
    This doesn't provide a counterpoint to the original comment's point. IMHO, it's true that a static site generator should be the way to go in 2023, instead of using a web framework with a db. I am personally running a hugo blog, on netlify, with netlify CMS. I have 0 costs, great performances, everything needed out of the box. What else to ask for ?

sc68cal 3y ago

I have been using Django for 10 years and it still is my tool of choice when I need to build something quickly that needs a full HTML and form handling interface. There is an excellent tool - https://djangobuilder.io/ https://djangobuilder.io/ that can also really speed up the boilerplate even more.

BiteCode_dev 3y ago

While this is a good example of all the good stuff raw django brings to the table, if you build a blog with django, you should go for wagtail in 2023: https://wagtail.org https://wagtail.org - It's incredibly more productive. - Seamlessly integrates with any django website, or hold your hand to create one from scratch. - Play nice with the whole django ecosystem. - Is easy to pick up because under the hood "it's just django". It uses django models, routing, auth, etc. It's uses standards, best practices, and is a good citizen. - The blog admin and the provided block editor are good out of the box. - It still gives you all the flexibility you want: it doesn't force any template on you, any page structure, workflow, nothing. You get to decide how simple or complex you blog is. - The team behind it is super nice.

sgt 3y ago
Will wagtail work in 10 years from now? Being Python and Django, it just might. In the node ecosystem, things are broken after 10 weeks or 10 months. The benefits of static site generations...
- lastofus 3y ago
  Wagtail first shipped 9 years ago in 2014. It's already old/boring, and great!
game_the0ry 3y ago
Thanks for the comments. Did not know much about wagtail until now. Looks worthy of consideration for a side project I am considering. If you don't mind answering a couple of questions: - I have a requirement for basically a CMS with the capability of serious extensibility, built in either python or javascript (I considered ghost but it does meet my requirments). Main job is for a membership based cms but to potentially add functionality outside of standard cms stuff. Would you say wagtail / django combo would meet that requirement? (Sounds like "yes") - How does wagtail compare to django cms? (Less interested in feature comparisons, more interested in your developer experience with both) Thx in advanced!
- 3y ago

tumidpandora 3y ago

Nice, built bravoboard ideas blog with Django as well. Nothing too fancy. Django gets the job done! https://www.bravoboard.xyz/ideas/ https://www.bravoboard.xyz/ideas/

KolmogorovComp 3y ago

Nice and simple. I feel the only lacking feature for a basic blog is having unlisted blog posts, which is very handy when you want to share it to proof-readers. This can be done on google doc/hedgedoc [0] for sure, but then when porting there are very often typos creeping in. [0] https://hedgedoc.org/ https://hedgedoc.org/

wolfskaempf 3y ago
The functionality exists in the author's implementation. If you search for 'is_draft' you'll come across the places in the code where this is implemented.

synergy20 3y ago

https://www.django-cms.org/en/ https://www.django-cms.org/en/ has blog with authentication etc, just a wordpress in python

ajhai 3y ago

Django has been my go to framework for any new web project I start for more than a decade. Its batteries-included approach meant that one could go pretty far with just Django alone. Included admin interface and the views/templating setup was what first drew me to the project. Django project itself has kept pace with recent developments in web development. I still remember migrations being an external project, getting merged in and the transition that followed. Ecosystem is pretty powerful too with projects like drf, channels, social-auth etc., covering most things we need to run in production. https://github.com/trypromptly/LLMStack https://github.com/trypromptly/LLMStack is a recent project I built entirely with Django. It uses django channels for websockets, drf for API and reactjs for the frontend.

Mimmy 3y ago

This might be a dumb question, but would you use the deployed version of the admin interface for writing your blog? And what if you weren't online but wanted to work on a new essay or make edits to an existing post?

simonw 3y ago
I usually write posts in Markdown these days, directly in VS Code with the preview pane open. The blog described in this article renders Markdown directly. My https://simonwillison.net/ https://simonwillison.net/ blog doesn't do that yet, instead I paste my Markdown into https://til.simonwillison.net/tools/render-markdown https://til.simonwillison.net/tools/render-markdown and then paste the HTML into the admin interface.

bodge5000 3y ago

I've been using Django for a number of years now and it's my go-to for any web app that requires any kind of dynamic content (especially user generated). DRF similarly for any REST related work fits in perfectly, but aside from that it's really refreshing to have a framework which doesn't require a tonne of other dependencies to get something decent off the ground.

Saphyel 3y ago

For a blog I prefer static site generators to be honest. Fast, cheap, secure and better for the environment. Django and Wordpress are still valid use case for a blog.

stavros 3y ago
I agree, I had my blog on Django, and the dynamic stuff was just minimal. Then again, with Django-Distill (linked above), you can get the best of both worlds.
nicbou 3y ago
I write and maintain content for a living. Switching to a static site generator is the best thing I have done for my productivity since I started that website. Powerful text editing tools I'm familiar with, source control, fully offline work, and very lightweight tooling that starts quickly (just a python script). I wrote a bit about the experience here: https://nicolasbouliane.com/projects/ursus https://nicolasbouliane.com/projects/ursus

colesantiago 3y ago

Just a question, is it possible to have a website built with Django and still work like the speed of a static site. I've seen all these JAMStack websites marketed as 'fast' when the only reason they are fast is that these web frameworks (11ty, Astro, Hugo, Gatsby, etc) are essentially static generators to HTML which is pretty much the same as creating a plain html file if you want to. I'm mainly interested in the SEO and speed side of things but does using a web framework like Django or an SSG make a difference?

simonw 3y ago
Computers are fast these days. If you write efficient code I don't see any reason the difference between a Django site and static files couldn't be imperceptible. Or... run a Django app behind a caching proxy like Varnish or Fastly or Cloudflare. I do that for my https://simonwillison.net/ https://simonwillison.net/ site (Cloudflare) and helped implement Varnish at Eventbrite - it's a really solid pattern.
- nicbou 3y ago
  The advantage of a static site is that your server is simple, fast and secure, and requires little to no maintenance.
EdwardDiego 3y ago
Depends on how much work your Django app is doing. There's built-in caching support to make it faster. https://docs.djangoproject.com/en/4.2/topics/cache/ https://docs.djangoproject.com/en/4.2/topics/cache/
nicbou 3y ago
Caching can make it really fast, and this is good if you expect your website to change often (e.g. due to comments). Otherwise static is 100% the way to go, if only to reduce how much code to deploy.

waynesonfire 3y ago

Do your notes include how to recover from being hacked?

simonw 3y ago
Do you know something I don't know?
- waynesonfire 3y ago
  No, just PTSD from my WordPress blog. I would use a static site generator if possible.
  - simonw 3y ago
    Hah, yeah securing something like WordPress can be a challenge, especially if you're running a bunch of plugins. My blog is a pretty straight-forward Django setup without many other dependencies, so it's a lot less of an attack surface: https://github.com/simonw/simonwillisonblog https://github.com/simonw/simonwillisonblog

nine_zeros 3y ago

How do people feel about Django vs flask in 2023? Just trying to farm for other's experiences because I find flask easier to start off with but I suspect I am biased.

Daishiman 3y ago
Every sufficiently large Flask app reimplements half of Django, badly. I’m the sole maintainer of a Flask app that uses SqlAlchemy, and the experience is similar except that I really miss the admin and auth. However every single flask app ends up using slightly different libraries and architecture, which means that onboarding always takes longer than an equivalent Django app. Also, I have over a decade of Python experience; I wouldn’t count on people with little Python experience to produce well architected apps in Flask, whereas Django does a lot of guiding the user towards established patterns. Some parts of Django are antiquated and I do not recommend them (specifically the Forms API really has been superseded by pretty much any newer forms library), but that’s still way less baggage than having to pick up a new stack for every new Flask app.
- canadiantim 3y ago
  Curious why you think Django Forms API has been superseded? Are you recommending people use something like WTForms directly?
  - Daishiman 3y ago
    When I started using Rest Framework as I had more need for API endpoints than HTML pages I realized the Serializer API was way easier and more intuitive and pulled more weight. Then I began using Pydantic and its API design does pretty much the same except for the rendering part. I think the rendering aspect in the Forms API has always been a PITA and the validation aspects always left something to be desired. Rendering and validation/serialization should be decoupled IMO, and in that sense the Forms API fails. Sometimes I wish for the Django admin to be reimplemented in FastAPI/SqlAlchemy as a more modern approach to the same problems.
3y ago

fbdab103 3y ago

That's a cute trick with the ATOM feed content-type. Simple idea, that probably(?) will not trip up any dedicated readers, but makes a nice usability win.

b0in 3y ago
I wonder if it's possible or worth applying an xsl stylesheet or transform on this? Or would it create usability issues for dedicated readers?
- simonw 3y ago
  I remember seeing people try that fifteen years ago - it was a feature of FeedBurner, which ... apparently continued to work until 2021! https://www.ctrl.blog/entry/feedburner-2021.html https://www.ctrl.blog/entry/feedburner-2021.html
- toyg 3y ago
  In order for that to work, the browser would have to actually implement an XSLT engine. I thought they all stopped shipping such engines about 10 years ago. If you mean postprocessing the feed server-side with an XSLT sheet, to then serve the resulting page: sure, that would work, and a lot of people used to do things like that around 2003. It fell out of fashion because XSLT is just hard to safely combine with advanced JS-based features.
  - b0in 3y ago
    Strange, Chrome and Safari on OSX still render xml with referenced xsl stylesheets just fine (pointing to 192.168.x address). Browsers still have XSLTProcessor accessible in javascript too so I'm guessing they still have XSLT engines. xsl-stylesheet with css works for me as well.
- ttepasse 3y ago
  There was a discussion here about that in June: https://news.ycombinator.com/item?id=36401854 https://news.ycombinator.com/item?id=36401854

gregsadetsky 3y ago

Big Django user and fan here! Ask HN: I plan on developing and deploying a bunch of Django apps in the coming months as I’m doing a 3 month stint at https://recurse.com https://recurse.com GitHub Pages is great for purely static content - but what is the preferred/""best""/cheapest option for django/postgres hosting? I know there’s tons of options - I used to be a Heroku fan until recently. Now am on Render (where things get expensive) Is Pulumi/Terraform/IaC on AWS the way? I want git-deploys, not have to write .sh scripts to restart nginx and pip dependencies that auto un/install if possible. I also thought of deploying one mega django project and having everything be a django app under that - it doesn’t feel sustainable/clean but maybe it’s ok for a bunch of small projects? Thanks!

bredren 3y ago
I use GitHub actions to automate test / build / deploy of django / Postgres / nginx docker orchestrations. I prefer digital ocean for VPS and have found you can get pretty far on the smaller droplets. I’ll typically have two environments, one getting auto deploys from anything on a feature branch, and production which gets deployed when there are changes to main. For my setup, I initially learned using blog entries from the folks who blog at: https://testdriven.io/blog/ https://testdriven.io/blog/ I blended multiple entries to achieve just the setup I wanted. I haven’t gone up to terraform though, finding it sufficient to use a pre built image of ubuntu / docker at the initialization. My oldest projects still use .sh to handle deploys but I’d never go back to that stuff.
theptip 3y ago
If you're not deploying at large scale, I'd go with something elastic in the same vein as Render (I haven't used that one though). Heroku used to be my go-to recommendation here of course. Fly.io gets a lot of love as a Heroku replacement and they have a generous free tier (though they have had some uptime troubles recently). Alternatively GCP and AWS both have elastic compute options that should work as well. (App Engine and Beanstalk? respectively.) Running a VM is going to be annoying (way more ops toil) and cost you more than you need, if you're making on the order of requests-per-hour instead of requests-per-minute. But if a VM is cheaper than your best elastic option you can make it work. I would not recommend sharing apps within a project as migrations can be annoying and you'll get downtime on every app whenever you deploy or break any of them. But you could have one VM serving up lots of projects, and give one port per project, then wire up a load balancer & DNS name for each project/port. It's possible to do git-deploys with a VM but it's a little work to wire up. You'd set it up with GitLab, and you can wire up a simple deploy script that effectively does a `docker stop && docker run` to launch your new app container.

tiffanyh 3y ago

Mojo? Has anyone heard if Django (or FastAPI, etc) will be ported to Mojo programming language? https://www.modular.com/mojo https://www.modular.com/mojo

GVRV 3y ago
According to the docs, Mojo is supposed to be a superset of Python, so technically nothing will need to be ported.

teleforce 3y ago

IMHO Django is what really catapults Python as one of the leading contender of interpreted programming languages for web development in the presence of the other popular ones namely Perl, Ruby, TCL and PHP. After many people started using Python for web development made popular by web framework like Zope and Django, then they stay and keep using it because it's relatively easy to program. Above all it's easier to grok and maintain due to its ancestor being ABC language. It also adopted identation and made it mandatory mainly for readability reason since most of the popular programs has more than one programmer or maintainer. Initially though Python got a lot of flak for this mandatory identation feature but later it's really its main advantage against other interpreted programming language of its time and programmers consider it a language with pseudo-like codes, but with functionality. Then come the era of data science and analytics popularity where Fortran and Matlab were kings, but the former is too primitive and the latter is a proprietary language. Interestingly, Guido himself was involved with new Python matrix operation syntax in order to make it more intuitive. Due to the rise of AI and machine learning where matrix operations are pervasive, Python becoming the best open source alternative and the rest is history. This is a very interesting read on HN for the reasons why Python win over its competitor and now the most popular language on the planet: [1] Ask HN: Why did Python win? https://news.ycombinator.com/item?id=37308747 https://news.ycombinator.com/item?id=37308747

HermanMartinus 3y ago

Bear Blog is a whole blogging platform running tens of thousands of blogs and is build in Django and running on pretty simple hardware. Django really is beautiful. https://bearblog.dev https://bearblog.dev

mediumsmart 3y ago

I really like Django and rails but here is how you make a blog: you choose a hosting package and pick your domain name for about 48 dollars per year. Then you create an index.html file and upload it. This file is your blog, you add <sections> that start with the date and below that you write your stuff for that date and each time you reupload the index.html. When around 365 days have passed you rename index.html to lastyear.html and start a new index.html that has a link to lastyear.html and that’s basically it. Have fun and don’t put too many images on the page.