Things I've learned

So I've learned some things since my last post on here.

For one, people actually come to my little website. I did not know this. I haven't run any usage tracking stuff for a long time and just kind of figured it's a tiny blog thing which I don't advertise and I'm not famous, so it must get like 2 hits per year. I got bored and set up Google Analytics a few days ago and it turns out more people visit each day than I thought did in a year. Not tons. Not even a lot. More than I thought, though. That's pretty cool.

You don't have to use Django's forms all of the time and they might even hold you back. I've been doing Django work for a couple of years now and web-related dev work for around eight years. The vast majority of my work has been behind the scenes. Any UI that I needed to touch only needed to be functional. They were just UIs for in house developed software for other employees to use. I had grown pretty attached to the Django's forms. They're easy to create, easy to pop into the HTML, they do my validation and converting things into objects for me. They just work. That is, if you are doing a layout that fits the exact way they output HTML. My current job is public facing work and for a company, and so clients who come to this company, who value style very highly. During my first project with this employer I wasted countless hours trying to force Django forms into a layout that they just don't work for. The designer wanted to display data that wasn't available from the form object and laid out in ways that the form object just will not do. One example would be using custom radio and checkboxes, which require having the actual <input> and <label> elements in a specific order so that they can be targeted via css and Django just will not do it. I should note that it might be possible with something like crispyforms, but it was more effort for me to dig through the crispyforms docs than to just write the html outright and have it post back. I've lost a little bit of "it just works" magic in that I can't just change the form object and have the output form just work without me remembering to also go change them, but damn, the site looks so much better than anything I've done just spitting out Django forms however Django wants them to be.

Don't mix JavaScript and Django templates for serious work. It can be tempting, and initially save time, to use inline JavaScript and then you can use Django template tags and variables inside the JavaScript to dynamically build some of it. I've generally done this for URLs and to pre-fill JavaScript arrays of objects. For the simple UI sites I've done in the past, that was fine. I learned that once you thrown in JavaScript compression via something like django-compressor, that plan breaks down. That dynamically generated JavaScript only gets dynamically generated once and eventually it is incorrect, with bad urls or out of date arrays of objects. It's much easier to just keep as much of the JavaScript as possible in external .js files. Sometimes I will now use a small bit of JavaScript in the template ,which I do not intend to compress, just to pull in urls using the Django's url template tag and then pass those as parameters to the functions and objects in my external JavaScript files. I'm finding this also results in cleaner JavaScript.

Don't use languages that compile down to JavaScript. My particular experience is with CoffeeScript, but others will all have the same problems. I'm not going to go into much detail, I've talked about it before on here. The short version is that they add more steps and more dependencies to the build and deploy processes and make debugging more difficult because you're now debugging JavaScript you didn't write and probably would not have written that way and trying to figure out what code in a different language created that JavaScript output. Just write JavaScript. Typing semicolons isn't that bad.