Hacker News Reader

You don't need more than what you have. You have essentially built a minimal MVC. Everything else you add is just stuff that other people added to other MVC projects to make life easier for them in some way. Web MVCs are basically just opinions on the way to handle HTTP requests and are meant to speed up the dev process if you agree with all of its boilerplating/tooling.

My only recommendation is to just keep yourself aware of url/form encodings, path handling, and common pitfalls related to handling HTTP requests in general.

cool, thanks for the insight. are there any materials you'd recommend for reading up on this kind of stuff? I have a fair bit of insight from having done things in various frameworks over the years, but if there's any resources you have in mind, I'd be more than happy to take a look.

I'm using Sveltekit and doing pretty much what you're doing, and never touched Rails before. I'm equally confused about the MVC pattern I hear so much, and why it was so big back then, and why it isn't very big now. Was this more of a design / architecture "fad" or a design around the constraints of the time?

MVC offered a formalized separation of concerns for data, ui, and business logic at a time when many developers were cramming all of their application code into massive php or C# files. The pattern was delivered via frameworks (RoR, Cake, Asp.net MVC) that handled a lot of the boiler plate for you and made for an easier development experience than what most of the people switching to it were used to at the time. As web applications became more focused on the client code, the template driven server side rendering capabilities of these frameworks was less useful or no longer necessary.

Initially when the mindshare began to move to the client code, front end tool chains actually did do a lot of hemming and hawing of what variant of mv* they were. Eventually tools like react came around and whatever variant of mv* they were wasn’t what was interesting about the building paradigm. More or less that’s where we are now.

one my wonder about what could this be:

> routes" (procedures, mapped to URL patterns, that execute logic such as accessing models (cached or queried)

A "route" that executes logic such as accessing models responding with an output based on what mime type was requested, can set a layout or template for the view ...

changing the name to "route" does not change the pattern that you are implementing here.

Rails Controllers are doing exactly everything that you describe here with the only exception that there is a big table that keeps references between a URL and the controller method associated with that URL.

I am not saying Rails is better than what you build, but just noticed that a lot of what you describe as a "route" is matching what a controller is doing.

it's been a very long time since I did anything with Rails… but I recall there being Ruby code in the "Views", which is something I'm choosing to avoid entirely. all logic is executed in the "Route" (or whatever it's called in the end) procedure, which is where, if you want to output HTML, you invoke a "Render" macro that takes in the template name and optionally any variables you want to pass in. the HTML templates have a simple, Mustache-like syntax (insert parameter, insert nested template/"partial"), but it's just plain HTML with some {{placeholdery-looking stuff}}. maybe I'll add a JSON "renderer" if I need it, and I still need to get static file loading to work, but other than that, this framework does pretty much everything I want to do as far as website backends go, and it compiles to a single executable. it's not going to be The Future Of Web Development, but it will be nice (for me at least) to make small-to-medium-sized websites with, in large part because it's much easier for me to reason about "Models (structs), Routes (code), Templates (HTML)" than "MVC", or at least, how I remember "MVC" feeling in Rails, and Django.

If you are building a framework to do that, you are probably just reinventing React

how so? I was under the impression React is a frontend framework, and I'm exclusively talking about the backend here.

(plus, my thing is compiled to a single executable and not using JavaScript.)

React is just a way to procedurally generate templated HTML in the frontend. You can do the same thing in the backend but it just makes rerenders more expensive which could matter depending on how input heavy your application is. For example, if you update a row in the table, do you have to reload the entire page or just the row?

my bad, I wrote "web application" above—I meant to say "website", like, year-2008-level-of-interactivity stuff. I'm neither interested in nor proposing a solution for anything on the frontend side of things at all, because I'd suspect you're correct, I would probably just reinvent React et al.