It has been half a year since I started my blog in May this year. Although there is no difficulty to build a blog, but their website is used to toss, so the engine behind the blog has also changed several times in this half a year. Here, I use a variety of blog technical framework of their own experience and some of their own experience recorded, I hope to also want to build their own blog students have reference bar.

WordPress

This is without a doubt the most well-known blogging engine in the world. When I started the site, I didn’t plan to spend much time writing my own blog, so it was a logical choice to use one of the most popular solutions on the market.

I don’t have any experience with PHP myself (and don’t like it). From experience, perhaps the most attractive aspect of phP-based solutions is that deploying a web site is a simple copy action that doesn’t involve stopping or restarting any servers. This feature should be very pleasing to space providers and ordinary users without a programmer background, after all, there is a large barrier for these users to manage their own servers. Programmers, on the other hand, may not feel much about it.

WordPress as a blog engine itself is fairly complete, but much of the deeper functionality still depends on third-party plug-ins, of course, WordPress also has a very large plug-in market. There are a lot of plugins that make blogging better, but they also raise some annoying questions:

  • Plug-in quality is uneven, some installation will appear some puzzling problems;
  • Many plug-ins have similar functions, similar reviews, and even similar names. You don’t know which one to choose, so you have to try one by yourself.
  • Some plugins work well, but it’s a worry to see if they work well because they are old.
  • With more plug-ins, the need for upgrades comes up more often. It’s annoying to pop up every now and then;
  • Sometimes custom changes will be overwritten after the plugin is upgraded.
  • Some plug-ins are obviously suspected of being top of the list;
  • There are a lot of plug-ins that need to be paid for. Payment isn’t a big deal, but it’s less pleasant to have to pay for bits and pieces of functionality separately;

Of course, the above phenomenon is generally true in other similar app markets. However, for a site like blog, which is not too complicated and is also a programmer, this situation is uncomfortable. It may be just a few lines of code that you rely on a third party you don’t know if you can trust, and you don’t know when it will be resolved. The WordPress plugin market also doesn’t seem as tightly regulated as the Apple Store.

In addition, there are some functional customizations that require you to modify the PHP code yourself. I personally have no love for PHP, so if I have to write my own code, why don’t I do it myself? So, after about a month of WordPress, I started looking for other solutions.

Hexo

Hexo is very different in that it is a static web site generator. Using a static website completely eliminates the need to write programs and upgrade their own troubles, but also do not have to worry about performance and security issues, of course, the disadvantage is that it is difficult to achieve dynamic interaction. I do see some projects exploring the possibility of breaking through static constraints, but seriously, these requirements are beyond the capabilities of static sites, so if you really need a lot of interaction, consider dynamic sites.

When I used WordPress, I found that while there was a comment feature, most of the initial reaction was ads and spam (due to the lack of traffic, of course). So my main question at this point was: since dynamic features are useless and add junk, I’d better ban them altogether. Hexo fits the bill for me. There are static web site generators available in almost all major programming languages, but Hexo is probably the most popular and well-received, so I chose it.

Hexo is the ultimate simplification in terms of deployment. Once configured, to deploy, you basically just need to do:

hexo d -g
Copy the code

The job of Posting and managing is also fairly simple. In addition, Hexo pioneered the (I think) excellent idea of writing content in Markdown. WordPress uses a rich text editor, which is intuitive, but the generated HTML is verbose and prone to redundant tags, making it sometimes difficult to accurately control the content and formatting. Hexo’s default theme is also very plain and generous (my current blog has also inherited this theme).

Overall, FEATure-wise, I’m very pleased with Hexo. What I am not satisfied with is that I still miss the flexibility of dynamic websites after using them for a long time. For example, I want to add some statistics, tracking and analysis functions that static websites cannot achieve. Although some third-party solutions can be introduced, external tools are not as accurate and detailed as their own background data anyway.

If you’re not a programmer yourself and don’t want to put in the effort to learn how to code; Or if you’re a programmer yourself, but your blog needs to be a place to write articles, Hexo is a simple and efficient solution that you should consider. But if you want to have more than just a collection of static content, but a website with its own features that can be managed and maintained, Hexo is not going to cut it, and you’re going to have to move on (as I did).

Another way to use Hexo is to post content to supported sites, most notably Github Pages. Other services such as GitLab, code cloud and Coding in China also have similar functions. This advantage is not only do not have to create their own website, even looking for hosting space time can be eliminated. However, it also means that your content is no longer entirely your own, but shared with a host. This is not necessarily a big deal, but you should seriously consider the potential problems if you want to do it. There is no such thing as a free lunch. The final decision is yours.

Flask

During the migration from Hexo, I made two decisions. One is that the site must be dynamic; The other is that the base language is not Java/C#, which I’m more familiar with, but Python. The thought process won’t be explained here, but since you’re using Python, the Web framework is basically a choice between Flask and Django.

My original choice was Flask. Flask’s design philosophy is small but beautiful, which is closer to mine, and there’s a lot to commend Flask’s design. I had basically written an entire blog site in Flask, but EVENTUALLY I gave up. Why is that?

Flask’s design quirks are that in order to define URL routing, you need to define view functions after defining app or Blueprint; The view function, in turn, needs to reference app or Blueprint defined earlier. This may not sound like much, but code order is especially important when a module is being split, because otherwise it’s easy to see circular references or Import errors that don’t mean anything. Of course, this problem can be avoided with care, but I particularly dislike the design style of enforcing code order. Django, as we’ll see later, is probably aware of this problem and uses module strings as arguments in its configuration rather than strong references, so that programmers don’t have to worry too much about the order in which code is defined.

Another problem is that Flask’S urls can only be partitioned by Blueprint; in fact, larger applications often require multiple levels of URL structure, and Blueprint is not nested. This question has also been asked on Stackoverflow and Stackoverflow, but there is no official solution, just a few hacks (see Stackoverflow and Github Issue). It’s not impossible to prefix each address yourself, but that wouldn’t be DRY…

Last but not least, there will be some boring CRUD work on the web. You can do it yourself, but using Django will save you a lot of work. When I discovered this, I began to turn to the direction below.

Conclusion: Just because I’ve given up on blogging in Flask doesn’t mean it’s not working (there are plenty of tutorials online), it’s just that I don’t like some parts of the framework, and it’s not an insurmountable problem. I also use Flask to create temporary sites to test features. This kind of task is too heavy to create an entire project with Java/C# and Django. Flask, on the other hand, requires a single file and a dozen or so lines of code to run, which is much faster and easier.

Django

In contrast to Flask’s style, Django takes a big, holistic, one-stop approach. This made me prefer Flask rather than it at first. A closer look, however, shows that Django is quite customizable, and the built-in Admin saves a lot of repetitive work (although the interface isn’t pretty, and that’s not a big deal when it comes to back-office administration of individual sites). The current site is Django based, and it was a pleasant process to write with no major pain points. I believe the current architecture will be sufficient for quite some time.

Working with Django is a different experience. This is because most of the things the framework has already taken care of for you, you don’t have to write much code, you spend most of your time getting familiar with the mechanisms and methods the framework provides, and Django’s architecture is pretty complex. Some students may not like this feeling of restriction, but in my experience, Django’s setup is generally sound. Some articles have also mentioned that Django’s all-in-one approach doesn’t fit in with the current microservices trend, which should be true, as the pieces of Django are hard to break down. But when it comes to personal websites, microservices are obviously overkill, and Django is a good choice for that.

Django is not without its drawbacks. My least favorite is its Template, which is probably designed to prevent designers from making mistakes, and is a bit crude and weird, which is not what programmers are used to. Flask’s Jinja2 engine, by contrast, is a lot easier to look at. Currently Django also allows programmers to use Jinja2, but it requires some configuration and is not as integrated in debugging as the built-in templates. My site also uses Jinja2 as the default template engine in the foreground section. It is also worth noting that Django versions change quite frequently, and some of the code that was built before 1.8 May not be available in 1.11. However, many articles on the web do not specify which version you are using, so you need to be careful.

One last word. Flask is good for getting started because it’s easy and quick. But my experience tells me that conclusion can be deceiving. Because Flask is a micro-framework, it doesn’t do much of anything for itself other than routing and templates, and you have to learn a lot of add-ons to build a full site, it’s not necessarily going to cost much less than Django. The core plugins commonly used like flask-Script, flask-SQLAlchemy, flask-Login are guaranteed quality, while the rest are not. In my opinion, Django is a better choice for beginners. The limitations of the so-called framework are actually instructive for beginners, and not a bad thing. Flask will have a lot more freedom for a real expert — but that’s when you’ve got a solid foundation.

PS: Just as I was writing this post, I found out that Flask’s official website is STILL HTTP, and Django has HTTPS enabled. Maybe Flask’s authors feel that their site is static and not worth hacking. But IN my mind, I gave Django a +1.