A Journey from Django to NextJS

Introduction

I began coding during the COVID-19 pandemic. At first it was a hobby to distract me from quarantine and a tool for procrastinating my school work. My first language was Python, because it reads easy to English-oriented readers. Additionally, the language is well-documented, stable, and elegant. My first code involved writing a text-to-speech pipeline for my Pdf and Epub reading assignments with Coqui TTS. My code would take extracted text files, filter text strings, convert text to speech, convert it to mp3 with FFmpeg, and finally, save it to its own folder. But then I graduated college and my interests for coding grew into an actual career interest. I wanted to make websites.

Django web development

And so it seemed only sensible to start with Django. Not only was it equally renowned for being stable, easy to learn, and well-documented, it also shared many of Python's programming beliefs and approaches to coding. This made both learning web development and using Python fun and enjoyable. I felt like many of Django's features fell hand in hand with Python's coding philosophy.

My first goal was simple, I wanted to make a blackjack website. I began with the game logic, easy enough. I then wrote the first views, I decided on functions over classes. While I didn't have a user system in mind, I decided to learn some SQLite and make one for my model, thinking that this would lead to simple user settings down the line. I then made a form and its views. Finally, I designed some templates and wrote some css styles from scratch.

When it came to connecting the controls of my game logic, I followed the Model View Template recipe, Django's variant of Model-view-controller. But here I struggled because I didn't want to have every game action to reload the page, and I didn't want each action to be a link. What I wanted was to make my website remain on a single page, exactly like a Single-page Application.

Doing a preliminary search on DuckDuckGo didn't produce the results I hoped for. At most I found tutorial blog posts with few examples. I turned to my partner, who is an actual fullstack web developer herself, on what I should use, and she mentioned htmx. And after some tedious templating and sprinkling of AJAX, I had SPA-like views where each game action updated the game, but the page stayed the same. I felt happy with the result, but I also felt like I had traded one problem for another. I had done my best at keeping DRY, but my templates felt redundant. I'm sure if I spent more time on it, I could make it better, but "perfect is the enemy of good."

And honestly, I think for a first website, the app was looking great but I still had to style it! Now I'm no web designer, I generally like minimalist looks, but for this page, I did want to make the game look and feel like you were in a casino. It was a silly want, one that took more effort than I initially intended, but one that bugged me nonetheless.

Now, writing CSS from scratch is rough when you're not a seasoned web designer, and a little rougher still when Django has you trawling through widget attributes to add your CSS. (Another option was to add the form elements to your template by hand and add the styles there, though, this is not recommended for the obvious reason that it is verbose.) And to be honest, neither of these approaches felt clean or simple. In some sense, I felt like it was my fault for not hunkering down to the approach, but by this point, I also felt like my simple game was scattershot.

I understood and appreciated how rigid and descriptive Django's web design sanitized and handled data, how the MVT made everything sequential and segmented, but I didn't like how each little change I made needed three file edits to get it working. The advantage of models, views, and templates felt like this framework was the wrong one for what I wanted to do.

I still love Django. It's documentation is a pleasure to read, the classes it provides feel to-the-point, and if I had to run a newsletter, I would look to it first. And I am still happy and proud of my application. When I look at the code, I can see what I learned and when. But it is a project I have no interest in deploying and managing. You can find it here.

Static Site Generators

After I finished making blackjack, I had told my girlfriend all about the development experience and about what I had learned. I asked her for some brainstorming ideas on what to make next and she mentioned creating my own static site generator. The idea instantly hooked me. It sounded so open-ended, approachable from many sides, and also very personable. Best of all, I already had a sense for what I wanted out of it too. I wanted to make my own website, a work blog.

I had used tools like Blogger and Weebly for homework assignments and personal blogs before, so the idea of a blog felt close. But writing prose in Google docs and then pasting it to a text box wasn't my idea of blogging. In my last years of university, I began writing all of my lecture and study notes in Markdown. I had even used it to write poetry for my remaining English classes! So I knew I wanted to write my website with md, wherever possible. I looked for a library that could convert MD to HTML. I decided on Python-Markdown, because it handles the occasional HTML syntax during conversions and it has a good extensions library should I decide to add any. Since my website was a blog, I added Jinja to handle the templates. And, then I started writing.

As I developed my pages, I realized how the static site generator became the outline and map to my website. My website felt deeply integrated and close compared to how it felt in Django and I think part of it was that apart from the md conversions, my website was as simple as it could be. Just some good ol' HTML and CSS. Additionally, the libraries I used provided no guidance to how my blog needed to be arranged or how it needed to look. The only limitation to my website was the time I could spend on it.

I deployed my static site with Github pages. If you're reading this, I have since taken it down and replaced it with the current blog you're reading. The reason for this was speed. When I wrote the blog I wrote all my styles from scratch. I used Catppuccin for my color pallete, but I had to style the code brackets, tables, and any small element I wanted to add. While I could have added a CSS library to handle this, I felt like it ran counter to the spirit of a static site generator. But reality always sets in as ideals chase the horizon. I kept running into the altered addage that "no website is an island." and I had to accept that. I finished my project and deployed it. And I began thinking about what I needed to change if I wanted to make websites faster.

Coming around to Javascript

By this point, my websites were simple because the code behind them was penned in Python. I hardly ventured into Javascript, unless by way of libraries like htmx. And this was mostly because whenever I ventured into Javascript, I kept running into weird and strange things.

By no means did I dislike Javascript, but if I had to put it into words, I would say it felt at odds with Python. Not in an antagonistic sense, but in the sense that they were built for different things. Each has it own set of types, conversion logics, and coding philosophies. Where Python is readable, Javascript is cluttered. Where Python is conservative, Javascript is cutting edge. And in the case of web development, as fun as Python is, it is not the language web browsers use. If I wanted to make my websites interactive, I needed to learn JS.

As I mentioned earlier, my blackjack website had a SPA-like approach. Each game had its own URL, but the game actions for 'bet', 'hit', 'stand', and 'continue' were all htmx request where the view would update the model and render the appropriate template response. Doing this quickly led to many templates, but for the betting page, the last view I worked on, I decided to write some dedicated javascript.

I wanted the user to bet with chips. They could still write in the bet, but they could also click on the chips to make their bet. I used Animate.css to create the motion styles of the chips moving to and from each pile. The chip style, I made myself! 😊

Looking at the javascript, you could probably see where I was going with it.

<script>
    function dec(coin) {
        var idBet = document.getElementById("id_bet");
        var betValue = parseInt(idBet.value);
        var idCoinBet = "c" + coin.toString() + "_bet";
        document.getElementById("betall").style.visibility = "visible";
        if (betValue >= coin) {
            betValue -= coin;
            idBet.value = betValue.toString();
            coinVisibility();
        } 
    }

    function inc(coin) {
        var idBet = document.getElementById("id_bet");
        var betValue = parseInt(idBet.value);
        var maxValidBet = parseInt("{{ game.coins }}");
        var idCoinBet = "c" + coin.toString() + "_bet";
        if ((maxValidBet - betValue) >= coin) {
            betValue += coin;
            idBet.value = betValue.toString();
            coinVisibility();
            document.getElementById(idCoinBet).style.visibility = "visible";
        }
    }
</script>

By trying to add control buttons to my bet input, I had inadvertedly stumbled onto React style componentry. This could have easily been a useState() with a couple of smaller components to setState(). But I didn't know about React. I was only following the designs I had observed on the internet.

Now, I'm not a Python expert (yet!), but using it as best I could felt like a comfort. I knew there was always a reasonable and simple answer to why Python was arranged the way that it was. If I needed to use a new library, I could be somewhat guaranteed to find something within the ballpark of what I wanted, with enough examples to get my project going. I hardly ever needed to track down a github issue or find myself in the stackoverflow trenches to get an answer. And so I focused on what I knew and kept the Javascript simple and rudimentary, but I now had to venture beyond a <script> tag.

Learning React

Learning React was a fun experience. I began with the tutorials, nothing strange, very sensible. Curly brackets for js parameters and inside html-like responses, got it. functional programming that's open to custom designs and features, very versatile. Responsive and easy to build client-based states? Slick! Hold on... working with javascript is actually fun, easy, and fast!

I quickly realized there was nothing to be afraid of! I had found what I was looking for and I loved it. Every single thing about React is just 💖lovely💖! 😍 Passing props to child components, automatic handling of input states, returning readable JSX elements, compartmentalizing UI componentry, integrating CSS classes seamlessly. It all felt so clean, so clever, and best of all, so byte-sized!

Learning NextJS

If learning React was fun, how was working with Javascript like? Long story short, it felt like culture shock.

With the idea of using React for my next website, I asked my partner again for framework advice. She used Gatsby when she was learning, but noted that NextJS was the React framework everyone was using nowadays. So I went through the documentations and tutorials, and started learning. And immediately, I began noticing the difference with development practices between Django and NextJS.

It seemed to me that where Django was stable, with an easy navigator to previous framework versions, and extensive examples, NextJS, was a little more... esoteric about their documentation, tutorials, and recommendations. I frequently found myself searching for issues I ran into and reading multiple discussion threads on broken dependencies, deprecated tutorial instructions, and uninformative suggestions. And I realized why this was the case too. NextJS is cutting edge, double-edged in fact! It isn't enough that a method for creating websites has already been outlined and stabilized with previous versions, the framework keeps changing to account for new projects and library integrations, with App Router being the latest configuration since last year. By no means do I think this is bad, things always change, but I will say I found it shocking. With Django I could always rely even on an old comment to help me understand the framework, with NextJS, I found constantly questioning if the information I was reading was stale or if a new library extension had already been developed to handle the thing I needed. It seemed like something I just needed to get used to. And while I was willing to just scotch this up as a NextJS thing, I quickly that this was a Javascript thing.

To be clear, none of the issues I encountered were taxing or impossible to fix, but I certainly felt vexxed because I believed the solutions were so trivial or inconclusive. I imagined that things could be easily averted with some communication, but then I read the comments from people who had gone through the much the same, and realized I wasn't the only one encountering the issue. I'm sure plenty of them had thought just the same. The Javascript development environment and library landscape constantly shifts under your feet!

Simple Meditations

After finishing the tutorials I decided on my next project. I wanted to make a meditation website. Something like Oak, but for laptops. The final product is hosted with Netlify: Simple meditation. The process for making this website was straightforward and easy, but I did learn a few things along the way.

The first thing I learned is that CSS class libraries like TailwindCSS can make web development a lot easier. I kind of already knew this, but I previously didn't want to jump into a CSS class library until I had a good grasp on CSS and had developed a sense for design, however rudimentary. I think approaching CSS this way made me appreciate libraries like this a lot more. For one, I didn't feel lost when searching for styles. And two, I had an easier time translating what I knew to what the library provided. I think what I found most interesting about the procedure was how seamlessly CSS libraries worked with React. It got me thinking if perhaps my issue with Django could have been averted in the same way, but that would have to be for another project.

The second thing I learned, is that typing in Javascript can be just as nice and easy as it is in Python. While it can always feel tedious to change the typing of a parameter or variable in development, I think the benefit of declaring explicit types can help data management, code development, and codebase organization in the long run, even if the code might not be revisited.

Finally, the last thing I learned, is that Javascript web development requires an understanding and appreciation of multiple standards. Mainly, the Javascript standard and the HTML standard. While I had initially used the DOM API in my blackjack app for element value manipulation, I didn't realize that the HTML standard was making this interaction possible with Javascript. Upon reflection, document.getElementById obviously doesn't make sense outside of HTML, but this also wasn't a thing most tutorials and introductions point out. In the end, Learning web development online is a fragmented mess, and while many pages do provide clear documentation, knowing where to look is part of the problem.

Conclusion

Working with web development tools across two languages has been an insightful experience. While there's still much to learn, I wanted to document my journey so far. Personally, I think switching to Javascript has made web development easier, but I still find myself coding in Python when thinking through problems. Writing Python is easier; it doesn't require as many mustached figures 🥸. But then again, writing JSON data blobs is as common in Python as it is in Javascript. So it seems apt to switch between the two.

I think my recent accomplishments have given me more confidence and motivation to keep coding and developing websites. I hope you enjoyed the read. Feel free to email me at ollycodes@pm.me if you have questions or comments! I really would appreciate it!