I think this is the gist of it. Tables were abused as general spaced 1D, and 2D styling components. Introducing proper general spacial styling components means we don't need to extend tables beyond their original purpose, but doesn't mean we shouldn't use them for that purpose!
Sure. In terms of making a decision, yes, in the healthy process, there should be a person with a formal power to decide (and take responsibility) eventually.
I was more curious about the discussion when the parties were speaking on the same level of command.
One way you can do that is to bring the business stakeholders into the discussion. This will help uncover implicit assumptions that may be being made about business needs. The business stakeholders can also help determine how the pros/cons of each solution impact the business and which they're more comfortable with. Business stakeholders won't be able to discuss technical merits, but they can discuss business impacts. This is also a great opportunity to build rapport with your business stakeholders because they learn you're not just a cog in the machine cranking out code. They learn the things to think about and see you more as a valued partner rather than a line item than can be cut to reduce expenses.
One way is to lead the discussion by asking questions and facilitating. You may learn something from others, they see you as thoughtful (and senior), and when necessary you can steer the conversation.
Agree, I wasn’t consistent with “a framework” vs “just language” approach. Ideally it should be 100% one or another.
My idea was to use the standard library as much as possible, but I didn’t eliminate the use of third party libraries entirely if it would allow async/concurrent processing.
It all started with Go vs Rust vs Zig as the main point of comparison. Then I added more languages I am familiar with.
By far, IMHO, Go is a clear winner in terms of being 100% with the standard library, fully concurrent and quite concise.
Sure, JS/TS implementations are also concise but it is different, not natively compiled technology.
The language's selection is purely my personal familiarity, so nothing wrong with Java, it’s just not my area.
Has anyone used htmx for a more or less large project?
Everything turns into spaghetti code really quickly.
Separation of API and frontend isn’t just for fun. It’s for making testing bearable.
Finally, mixing data modelling (database) with presentation (html output) in one place (htmx handler) goes out hand really quick too, making testing much harder.
But real coding cowboys from the golden age don’t write tests, right? :-)
Depending on what you mean by large, I have. Testing is just the same as on any server-side MVC application. And I don't get spaghetti, because the structure is provided by the backend framework. Same with the data modelling - there's a model layer in the backend project that can be tested independently of everything else.
I can only guess that you're trying to put all your logic and structure on the front-end, with the backend only serving what the front-end needs ad-hoc? Don't do that. Build a classic MVC app (Django, Rails, ASP.NET MVC), factor your views into small, reusable components, and use HTMX to replace page elements at that level.
Similar concept and functionality. jQuery plugin attach events like "x-post" and other attributes, sends data to server which always returns HTML.
800+ CRUD pages full of business logic, around 2k routes, single PHP server, single MySQL server, serves up to 3k requests per second seasonally, P95 around 50ms.
Team still adding and changing features every 2 weeks, even after years in production. Stack is custom PHP framework, MySQL, custom jQuery plugin that acts similar to htmx.
Onboarding is dead easy. It was made with a no-build frontend stack. Meaning there's no build pipeline to understand and fight against.
I look at React/SPA misuses and self inflicted pain, and feel sorry for them.
This feature of Go tool chain is so underrated. Yes, there is nothing magical here. I can achieve similar outcome with some custom preprocessing, but having it built into the ecosystem, with type checking and inferencing, single binary compilation, etc. is a great productivity booster.
staging or index is one of the most beloved by me features of git. It saved my careless butt from loosing files SO many times. I stopped counting. Severely underrated, even complained about to be confusing.
I’m always puzzled when people say than git is hard, confusing etc. Is English hard to learn? Russian? Chinese? It depends, as always.
Yep, it’s a learning curve, and as deeper understanding comes, in more ways you start bending this great tool (git).
There is an endless ocean of toolings, helpers etc of all kinds, for all levels.
I’m not saying git is the best. There is no the best tooling in general. Fossil is great, git is great, and some other VCS. Pros and cons are everywhere.
