This was an awesome talk. I've been trying to talk to other devs about this topic for years now, but I'm kinda bad at explaining myself :p About 6 years ago I was faced with a rewrite. Although it's true that hindsight is 20/20, there were some general things with the current project I wanted to see if I can avoid. 1. It felt very much like I was maintaining 2 apps... the front end app and the back end app and I had to keep both in sync as well. 2. Although most 3rd party tools I used worked, I often had to bend them to my will and often even override certain parts to get the exact result I wanted. Had quite a bit of bloat after 7 years of dev... 3. Businesses/Clients don't want to spend money on expensive hardware. So they always had low end, very old, or low end and old hardware that didn't like having to handle tons of JS. 4. I wanted to rather focus on long term productivity and maintainability. I think the industry is way to obsessed with "how fast can I build something today" and then 10 years later the company has millions of lines of code that was build with 3 different versions of whatever framework they chose and none of the original developers are there still. I could not find anything that fit what I wanted to do and HTMX wasn't a thing yet. So I came up with my own ideas and patterns and made the server do pretty much all of the work. It's really simple... user interacts with page, interaction is sent to server, server processes the interaction and updates State, and then IF needed... send back some HTML to update the UI. Came up with my own way to template HTML and a generator so I don't have to write any HTML by hand... I just define what I want and the generator spits out the actual HTML. No more typos messing things up :) I have zero 3rd party JS. The JS I do have is extremely simple and is mostly just to handle some user interactions... here and there... It is fast... real fast. Especially on devices with crappy SOCs like old handheld scanners. I have absolute control over how everything works... what updates, when, or how is an open book and I'm writing the book. I learned more about JS and CSS in 1.5 years than I did in the 12-ish years before... I've been working in software for almost 2 decades, but coming up with these ideas, building it, and it all actually working better than I hoped, was the best 1.5 years of my entire career. I didn't realize it at first, but for the first time in my career I was actually building something instead of sticking 3rd party pieces together. By no means am I saying everyone should dump what they are using and just roll it on their own... if there is an off the shelf tool that does exactly what you want or need, then use that.
i like the message and most of the points, but i gotta point out: he said not to use orms and in next step proceeded to write first lines of his new orm
That wasn't really the idea, though. :D Utility functions for creating SQL queries is pretty low-level compared to a full-blown ORM, where you're really working with an abstraction layer of entities, caches, relationship graphs, type mappings, and so on. And that then has its own intricacies and limitations you usually don't want to, and fairly often don't actually need to deal with.
I really though the first example was to point out how complexity grows due to edge cases. The conclusion I get is that you pick your own poison, you can't really escape complexity. In a lot of cases we just query a database, render HTML and send it to the user any tool can solve that until weird requeriments and bugs start appearing.
He's not talking about complexity but about OVERcomplexity. Complexity is always aroud. But it's better to face it than hidding under the rug. I've been facing it for way more than 20 years and experience lead me to better solutions every day. With frameworks you learn the framework, not the actual problem and then you have to learn other frameworks to do just the same… (precious time wasted). …and when you finally face a non trivial problem you find out the framework has no (or at least no good) solution for it and have to circumvent it to achieve your goal. But then you have too much code depending on the framework to escape… Of course: Frameworks also make developers cheap for the companies because they have plenty of juniors trained in all most trendy ones disposed to work for a few bucks in complex code they're far from understanding…
I don’t understand. He says don’t use React because it’s complex, then promotes htmx which is complex. Advises not to use ORMs, then writes one. Hello?
HTMX's declarative nature is precisely the reason it is _not_ a complex tool. With regards to the ORM question: there is a huge difference between importing a third party solution that obfuscates implementation and db-specific features, and writing a couple of dozen lines of utility functions.
@@chrsbll So we don't import complexity created by others but created ourselves. I don't think we can escape complexity but there is a point when we should stop.
HTMX seems much more complex to me than React. Just taking a look at their documentation terrified me. Yes, there’s a huge difference I agree. I prefer importing a solution from a third party developed by people much smarter than me on the matter. Maybe if I need just one/two functions I would consider writing them myself but again that rarely happens.
Yeah, I'm not 100% happy with how this turned out, either. Tried to cut what really was a 50-minute presentation down to 30 at the last second. Add nerves on top of that, and now it's just 20 minutes anyway. Will be better the next time around. :) In the meantime, happy to try and explain any contradictions.
@robertholts Calm down, think about the topic again and make a better comment. I think this comment was "Rushed. Nervous. Contradictory." probably like your work ethic. If this is how you treat a peer in the industry I would hate to work with you...
Thanks for an awesome talk
This was an awesome talk. I've been trying to talk to other devs about this topic for years now, but I'm kinda bad at explaining myself :p
About 6 years ago I was faced with a rewrite. Although it's true that hindsight is 20/20, there were some general things with the current project I wanted to see if I can avoid.
1. It felt very much like I was maintaining 2 apps... the front end app and the back end app and I had to keep both in sync as well.
2. Although most 3rd party tools I used worked, I often had to bend them to my will and often even override certain parts to get the exact result I wanted. Had quite a bit of bloat after 7 years of dev...
3. Businesses/Clients don't want to spend money on expensive hardware. So they always had low end, very old, or low end and old hardware that didn't like having to handle tons of JS.
4. I wanted to rather focus on long term productivity and maintainability. I think the industry is way to obsessed with "how fast can I build something today" and then 10 years later the company has millions of lines of code that was build with 3 different versions of whatever framework they chose and none of the original developers are there still.
I could not find anything that fit what I wanted to do and HTMX wasn't a thing yet. So I came up with my own ideas and patterns and made the server do pretty much all of the work. It's really simple... user interacts with page, interaction is sent to server, server processes the interaction and updates State, and then IF needed... send back some HTML to update the UI.
Came up with my own way to template HTML and a generator so I don't have to write any HTML by hand... I just define what I want and the generator spits out the actual HTML. No more typos messing things up :)
I have zero 3rd party JS. The JS I do have is extremely simple and is mostly just to handle some user interactions... here and there...
It is fast... real fast. Especially on devices with crappy SOCs like old handheld scanners.
I have absolute control over how everything works... what updates, when, or how is an open book and I'm writing the book.
I learned more about JS and CSS in 1.5 years than I did in the 12-ish years before...
I've been working in software for almost 2 decades, but coming up with these ideas, building it, and it all actually working better than I hoped, was the best 1.5 years of my entire career. I didn't realize it at first, but for the first time in my career I was actually building something instead of sticking 3rd party pieces together.
By no means am I saying everyone should dump what they are using and just roll it on their own... if there is an off the shelf tool that does exactly what you want or need, then use that.
Cool presentation
HTMX is the future for sure
i like the message and most of the points, but i gotta point out: he said not to use orms and in next step proceeded to write first lines of his new orm
That wasn't really the idea, though. :D Utility functions for creating SQL queries is pretty low-level compared to a full-blown ORM, where you're really working with an abstraction layer of entities, caches, relationship graphs, type mappings, and so on. And that then has its own intricacies and limitations you usually don't want to, and fairly often don't actually need to deal with.
I really though the first example was to point out how complexity grows due to edge cases.
The conclusion I get is that you pick your own poison, you can't really escape complexity.
In a lot of cases we just query a database, render HTML and send it to the user any tool can solve that until weird requeriments and bugs start appearing.
He's not talking about complexity but about OVERcomplexity.
Complexity is always aroud. But it's better to face it than hidding under the rug.
I've been facing it for way more than 20 years and experience lead me to better solutions every day.
With frameworks you learn the framework, not the actual problem and then you have to learn other frameworks to do just the same… (precious time wasted).
…and when you finally face a non trivial problem you find out the framework has no (or at least no good) solution for it and have to circumvent it to achieve your goal.
But then you have too much code depending on the framework to escape…
Of course: Frameworks also make developers cheap for the companies because they have plenty of juniors trained in all most trendy ones disposed to work for a few bucks in complex code they're far from understanding…
I don’t understand. He says don’t use React because it’s complex, then promotes htmx which is complex. Advises not to use ORMs, then writes one. Hello?
HTMX's declarative nature is precisely the reason it is _not_ a complex tool. With regards to the ORM question: there is a huge difference between importing a third party solution that obfuscates implementation and db-specific features, and writing a couple of dozen lines of utility functions.
@@chrsbll So we don't import complexity created by others but created ourselves.
I don't think we can escape complexity but there is a point when we should stop.
@@neociber24Then I think our definitions of "complex" must be very different.
HTMX seems much more complex to me than React. Just taking a look at their documentation terrified me.
Yes, there’s a huge difference I agree. I prefer importing a solution from a third party developed by people much smarter than me on the matter. Maybe if I need just one/two functions I would consider writing them myself but again that rarely happens.
You know they have no effin clue what they're talking about when they say HTMX is complex..
Rushed. Nervous. Contradictory.
Yeah, I'm not 100% happy with how this turned out, either. Tried to cut what really was a 50-minute presentation down to 30 at the last second. Add nerves on top of that, and now it's just 20 minutes anyway. Will be better the next time around. :)
In the meantime, happy to try and explain any contradictions.
Dude haters gonna hate. Rude comment
@robertholts Calm down, think about the topic again and make a better comment. I think this comment was "Rushed. Nervous. Contradictory." probably like your work ethic. If this is how you treat a peer in the industry I would hate to work with you...