The First Real Blog Post

A new kind of blog post for a new kind of blog.

The First Real Blog Post

This file you're looking at right now is the very first blog post to my new platform for hosting my courses. I've been wanting to create a new kind of course hosting platform for a while, but never really had the time to sit down and work on it due to travel and other commitments. I've since been able to get very far on this latest idea mostly because everyone is now quarantined and we all have tons of free time.

My old system was written in something called Django, which is the very best web framework for a website in 1998, but today Django is an old convoluted piece of garbage. Maybe that's too harsh but after using modern JavaScript tools I can't see myself ever going back to something like Django again.

Enough with the Bureaucracy, Web Frameworks

I spent many years crafting professional websites with Django and Python, Ruby, Java, C, and every language you can ever think of and they all seem to have the same kind of affliction: It takes 6-10 files to show one webpage. All you want is to work on the design. You've got the idea in your head, burning an image of the thing you see (or you're just copying someone else's vision) and Django makes you fill out routes, classes, controllers, models, more classes, forms, validators, settings, database servers, and configure a web server. All you want is HTML and Django is making you fill out mountains of paperwork in triplicate to schedule the meeting to form the committee to establish the project plan for determining the size and color of the office the team will hold further meetings in.

I call the frameworks from this era the "Bureaucracy Web Frameworks", because you need to fill out endless forms and go through some opaque convoluted process just to do something simple. All you want is to work on that UI. All Django wants is for you to satisfy Django's paperwork requirements before it'll give you that HTML. We are all told this is "good for us", because we "should start with the model", but nobody refused to use a website because you failed to convert your SQL database to 3rd Normal Form. People refuse to use websites because the UI sucks, so getting that right is the most important thing.

I know, 'cause I've made more than my fair share of terrible UIs and after many years of forcing a UI centered process through the eye of the Bureaucracy Django needle, I'd rather use something that starts with the UI.

UI First Development

When I'm creating a website now I like to develop the frontend UI before start working on the backend. I'm definitely not a professional designer, but the frontend is really the most important part of web applications. If the UI's not usable then there's really no point working on all the controllers and models. Nobody will use it anyway so you're wasting effort. By focusing on how the website works and flows and looks, I'm able to sort out the functionality and the reality of how it is actually going to function.

Systems like Django, Ruby on rails, and anything from Java, tend to have a method where you start with the data. You'll sit down and craft of the data model work up the relationships in a database, figure out exactly how that works with some sort of model view controller system, then eventually, make a webpage. This is how I worked for decades mostly because nobody really cared about how websites looked. They only cared about how they worked (for banks, because Java).

The way systems like Django work requires you open up multiple file all focusing on the backend at the very beginning. If you just want to make a simple user interface show up, you have to open a routing file, a model file, a controller file, configuration file, and multiple other files just to get that one simple HTML page to appear in a browser. You also have to run all of this through a full Web server, and connect that to some kind of database.

Yet, when you're working on a web application you shouldn't need any web servers, controllers, routes, databases, models, or anything except a plain old file on the disk. You should just need HTML and CSS, but the nature of web browsers forces you to run a minimal amount of Web server technology just to make JavaScript work. My dream would be for browsers to stop being slaves to HTTP and let me run apps off the disk but, whatever, I'm just a programmer after all.

I find this incredibly frustrating and have been looking for an alternative for a long time. In recent years we've seen the rise of new frontend development frameworks that make this possible. Systems like React, Vue.js, but and Svelte, all make the model of web development change from backend focused to frontend focused.

After close to two years of research in these new technologies for JavaScript frontend development I was finally able to replace most of the technology that I used in Django, and then some. The new frameworks I'm using are much simpler much easier to work with, and end up allowing frontend first development. They also solve the major problem I have with frameworks from the past because they only require that I work on one file to get started.

Close, But Not Perfect

What you're using now is the result of quite a lot of research into how the systems work both for my own professional needs, and as something that I can teach to people as a sample project. This tends to make the development work a little more difficult, but I feel that people are much more interested in creating something that they actually can see in his real rather than yet another linked list.

What I have right now isn't perfect, by any means. I had to change database servers and write my own content generation system, but it's now at a point that I can use it to at least publish. Nothing is ever perfect, but given that I'm able to do so much more with the little bit I have here means it has room to grow an improve.

What's Working

Currently I have the majority of the features I need to host a few sample free courses. I can post blog posts, except logins, create user accounts very simply, host videos, images, audio, and full course content. The next stage is to actually use this system to create sample courses I want, and then to start charging people for the full courses.

The development work on this has been moderately smooth, but there are some things about Svelte that people should know before they start using it. I find that Svelte and Sapper are working very well, but that there's a few gotchas people need to know before they can get working on. And a future blog post I will talk about some of the things I ran into, and how you can work around them. I'll also cover the alternative systems and possibly even do a live session where I build the same UI in all three.

I will also cover big problems I had using Gulp, and ArangoDB which forced me to ditch them and go with something else entirely.

Bug Reports

There isn't much to use quite yet, but if you run into a weird layout problem then hit me up on Twitter @lzsthw and give me some screenshots. Thanks!

Ten Reasons Youtube's Streaming is Awful
Starting Free JavaScript Live Streams
How to Create Your Own `npm init` and Get Off
Stripe is Paypal circa 2010
See More...