3 ms·

While I mostly agree... there's something to be said for a simpler, server-driven stack. HTMX is particularly interesting as a point for server driven integrat

While I mostly agree... there's something to be said for a simpler, server-driven stack. HTMX is particularly interesting as a point for server driven integration(s). Many (most) apps are for internalized use at a given company... there's a lot of corporate development and most of these applications can scale perfectly fine with a relatively simple stack backed by a traditional RDBMS. It's usually somewhere between 10k users and 1m users where the rules change entirely and you need to start looking to more modern/advanced approaches. 10k is kind of arbitrary, because you can do some really stupid things with a traditional rdbms with sql.

solardev 3y ago
Sure, nothing wrong with a simple server-side stack. But even then, you probably wouldn't write it (today) by spinning up Microsoft SQL Server on a bare-metal machine so that your sysadmin can maintain its records with MS Access, then writing a bespoke CMS by creating your own prepared SQL statements from scratch, all while making sure your designer knows Frontpage and that you have a WAP version ready to roll out soon. It's not that the principles are invalid these days, but that the specific examples and techniques mentioned in that text are now often done with different tooling. Significantly, a lot the low-level stuff has also been replaced with higher-level, industry-standard abstractions (which embody many standard best practices that might otherwise take an individual years to learn and polish), building upon the lessons and mistakes learned over the decades. This text doesn't really clarify what is a long-lasting architectural principle and what was just a fashion trend of the day and now obsolete. Realistically, I think new devs coming into the field these days are likely to first encounter those abstractions (whether it's HTMX or Next) before understanding the history of why they exist (and what their tradeoffs are). Those architectural tradeoffs are important to learn at some point, but usually those decisions are not left to the newcomers (in a sane company) and also should be taught in the context of modern tooling and decisions, not software that was common two decades ago. Like important questions these days might be (as you said) what do we do on the server vs client JS (or rehydration), what do we outsource to a cloud (which clouds?), what do we containerize or not, how do we deal with HTTPS and mobile and cross-platform (web/iOS/Android), etc. Not "what is the best log parser for Apache" or "should we use MS SQL because it works better with Access". In some companies, it might also be "which off-the-shelf CMS best fits our use case" vs "Is C# or Java or more appropriate for our backend?" If someone wants to take the time to highlight the specific, still-relevant sections of that text, I think it could be worthwhile. But otherwise, without that differentiation, it's just kinda a minefield for newcomers.
- tracker1 3y ago
  That's fair... I hadn't really taken in the referenced article(s), only wanted to note, that there's still a place for a simpler vertical stack. As to MS-SQL, I don't think I'd recommend it for any purpose where it isn't already entrenched. Same for any commercial SQL based RDBMS (Oracle, DB2, etc) in favor of PostgreSQL or a largely compatible implementation. Aside: Right now, exploring HTMLX + server-side yew for rendering in rocket (rust), which could be very interesting. Usually do https termination at the platform, or reverse-proxy via Caddy. And I'm a proponent of containerizing all the things (Docker).

solardev 3y ago

Sure, nothing wrong with a simple server-side stack. But even then, you probably wouldn't write it (today) by spinning up Microsoft SQL Server on a bare-metal machine so that your sysadmin can maintain its records with MS Access, then writing a bespoke CMS by creating your own prepared SQL statements from scratch, all while making sure your designer knows Frontpage and that you have a WAP version ready to roll out soon. It's not that the principles are invalid these days, but that the specific examples and techniques mentioned in that text are now often done with different tooling. Significantly, a lot the low-level stuff has also been replaced with higher-level, industry-standard abstractions (which embody many standard best practices that might otherwise take an individual years to learn and polish), building upon the lessons and mistakes learned over the decades. This text doesn't really clarify what is a long-lasting architectural principle and what was just a fashion trend of the day and now obsolete. Realistically, I think new devs coming into the field these days are likely to first encounter those abstractions (whether it's HTMX or Next) before understanding the history of why they exist (and what their tradeoffs are). Those architectural tradeoffs are important to learn at some point, but usually those decisions are not left to the newcomers (in a sane company) and also should be taught in the context of modern tooling and decisions, not software that was common two decades ago. Like important questions these days might be (as you said) what do we do on the server vs client JS (or rehydration), what do we outsource to a cloud (which clouds?), what do we containerize or not, how do we deal with HTTPS and mobile and cross-platform (web/iOS/Android), etc. Not "what is the best log parser for Apache" or "should we use MS SQL because it works better with Access". In some companies, it might also be "which off-the-shelf CMS best fits our use case" vs "Is C# or Java or more appropriate for our backend?" If someone wants to take the time to highlight the specific, still-relevant sections of that text, I think it could be worthwhile. But otherwise, without that differentiation, it's just kinda a minefield for newcomers.

tracker1 3y ago
That's fair... I hadn't really taken in the referenced article(s), only wanted to note, that there's still a place for a simpler vertical stack. As to MS-SQL, I don't think I'd recommend it for any purpose where it isn't already entrenched. Same for any commercial SQL based RDBMS (Oracle, DB2, etc) in favor of PostgreSQL or a largely compatible implementation. Aside: Right now, exploring HTMLX + server-side yew for rendering in rocket (rust), which could be very interesting. Usually do https termination at the platform, or reverse-proxy via Caddy. And I'm a proponent of containerizing all the things (Docker).