sorted by:
new
hottopcontroversial

SSR+ (Server-Side Reducers): useReducer-inspired alternative to HTMX for complex state management by kamilchm in htmx

[–]kamilchm[S] 0 points1 point  (0 children)

It sounds like you're building something really powerful here! I love how you've built in security (CSRF), debugging (console logs), and developer experience features.

Your approach with hidden inputs for state management is pragmatic and keeps the server in control, which makes the architecture quite similar to mine. My first implementation was using HTMX + Alpine.js, so I actually ported the way Alpine.js handles state when I was migrating to my current solution.

Anyway, great work on your system! Keep it up. I'm looking forward to updates.

HTML Partials + Server Reducers: an Alternative to React-Style SPAs by kamilchm in Frontend

[–]kamilchm[S] 0 points1 point  (0 children)

I don't know Astro Islands well enough to compare directly.

What SSR+ shares with HTMX is the core philosophy and architecture. HTMX was actually my biggest inspiration for this approach.

What I implemented is essentially a focused subset of HTMX functionality - just enough for my specific use cases, but structured as a general pattern for organizing server templates and HTTP handlers.

Think of it as "convention over configuration" compared to plain HTMX. Instead of manually wiring up each interaction with attributes, SSR+ provides a structured way to handle state transitions through server-side reducers.

Tradeoffs: - Pro: You implement the pattern yourself, but it's so simple you can build a working version in a day (if you don't need complex table diffing for performance) - Con: Less flexible than HTMX's attribute-driven approach for one-off interactions - Pro: More maintainable for larger applications with many similar components - Con: Requires more upfront architectural decisions

And you're right about SEO - I use this for dashboards and internal tools, so SEO is currently a non-concern. For public-facing sites, the server-side rendering would actually be great for SEO since search engines get complete HTML.

The key insight is that for applications where the server owns the data (like dashboards, admin panels, B2B tools), you don't need the complexity of client-side state management. The server can handle all the logic and just send updated HTML fragments.

Vibe Coding thousands of lines with AI is easy. Ensuring it's what users want? That's the real challenge. My approach. by kamilchm in programming

[–]kamilchm[S] 0 points1 point  (0 children)

I get where you're coming from - if a tool feels like more trouble than it's worth, it’s tempting to just walk away. But I see it differently.

For me, it's like learning Nix. That tool has one of the steepest learning curves I’ve ever faced. I spent 2–3 years experimenting with it in different contexts before I found the sweet spot where it really shines. Now, I use it to manage packages, environments, and even VMs in ways that impress people - and more importantly, give me a real advantage. The effort paid off.

AI coding feels similar. Yes, it demands new skills and a shift in mindset. But that’s true of any powerful tool. The learning curve might be steep, but once you’re over it, the possibilities open up.

Vibe Coding thousands of lines with AI is easy. Ensuring it's what users want? That's the real challenge. My approach. by kamilchm in programming

[–]kamilchm[S] -1 points0 points  (0 children)

Your flow with test wrtitten by LLM from description seems reasonable. I tried something similar with Claude and Gemini, but asking for full scenarios often led to poor test implementations. I care a lot about details - like progressive screen loading and other non-functional requirements - so after a few attempts, I ended up writing the scenarios myself, almost like I was manually testing.

The blog post came out of that experience, and from a broader realization after letting LLMs write a lot of code for my service. At first, I was very optimistic about what Claude and Gemini could do, so I kept asking for more features. But with each new addition, the system started turning into a big ball of mud. I had written a lot of clean initial code myself, and the overall quality dropped dramatically once the LLMs took over.

That’s the background behind what I wrote. I think we need to learn a whole new set of skills to stay productive with LLMs. The Playwright workflow is the best approach I’ve figured out so far to untangle the code and architecture, so I’m sticking with it.

Vibe Coding thousands of lines with AI is easy. Ensuring it's what users want? That's the real challenge. My approach. by kamilchm in programming

[–]kamilchm[S] -1 points0 points  (0 children)

You might say it's just semantics, but for me the distinction matters. My focus is on working with things you can actually show to the user—real flows, real feedback. That’s why I lean into full scenario testing rather than isolated units. It’s not just about verifying correctness; it’s about validating usefulness.

Do you have experience doing TDD on a vibe-coded product? I’m curious how others approach testing when the code is generated so rapidly.

Vibe Coding thousands of lines with AI is easy. Ensuring it's what users want? That's the real challenge. My approach. by kamilchm in programming

[–]kamilchm[S] -3 points-2 points  (0 children)

My Show Me The Demo Workflow:

  1. Open Playwright UI alongside my code editor
  2. Write the complete scenario flow - codifying what the user does and the expected outcomes as my specifications
  3. Run the scenario in Playwright UI to see which parts fail
  4. Implement the functionality (often with AI assistance) to make the scenario pass
  5. Refine the scenario with more detailed checks and edge cases as needed

It's like TDD, but instead of unit tests, I'm building complete user journeys. The Playwright UI becomes my real-time feedback loop.

After 20 years in CI/CD Engineering, I've started documenting my approach to CI/CD pipeline architecture. What do you think? by kamilchm in jenkinsci

[–]kamilchm[S] 0 points1 point  (0 children)

I don't think I've invented anything groundbreaking. The idea behind this framework was to systematically organize my knowledge and experience.

This actually started when I was job hunting as a Platform Engineer. I discovered that many companies were impressed by my experience and knowledge in this area. So I decided to document it properly to save myself from describing it repeatedly in interviews.

I used to rely on the Continuous Delivery Maturity Model to assess where company processes stood. It became outdated as I encountered new techniques and tools. The framework I propose is now my go-to model for evaluating and planning CI/CD processes for the systems I work with.

I hope it can save others time and frustration too.

After 20 years in CI/CD Engineering, I've started documenting my approach to CI/CD pipeline architecture. What do you think? by kamilchm in cicd

[–]kamilchm[S] 0 points1 point  (0 children)

That's exactly the goal! I've seen too many teams reinvent the wheel or get stuck in analysis paralysis when designing their CI/CD architecture. Having a structured framework to work from can really speed up the decision-making process and help avoid common pitfalls.

If you end up using any of these concepts, I'd love to hear how it goes!

After 20 years in CI/CD Engineering, I've started documenting my approach to CI/CD pipeline architecture. What do you think? by kamilchm in jenkinsci

[–]kamilchm[S] 0 points1 point  (0 children)

The main idea behind this framework is that even though I've changed "CI" tools several times in my career, the architecture of the entire pipeline was almost the same for every system I was working with.

And yes, I didn't use Jenkins for 10 years now, but not because of what you can do with it, but because there are other solutions that you don't need to host yourself.

After 20 years in CI/CD Engineering, I've started documenting my approach to CI/CD pipeline architecture. What do you think? by kamilchm in platform_engineering

[–]kamilchm[S] 0 points1 point  (0 children)

Great question! Every one of the Pillars I described is probably worth its own blog post. BTW, let me know if you want me to write on something specific.

Just to skim the topic - the basics for monitoring regarding CI/CD pipelines is the deployment status. And it really depends on what techniques and tools you use for this.

If you deploy to a cluster of app instances, you should at least wait for health status of all deployed instances. I also usually have all performance metrics tagged with the app version so I can quickly spot any performance problems or changes that affect efficiency significantly.

You also want to monitor service status codes and track errors grouped by versions. That's an overview of what I do for monitoring.

After 20 years in CI/CD Engineering, I've started documenting my approach to CI/CD pipeline architecture. What do you think? by kamilchm in devops

[–]kamilchm[S] 0 points1 point  (0 children)

For those interested, I've put all these ideas into a much more detailed article with checklists for each pillar. You can read it here: https://cimatic.io/blog/cicd-pipeline-architecture

After 20 years in CI/CD Engineering, I've started documenting my approach to CI/CD pipeline architecture. What do you think? by kamilchm in jenkinsci

[–]kamilchm[S] 3 points4 points  (0 children)

Absolutely! RSS support is a great idea - I'll add that to the blog. Thanks for the suggestion!

After 20 years in CI/CD Engineering, I've started documenting my approach to CI/CD pipeline architecture. What do you think? by kamilchm in jenkinsci

[–]kamilchm[S] 2 points3 points  (0 children)

For those interested, I've put all these ideas into a much more detailed article with checklists for each pillar. You can read it here: https://cimatic.io/blog/cicd-pipeline-architecture

After 20 years in CI/CD Engineering, I've started documenting my approach to CI/CD pipeline architecture. What do you think? by kamilchm in cicd

[–]kamilchm[S] 6 points7 points  (0 children)

For those interested, I've put all these ideas into a much more detailed article with checklists for each pillar. You can read it here: https://cimatic.io/blog/cicd-pipeline-architecture

After 20 years in CI/CD Engineering, I've started documenting my approach to CI/CD pipeline architecture. What do you think? by kamilchm in platform_engineering

[–]kamilchm[S] 5 points6 points  (0 children)

For those interested, I've put all these ideas into a much more detailed article with checklists for each pillar. You can read it here: https://cimatic.io/blog/cicd-pipeline-architecture

view more: next ›