DEV Community: Justino Contingo

Rebuilding an Abandoned Laravel Page Builder With a JSON-Based Architecture

Justino Contingo — Sun, 07 Jun 2026 20:19:06 +0000

Submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I built a Laravel Page Builder that allows developers to create and manage pages through a visual drag-and-drop interface.

Unlike most page builders that rely heavily on database storage, this project takes a different approach: page layouts are stored as JSON files directly in the filesystem.

The idea behind this decision was simple:

Pages become portable
Content can be versioned with Git
Deployments become easier
Developers can review page changes through pull requests
No dependency on SQL or NoSQL storage for page definitions

The goal wasn't just to create another page builder, but to explore an alternative architecture for page composition within Laravel applications.

Current Features

Drag-and-drop page builder
Modular block-based architecture
JSON filesystem storage
Livewire v3 integration
Editable headers and footers
Import and export functionality
Custom block support
Multi-language support

The project is currently a working prototype, but it already demonstrates the core concept and architectural direction.

Repository

https://github.com/Justino-code/pagebuilder

Project Evolution

To make the progress made during the challenge transparent, I preserved two separate branches:

Before

https://github.com/Justino-code/pagebuilder/tree/before-changes

After

https://github.com/Justino-code/pagebuilder/tree/after-changes

These branches show the project's state before and after the redesign and refactoring work completed during the challenge.

Screenshots

Project screenshots can be found here:

https://github.com/Justino-code/pagebuilder/blob/main/docs/screen.md

The Story Behind the Project

This project actually started long before the challenge.

The original idea was to build a page builder centered around a filesystem-first philosophy, where page definitions would live as JSON files rather than database records.

While the concept was promising, the project eventually stalled and was left unfinished.

The GitHub Finish-Up-A-Thon provided the perfect opportunity to revisit the idea and determine whether it was worth pursuing.

Instead of trying to build every planned feature, I focused on validating the architecture, improving the internal structure, and delivering a functional prototype.

During the challenge I:

Reworked the block architecture
Improved page composition workflows
Refactored major portions of the codebase
Expanded customization capabilities
Clarified the long-term direction of the project

The biggest achievement wasn't adding a specific feature.

It was proving that the concept works.

Today, the project has evolved from an abandoned experiment into a functional foundation that can continue to grow.

My Experience with GitHub Copilot

GitHub Copilot played an important role throughout the development process.

It helped accelerate implementation by assisting with:

Laravel and Livewire boilerplate generation
Refactoring repetitive code
Block rendering improvements
TailwindCSS UI development
Exploring alternative implementations during redesign

Rather than replacing decision-making, Copilot acted as a productivity multiplier, allowing me to spend more time thinking about architecture and less time writing repetitive code.

Final Thoughts

For me, this challenge wasn't about shipping a finished product.

It was about finishing a phase of development.

Given the available time, I prioritized validating the idea and rebuilding the core functionality instead of focusing on perfect architecture or extensive polishing.

There is still a lot of work ahead, including improvements to structure, design patterns, developer experience, and overall refinement.

But the most important milestone has been reached:

The concept is validated.

What started as an abandoned idea is now a working prototype and a solid foundation for future development.

And that, for me, is exactly what the Finish-Up-A-Thon was about.

Will junior developers disappear because of AI?

Justino Contingo — Fri, 05 Jun 2026 20:19:09 +0000

Over the past few months, I've seen many people claim that junior developers will disappear because of AI.

I'm not convinced that's what's happening.

My impression is that we're witnessing something different: a technological transition that may redefine how software development is learned and practiced.

This isn't the first time the industry has gone through a major shift.

Personal computers changed how people worked.

The Internet changed how people accessed information.

Smartphones changed how people interacted with technology.

None of these innovations eliminated the need for professionals.

What they did change were the skills that professionals were expected to have.

That's why I wonder if we're asking the wrong question.

Instead of asking:

"Will junior developers disappear?"

Perhaps we should ask:

"What will it mean to be a junior developer in an AI-assisted world?"

The traditional distinction between junior, mid-level and senior developers is not just about writing code.

It reflects differences in:

experience
responsibility
decision-making
understanding of trade-offs
ability to work with uncertainty

I don't see those differences disappearing.

What may change are the skills expected at each level.

For example, today it is becoming increasingly common for developers to use AI tools to:

generate code
explore solutions
review implementations
explain concepts
accelerate routine tasks

As these tools become part of everyday development, the ability to use them effectively may become a standard expectation rather than a differentiator.

However, using a tool is not the same as understanding a problem.

Software development still requires people who can:

understand requirements
evaluate solutions
identify limitations
make technical decisions
understand trade-offs

In my experience, AI often makes implementation faster.

What it doesn't remove is the need for judgment.

In some situations, it may even make judgment more important.

A generated solution can work and still be inappropriate for the context.

A recommendation can be technically correct and still introduce unnecessary complexity.

These are not problems that disappear simply because code can be generated more quickly.

For that reason, I don't think we're necessarily witnessing the disappearance of junior developers.

What I think we may be witnessing is the evolution of what being a junior developer means.

The industry has adapted to major technological changes before.

It will likely adapt again.

The interesting question is not whether developers will disappear.

It's how the expectations placed on developers will change.

What do you think?

Are junior developers disappearing, or are we simply redefining the skills that will be expected from them?

The biggest challenge I've found when using AI for programming

Justino Contingo — Mon, 01 Jun 2026 07:08:43 +0000

The hardest part of using AI for programming isn't writing prompts

I've been using AI tools quite frequently during software development.

They help with many tasks:

exploring ideas
generating boilerplate code
reviewing implementations
explaining concepts
proposing alternative solutions

Most of the time, getting an answer is not the difficult part.

The difficulty starts after the answer is generated.

A generated solution can look convincing.

It can compile.

It can pass tests.

It can even solve the immediate problem.

But that doesn't necessarily mean it's the right solution.

Recently, I asked an AI assistant for help solving a programming problem. The generated solution worked and produced the expected output. At first glance, it seemed completely reasonable.

However, after reviewing it more carefully, I realized that the implementation introduced unnecessary complexity that wasn't required by the problem. The solution was technically correct, but not appropriate for the context.

That experience reinforced an important lesson:

A working solution and a good solution are not always the same thing.

Questions often remain:

Does it actually solve the problem I'm trying to solve?
Is it aligned with the requirements?
What trade-offs does it introduce?
Will it still make sense as the system grows?
Is there a simpler approach?

This is where software engineering still matters.

The value isn't only in producing code.

It's in understanding the problem well enough to evaluate whether a proposed solution makes sense.

The more I use AI, the more I realize that these tools don't remove the need for knowledge and critical thinking.

In some ways, they make them even more important.

Without context, it's easy to accept an answer simply because it looks correct.

With context, you can challenge assumptions, identify limitations, and adapt solutions to the actual problem.

For me, AI has been most useful not as a replacement for understanding, but as an accelerator for it.

It can generate possibilities.

But deciding which possibility is appropriate still requires analysis and judgment.

That's been my experience so far.

What has been the biggest challenge you've encountered when using AI for software development?

Debugging Node.js? console.log isn't enough anymore

Justino Contingo — Thu, 28 May 2026 10:17:30 +0000

We've all been there.

Deeply nested objects. Circular references. Repeated structures.

At some point, you stop debugging and start trying to understand what you're even looking at.

That's why I built DumpKit — a small debugging tool inspired by Laravel's dump() and dd(), designed for Node.js.

import { dump } from 'dumpkit';

dump(complexObject);

It handles common debugging pain points:

Safe handling of circular references
Support for shared references
Large and deeply nested structures

You can also inspect data in different formats:

dump(data, { view: 'tree' });   // hierarchical view
dump(data, { view: 'table' });  // structured collections

Another useful feature is dump and pause (dp):

await dp(data);
// Execution pauses until you press ENTER

This makes it easier to inspect application state at critical points in execution.

DumpKit also exposes a structured internal representation (AnalysisNode), which can be used to build custom debugging tools on top of it.

DumpKit doesn't replace the console.

It simply gives you more clarity when complexity grows beyond simple logs.

Debugging isn't just about finding bugs — it's about understanding structure.

GitHub: https://github.com/Justino-code/dumpkit