When it comes to writing web applications, my go-to framework is usually Flask.

JSfags like Express. PHPbros swear by Laravel. They're both wrong. You should be using Flask.

On a serious note, Flask is an ideal framework if you're just getting started with web app development. Since Flask is a microframework and doesn't come with "batteries included", it forces you to make decisions about its extensibility and architecture on your own.

Need a database? Pick one - Flask doesn't force MySQL, Postgres, or Mongo on you. Want to manage user accounts? Feel free to use session-based authentication or JWT. Building a front-end heavy CRUD app? Use the JS framework of your choice to digest Flask-powered API endpoints, server-side render all your templates, or mix and match according to your needs.

Don't know what any of that stuff means? That's why you should be using a microframework like Flask!

By forcing you to make these design decisions at the framework level, you'll have a much better idea of how web apps work on the server side. Every library you add to your application will be a component you come to understand intimately. And let's be honest, Python is a much more approachable language than ES6+ JavaScript for beginners.

Full stack web app developers will have to learn JS along the way regardless, and since both are C-like languages, it's easy enough to pick up one after you've learned the other. You might as well learn a good language first.

So yeah. If you're new to web app development, give Flask a shot. Try out Flaskeleton, a simple blueprint I whipped up to help Flask developers bootstrap new projects. Or check out Corey Schafer's Flask Tutorial if you're a webdev virgin.

Otherwise, read on to hear me bitch about the atrocious state of modern web applications and how they're designed to make you a corporate serf!

Modern Web App Architecture Sucks

If you've just started learning web application development in The Current Year (2022 as of writing), you're probably learning some JavaScript front-end framework. Likely Facebook's ubiquitous React, because that's what globohomo corporations use, and that's where the jobs are. You might even be eschewing the fundamentals of the language in order to flesh out your portfolio.

Fine. If you're just looking for a junior development job, maybe that's life.

You should know, however, that front-end frameworks are not designed with independence in mind.

They're designed to make you a cog in someone else's machine.

Front-end applications are rarely standalone products. They require some kind of interaction with a server, probably multiple servers, to function. To realistically float a full stack JavaScript application beyond a Hello World-tier Todo app, you have to:

1. Create a server that spits out JSON to your front-end client
2. Build a front-end that digests JSON from your server
3. Generate routes for your front-end as well as API endpoints for your back-end
4. Maintain state between your front-end and your back-end with regular "handshakes" between the two
5. Configure your front-end and back-end on two different subdomains using a web server like Nginx
6. Ensure that both your front and back-end are floated properly, are cross-origin request compatible, and functioning as intended

That's a lot to handle for a new developer. Heck, that's a lot to handle for an experienced developer looking to float a simple MVP (minimum viable product).

You know who it's not a lot for? A 500+ man development team at FAGMAN (Facebook Apple Google Microsoft Amazon Netflix) with endless resources. On the contrary, FAGMAN is hoping that you develop an autist-tier skillset so hyperfocused on a single part of the stack that you are useless on your own.

That you can never leave their plantation and develop full-fledged applications of your own volition.

That your knowledge base is so narrow that the notion of striking out on your own is an anathema to you.

Companies like Meta, Twitter, and Alphabet aren't releasing open-source SDKs and frameworks out of the goodness of their heart, after all. They're doing it to inculcate you into a set of design patterns to farm future employees on the cheap and get free bug fixes from clout-chasers on GitHub.

Thankfully, it doesn't have to be this way.

Back to Basics

Let's compare the above "zero to deployment" steps outlined for bloated JS-driven apps above to a simple server-side rendered app:

1. Create a server that renders templates using your app's logic
2. Build a front-end using HTML, CSS, and a templating engine
3. Deploy your application on a single domain

This is obviously a lot more manageable for a new developer. There's less to go wrong. There's a lot less cognitive overhead. Deployment is easier. And if something breaks in your development environment, it'll be easier to debug.

But server-side templating is OLD TECH, FF. Cool kids use heckin' front-end frameworks and flash innane animations in your face! It's ThE fUtUrE oF WeBsItEs.

Tell that to Amazon, eBay, AirBNB, or any of the other tech juggernauts that use primarily server-rendered templates and sprinkle in JavaScript where necessary.

There's good reasons these companies do things this way: Server-side templates load faster. Server-side templates are indexed better by search engines. Server-side templating is better for device battery life. Server-side templating is fault-tolerant for browsers with limited JavaScript support, or privacy-oriented users with NoScript enabled.

I could go on, but you get the point.

The sad fact is, the delusional trend to turn every site on the 'net into a single-page app is already starting to break down, with new frameworks like NuxtJS trying to shoe-horn server-side templating into frameworks that were designed to avoid it in the first place! Web developers are reinventing the wheel and trying to resurrect "dead" technologies that never stepped foot in the grave to begin with.

That's one of the reasons why Flask is such a fantastic web framework: It can exist in any front-end paradigm, and it's a framework that a new developer can grow with without being shoe-horned into a single ecosystem.

But if I use Flask's server-side templating engine, FF, I can't use < insert popular JS framework of the week here >! It's one or the other!

I would submit that whenever you're picking up a new language, you shouldn't be using frameworks at first. You should be learning the language itself.

Why not start learning JS by developing a server-side rendered template that uses vanilla JS to handle simple animations and API calls? You'll be much more familiar with the core concepts of JavaScript after building a simple app or two this way.

Besides, using Flask and Jinja2 by no means implies you can't use a JS framework. Sure, React is difficult to shoe-horn into this paradigm, but Vue is not.

You can use Vue as a drop-in script in any HTML page, just like jQuery of olde. It's by far the most flexible of the "modern" JS frameworks for this reason, and it allows you to develop reusable JS components without having to commit fully to the SPA design pattern.

You can have your JS framework cake and eat it, too.

Okay, but you're still WRONG, Federal Farmer

I concede that there are plenty of instances where you might want to use a single-page app architecture that digests JSON from an API instead of server-side rendering.

Some of the common reasons stated for doing so, however, simply aren't true, and many of these benefits are for companies operating at scale, not independent developers. Let's take a look at a few of the common reasons people say this:

• If your server is simply an API, you can use the same server to build cross-platform apps (i.e. web apps and mobile apps)

Yes, but that doesn't mean you're required to use NodeJS+React to accomplish this.

You can just as easily set up API endpoints to power a mobile app using a server that also handles templating for a web app. This kind of separation of logic is precisely why Flask's Blueprint paradigm exists, and it's why I put Flaskeleton up on GitLab so developers can scaffold out an app with these separations of concern already in place.

This level of code segregation is probably not going to matter for most independent developers, anyways. It does, however, benefit big companies who have the resources to build a web app, Electron app, React Native mobile app, and Apple Watch app all using the same server-side logic.

Yet another example of how these technologies are built by corporations, for corporations, but I digress.

• I want to syndicate my app as a Progressive Web App to avoid the hassle of app stores

While it's definitely possible to add the requirements of a PWA to any website, it is doubtlessly easier to do so with a front-end framework where a library to do so already exists.

PWAs are becoming more popular, though, and packages for adding this functionality are becoming increasingly common. So I wouldn't make a large design decision based on the ease of adding a PWA alone.

• My app requires lots of real-time interactivity (maybe a video game or financial software with lots of data visualization) and refreshing the page at all would break immersion

This is one instance where a JavaScript-centric SPA is probably a good decision.

While it's totally possible to build a single page with lots of JS components and create a highly immersive experience on that one page, mixing server-side rendering with a JS framework may actually add more overhead than just building an SPA in the first place.

• My app requires some esoteric library that's only available as a package on NPM

You're writing a crypto app, aren't you? Don't lie, you degenerate gambler.

Kidding aside, it really do be like that sometimes. You might need to use a mission-critical SDK that's only available in one language. If that's the case, it may be worth architecting your app around that design constraint.

I've had this happen to me with certain web app ideas - sometimes it was worth it to write my own library from scratch, but I understand that's not always feasible or a good investment of your time.

• I love writing JavaScript and/or JavaScript is the only language I know

If that's the case, go for it. I think you're a masochist, but whaetver makes you happy, bro 😉️

In Closing

The point of this article isn't to convince you not to learn or use React (well, maybe a little bit).

The point is that when learning a skillset like software development where you can build anything your mind's eye can imagine, you should cultivate that skillset in a way that grants you the most possible independence in your "career". You should be fostering a skillset where you can pick up a wagie software gig if you have to, but that you can leave at any time to build your own apps/services/companies.

A skillset that is portable and time-tested.

JavaScript isn't going away anytime soon. Server-side templating isn't going away anytime soon. Frameworks come and go all the time.

React is really popular at present and has dominated the startup scene for a few years now. Before that, Angular was the main hotness. Before that, jQuery. Is anyone launching new startups using Ruby on Rails?

There will doubtlessly be people that disagree with me. They'll tell you that hyperfocused specialization is the way the world is going and that it's a waste of time to be a generalist in any field.

But as globalization goes the way of the dodo bird, so too will the humanoid cogs created by corporatism. Software independence is a bet against the current configuration of the economy.

It's a revolt against the modern web.