DEV Community: Arnaud Denoyelle

From Wow to Oops: The Vibe Coding Reality Check

Arnaud Denoyelle — Tue, 12 Aug 2025 09:50:55 +0000

AI is having its “gold rush” moment.

Every week, there’s a new tool promising you can “build an app in minutes” — just type a prompt and watch the magic happen.

Non-technical folks see it and think: “Wow, developers must be 100x faster now.”
But here’s the thing: the magic trick only works from the right angle.

In this article, I’ll unpack why the reality is messier and how to use AI productively without falling for the hype.

Note : What I call vibe-coding is creating an application almost without writing any code, relying solely on prompts. This is in contrast to LLM-assisted coding, where the developer creates the project and occasionally uses prompts to complete it.

The illusion of application generators

I fully agree with the description given here:

My Trip to Vibe Coding Hell. Let me start by saying that I use AI to… | by Brian Jenney | Medium

Brian Jenney ・ May 15, 2025 ・
brianjenney.Medium

Your manager reads a few LinkedIn posts about AI, tries an application generator, and suddenly expects you to work 100 times faster.

But that’s not how it works.

A developer often spends more time reading code than writing it

especially when the code was generated by AI.

So, no—you won’t code 100 times faster with AI. At least, not today.

Many have tried this: go to an application generator (Replit, Lovable, Bolt, V0), enter a prompt, and receive a “working” app.

It feels like “AI built it”. In reality, it’s closer to “AI finished it”.

Most generated apps are 80% boilerplate, 20% actual features — and that boilerplate is almost always pre-written by humans

Think of the boilerplate as the foundation of a house—the technical groundwork before construction begins. In software, that means setting up tools, a database, a server, basic page structures, etc.

When developers code manually, this boilerplate is what takes the most time at the beginning. Generators just clone a boilerplate and sprinkle AI-generated features on top.

That’s why the first prompt often delivers impressive results, but subsequent prompts fail to produce the same value.

Right now, you can’t realistically expect AI tools to generate large, production-ready applications from scratch.

They’re still best suited for:

Ideation
Design team support
Small personal tools

Typically, the design team can test prompts with style constraints, color palettes, fonts, etc., and see the results live while generating multiple mockup proposals.

The Hidden Complexity

You ask the AI to make a login/password form.

It gives you a form with two fields and a button. You think that’s it? That’s the “happy path,” the nominal case.

But alongside that, you also have to handle all the other cases:

Data validation (show the field in red if it’s empty, etc.)
Extra features (auto-fill, global styling, etc.)
Is it responsive?
Handle error messages
If the password is wrong, allow another attempt (or not)
If the address doesn’t exist, suggest signing up
If an unexpected error occurs? “Please try again later”
Handle abuse

What about someone trying to brute-force a password? Just for that, you have to go through a whole process of setting up a captcha, with Google API calls, etc.

And what about someone attempting an SQL injection?

Extra features:

What if I forgot my password? You need a separate form, with an email being sent. That’s another whole process in itself.
And what if I want to log in with a Google account instead? That’s another separate process to set up OAuth.

You need to think about handling all these cases (and actually know they exist in the first place), and it takes time to deal with them, even with AI — if only to simulate/test that you’re handling them correctly.

The Real Story Behind Productivity Curves

Junior – Starts quickly but maintains a slow overall pace.
Senior – Invests time upfront to build a solid boilerplate, then accelerates and eventually outpaces everyone.
Vibe coding – Bursts out of the gate with impressive speed, but soon crashes into the vibe coding wall — where lack of structure and growing complexity drain momentum.

There’s a zone where the developer has to explain to their manager that, no, vibe coding won’t actually make us faster. This is tricky, because from the manager’s perspective, things currently look very different. Navigating this moment requires clear communication and strong teaching skills.

The Dangers of Vibe Coding

Sometimes, managers just want to ship code quickly, regardless of quality.

There are two major risks with AI-generated code: security and skyrocketing costs.

Application generators often allow users to write code without understanding it—creating high security risks. I expect many generated apps will leak user data simply because their creator doesn’t truly understand how they work.

If you can’t explain your code, you can’t secure it.

There’s also the financial risk: AI can produce inefficient code that consumes vastly more resources than necessary — sometimes even getting stuck in infinite loops — leading to bills in the hundreds of thousands.

Rule of thumb: never run code you don’t fully understand.

The AI Moore’s Law

Source : https://theaidigest.org/time-horizons

There’s a so-called AI Moore’s Law, suggesting that AI’s “time horizon” doubles every 7 months:

Initially, AI could do in 30 seconds what a coder could do—success rate 50%.
Seven months later, it could handle 1-minute tasks.
Today, it can handle 1-hour tasks (still with a 50% success rate).

But remember—a typical software project can represent decades of development (5–10 developers over 2–3 years).

If the trend continues, AI could match one month of coding by 2030. Even then, that won’t be enough for fully automated software creation for non-developers.

For developers, though, this is still a huge advantage—AI will be able to take on increasingly large chunks of work.

LLM-Assisted Development

// Detect dark theme var iframe = document.getElementById('tweet-1953531950137815374-297'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1953531950137815374&theme=dark" }

We don’t need to wait for fully autonomous AI.
If AI can do an hour’s worth of coding with a 50% success rate, it can also:

Do 30 minutes with ~70% success (70%² ≈ 50%)
Do 15 minutes with ~84% success (84%⁴ ≈ 50%)

That’s already a massive time saver.

Developers are also learning to distinguish between tasks AI can and cannot handle.

Right now, AI is especially effective for:

Spotting bugs
Writing and updating documentation
Creating automated tests
Developing small features
Drafting development plans

These use cases will only expand.

It’s also becoming easy to “train” AI to code in a specific style.

You can give it a file describing:

How you build forms (with examples)
How you handle database requests

And it will follow your style for repetitive tasks, leaving you to connect everything together.

How to Work with AI Today

AI offers both opportunities and risks. The key is understanding its current limits to avoid unrealistic expectations.

There won’t be an “AI big bang” but rather a steady, continuous adoption.

AI won’t replace developers tomorrow. But developers who know how to work with AI — and know its limits — will replace those who don’t.

So my advice is simple:

Experiment daily
Learn what AI can and can’t do
Never ship code you don’t understand
Regularly test whether past limitations have improved
Invest in communication — Learn to clearly explain AI’s limits and trade-offs to non-technical stakeholders

Vibe-coding can be a great creative tool — just don’t confuse the demo for the delivery.

Have you tried vibe-coding yet? What worked for you, and what blew up in your face?

Double bind the foreign key to avoid unnecessary JOIN in TypeORM

Arnaud Denoyelle — Sat, 23 Mar 2024 18:38:02 +0000

ORM tools are cool but they generate SQL "automagically". The generated code tends to be unnecessarily complex and causes a performance overhead.

In a database, performance depends on the time to compute the information + the time to bring this information back to the server.

In this article, I will show how to reduce the computation time by removing some unnecessary JOINs and how to load only the information you need.

The model

In this article, we will use the simplest possible model :

A table called company
A table called employee

mapped like this :

@Entity({ name: "company" })
export class CompanyEntity extends BaseEntity {

  @PrimaryGeneratedColumn({name: "id"})
  id: string;

  @Column({ name: "creation_date"})
  creationDate: Date;

  @Column({ name: "name"})
  name: string;
}

@Entity({ name: "employee"})
export class EmployeeEntity extends BaseEntity {

  @PrimaryGeneratedColumn()
  id: string;

  @Column({ name: "creation_date" })
  creationDate: Date;

  @Column({ name: "first_name" })
  firstName: string;

  @Column({ name: "last_name" })
  lastName: string;

  @JoinColumn({name: "company_id"})
  @ManyToOne(() => CompanyEntity)
  company: CompanyEntity;
}

Preparation : Activate logging on the local environment

To spot optimization problems early, you should always log the generated SQL at least in your local environment. You can do so using the logging option from the TypeORM configuration

  createTypeOrmOptions(): TypeOrmModuleOptions {
    return {
      type: "postgres",
      host: "localhost",
      port: 5432,
      database: "acme",
      username: "acme",
      password: "acme",
      schema: "acme",
      logging: true, // <= Here !
      entities: [
        CompanyEntity,
        EmployeeEntity
      ],
      synchronize: false
    }
  }

In this way, TypeORM will output the generated SQL in logs, which is a huge help for debugging. Here is an example of output :

query: SELECT "EmployeeEntity"."id" AS "EmployeeEntity_id", "EmployeeEntity"."creation_date" AS "EmployeeEntity_creation_date", "EmployeeEntity"."first_name" AS "EmployeeEntity_first_name", "EmployeeEntity"."last_name" AS "EmployeeEntity_last_name", "EmployeeEntity"."company_id" AS "EmployeeEntity_company_id" FROM "acme"."employee" "EmployeeEntity"

In this article, we will rely on that to show the code generated by TypeORM

Double bind the foreign key

Suppose that your application has already loaded the list of companies and you want to get the list of employees for one specific company, knowing it's companyId

The naive implementation would be this :

findByCompanyId(companyId: string) {
  return this.employeeRepository.findBy({
    company: {
      id: companyId
    }
  })
}

But let's have a look at the generated SQL :

SELECT "EmployeeEntity"."id"            AS "EmployeeEntity_id",
       "EmployeeEntity"."creation_date" AS "EmployeeEntity_creation_date",
       "EmployeeEntity"."first_name"    AS "EmployeeEntity_first_name",
       "EmployeeEntity"."last_name"     AS "EmployeeEntity_last_name",
       "EmployeeEntity"."company_id"    AS "EmployeeEntity_company_id"
FROM "acme"."employee" "EmployeeEntity"
  LEFT JOIN "acme"."company" "EmployeeEntity__EmployeeEntity_company"
    ON "EmployeeEntity__EmployeeEntity_company"."id" = "EmployeeEntity"."company_id"
WHERE (((("EmployeeEntity__EmployeeEntity_company"."id" = $1)))

There is a JOIN between the employee and company tables! This join is not necessary as the "company id" information is already present in the employee table.

And here comes the double binding on the foreign key to solve that :

@Entity({ name: "employee"})
export class EmployeeEntity extends BaseEntity {

  @PrimaryGeneratedColumn()
  id: string;

  // [...]

  @JoinColumn({name: "company_id"})
  @ManyToOne(() => CompanyEntity)
  company: CompanyEntity;

  // Here is where the magic happens
  @Column({name: "company_id"})
  companyId: string;
}

We let the company relationship but add a companyId field, which points to the same column.

Now we can rewrite the findByCompany implementation like this :

findByCompanyId(companyId: string) {
  return this.employeeRepository.findBy({
    // Use the companyId "column" instead of the relationship
    companyId: companyId
  })
}

Now, the generated SQL looks like this :

SELECT "EmployeeEntity"."id"            AS "EmployeeEntity_id",
       "EmployeeEntity"."creation_date" AS "EmployeeEntity_creation_date",
       "EmployeeEntity"."first_name"    AS "EmployeeEntity_first_name",
       "EmployeeEntity"."last_name"     AS "EmployeeEntity_last_name",
       "EmployeeEntity"."company_id"    AS "EmployeeEntity_company_id"
FROM "acme"."employee" "EmployeeEntity"
WHERE (("EmployeeEntity"."company_id" = $1))

No more unnecessary JOIN !

Bonus: "SELECT" only the information you need

In this example, the table employee contains few columns but, in a real-world example, it could contain dozens of columns that you don't need every time. Especially columns that could contain sensible information

Suppose that I just fetch all employees like this:

this.employeeRepository.find();

Here is the generated sql :

SELECT "EmployeeEntity"."id"            AS "EmployeeEntity_id",
       "EmployeeEntity"."creation_date" AS "EmployeeEntity_creation_date",
       "EmployeeEntity"."first_name"    AS "EmployeeEntity_first_name",
       "EmployeeEntity"."last_name"     AS "EmployeeEntity_last_name",
       "EmployeeEntity"."company_id"    AS "EmployeeEntity_company_id"
FROM "acme"."employee" "EmployeeEntity"

But we might not need all the columns. TypeORM lets you decide which columns you want to fetch, like this :

this.employeeRepository.find({
  select: {
    firstName: true,
    lastName: true
  }
});

Note : we don't call findBy anymore but find which allows us to pass other useful parameters such as take, skip and relations (this one is for lazy/eager loading), and of course, the where clause.

And here is the corresponding SQL :

SELECT "EmployeeEntity"."first_name" AS "EmployeeEntity_first_name",
       "EmployeeEntity"."last_name"  AS "EmployeeEntity_last_name",
       "EmployeeEntity"."id"         AS "EmployeeEntity_id"
FROM "acme"."employee" "EmployeeEntity"

Note : the return type will still be a EmployeeEntity[] but the non-required fields are left undefined

Conclusion

Double binding on the foreign key is so useful that I now use it on nearly every foreign key.

Also, select can be useful on main tables, especially the user table, which often contains sensible information that you don't want to expose outside of the database if not necessary.

I hope that those tips will help you reduce the performance overhead on your database!

Stupid form generator

Arnaud Denoyelle — Sun, 02 Oct 2022 15:25:13 +0000

Or why full automatic forms generators are often a fake good idea, and what to use instead.

But first things first, why do we use form generators in the first place ?

Forms take more time to develop than expected

Let's say you want to build a login/password form. 2 input fields + a submit button. Seems easy and looks like it will take 5 min.

But experienced developers learned the hard way that forms hide some complexity :

Field validation
Error messages
Layout problems

If you need a lot of forms in your application, they can be tedious to build. To tackle this problem, some developer's immediate reaction is to use a form generator. There are plenty of them, in every existing language.

Automatic form generators : the fake good idea

Form generators come with a handful of promises :

Just configuration, no HTML/CSS/JS/Java to write
The code base will become "cleaner"
Compatible with any tool/framework/library
Fully configurable

At the beginning, everything seems easy to use, and the demo works well.

Then you decide to use it in your project, on real use cases.

Then, you discover problems :

A text field is nice, but I need a text area instead
But I need a very special component for this field, like a color picker
But here, I want to place components differently
But here, I want to add a "special offer" tag
But I need to react to a value change in this component
But I need to show a different component if this field has that value.

And their usual solutions :

You have an option for that
You can use a design pattern provide your own component
You can override the layout with CSS
You can use a factory/builder/adapter in order to handle this very special use case
You can provide a callback
We developed a custom dynamic expression language to handle this use case

In the end, you realize that, for complex use cases, it would have been easier to just use the native API

A form generator that aims at handling every use case is bound to become more complex than the problem it was supposed to solve.

You did not want to write code, but your configuration became the code

Do you remember when you just wrote the form by hand, and were able to do exactly what you wanted without dealing with tons of options ?

With a full automatic form generator, you still end up coding the form manually. You just code with the generator options instead of the native API, but you actually finish the code manually.

Configuring form generators takes time, and if you have less than < 10 forms in your app... just write them by hand.

Or...

Code generators to the rescue

Use a code generator instead. What is the difference ? You generate some code then copy-paste this code in the project. The project does not contain the form generator anymore, only the generated code.

Then, you can finish the code manually, adapt the structure as you wish and use the native API for complex use cases.

Also, as the complexity comes from the intention to handle every case... what if you just generated some code that is only 90% right ?

A code that is only 90% accurate ? Really ?

As you don't need to handle every use case anymore, the complexity falls dramatically. With a rule like "1 field = 1 component", you can build yourself a code generator that will handle 90% of the use cases in only ~100 lines of code.

And as you code the generator yourself, you can decide what you want to automatize or not and fully customize the generated code to your good taste.

I show you how to do that, and I provide a boilerplate

Build your own code generator

This part shows one possible way to build a custom code generator. I provide a working example here.

It generates a basic Angular form with 2 templates :

One template for the HTML code
One template for the TypeScript code

It is not much, but enough to understand the concept.

The code generator consists in 3 steps :

Describe the form fields
Enrich the model with variables that will be useful in the templates
Apply the enriched model on various templates

1) Describe the fields

The first thing you need is a place to describe the fields. As it will be your code generator and your templates, just think about the info that you will need when writing the templates.

export const input = {
  fields:
    [
      {
        name: "firstName",
        component: "TEXTFIELD",
        required: true,
        placeholder: "John"
      },
      {
        name: "lastName",
        component: "TEXTFIELD",
        required: true,
        placeholder: "Doe"
      },
      [...]
     ]
}

2) Enrich the model

From this point, the variable name firstName is useful, but you will probably need to have it in different cases : FIRST_NAME, first-name, First Name etc. This can be automatized with a simple for loop in order to obtain that :

{
  "fields": [
    {
      "name": "firstName",
      "component": "TEXTFIELD",
      "required": true,
      "placeholder": "John",
      "nameCamelCase": "firstName",
      "nameUpperCase": "FIRST_NAME",
      "nameSnakeCase": "first_name",
      "nameCapitalized": "FirstName",
      "nameKebabCase": "first-name",
      "nameLabel": "First Name"
    },
    {
      "name": "lastName",
      "component": "TEXTFIELD",
      "required": true,
      "placeholder": "Doe",
      "nameCamelCase": "lastName",
      "nameUpperCase": "LAST_NAME",
      "nameSnakeCase": "last_name",
      "nameCapitalized": "LastName",
      "nameKebabCase": "last-name",
      "nameLabel": "Last Name"
    },

3) Apply it to templates

For this part, you have to choose a template engine. I chose ejs because it has the required features : conditions and loops. Also, it is quite standard and well documented

The code is as simple as

  console.log('Loading template ' + templatePath);
  const template = readFileSync(templatePath, 'utf-8');

  console.log('Compiling template');
  const compiledTemplate = ejs.compile(template);

  console.log('Applying template');
  const result = compiledTemplate(enrichedInput);

And here is what the template looks like :

<form [formGroup]="formGroup" (ngSubmit)="onSubmit()">
<% fields.forEach(function(field){ %>
  <div>
    <%_ if (field.component === 'TEXTFIELD') { -%>
    <mat-form-field>
        <mat-label><%= field.nameLabel %></mat-label>
        <input matInput [formControl]="formControl<%= field.nameCapitalized%>"<% if (field.required === true) { %> placeholder="<%= field.placeholder %>"<% } %>>
    </mat-form-field>
    <%_ } -%>
    <%_ if (field.component === 'TEXTAREA') { -%>
    <mat-form-field>
        <mat-label><%= field.nameLabel %></mat-label>
        <textarea matInput [formControl]="formControl<%= field.nameCapitalized%>"<% if (field.required === true) { %> placeholder="<%= field.placeholder %>"<% } %>></textarea>
    </mat-form-field>
    <%_ } -%>

Put everything together

The complete program works like that :

Read the list of form fields from the input file
Enrich the model with various string cases
For each template of the templates directory :
- Apply the enriched model on the template
- Open the template in your favorite text editor

For me, it opens the generated files in gedit, ready to be copy-pasted to the project !

Conclusion

By taking back the control on the generated code, you can have 90% of the code automatically generated while still being able to fully customize the output.

Bonus : using the same strategy, it is possible, from a given class to generate most of the files for the frontend AND the backend part of the app that are more or less always the sames:

DAO
Service
Controller
Model
View
Presenter
various pieces of configuration to add in those files that you systematically forget.

I applied this strategy with success in an app that contained hundreds of forms. The code generator (written in Java at the time) would generate 25 different files for every part of the application : frontend, backend, database, configuration.

Code generators are nothing new and they are incredibly efficient. Their power should not be forgotten

9 things Chrome DevTools can do for you

Arnaud Denoyelle — Tue, 06 Jul 2021 09:10:07 +0000

This is my first article here. In this article, I share some tips that I wish I had known sooner. Those tips help you to debug faster and/or code better.

Most of the features I show here are available in all browsers.

The most important feature to me is 7 - Lighthouse and if you work with a dedicated test team, 8 - Export the Network tab is vital !

1 - Put any DOM element in a variable

The Elements tab allows you to edit the DOM and CSS properties.

But did you know that clicking on an element of the DOM will also put this element in the variable $0 ? Chrome actually gives an hint about that by adding == $0 beside the selected element :

You can then manipulate it in JavaScript from the Console tab :

Also, if you select other elements, $1 will contain the previously selected element. $2, $3 and $4 work in the same way.

2 - Pretty print minified source files

In the Sources tab now, suppose that you are working with minified code and need to put a breakpoint somewhere in this file :

This script is minified so the whole script lies in a unique line. How to put a breakpoint if there is only one line ? This is where the Pretty print tool comes in. It is located in the lower left corner :

Click it and... tadaaa !

3 - Conditional breakpoints

Speaking about breakpoints : what if there is a function that is called very often and throws an error only when a particular value is given ? How do you debug it without clicking 100 times on "Step over" ?

You can ~~add a condition or a bunch of console.log~~ use Conditional breakpoints !

First, you need... a breakpoint !

Click in the left column on the line of your choice to add a breakpoint then right click on the blue arrow then Edit breakpoint :

You can now write any condition you want. The code execution will stop only when the condition returns true

4 - Preserve logs upon navigation

Tired of losing logs each time you navigate ? You can just tell Chrome to keep them. The cog icon located in the upper right corner offers a ton of useful options.

In the Network section, you can tick Preserve logs.

In the Console section, you can tick Preserve log upon navigation.

There are a lot of other useful options, such as Show timestamps in the Console section. Feel free to explore them !

5 - Simulate a slow connection

Not everyone has a good internet connection. Do you know how long does it take to display your site on a slow connection ?

In the Network tab, there is an option to simulate a slow connection :

Do not forget to tick the Disable cache checkbox if you want to simulate a first connection.

6 - Replay a request

Suppose that there is a request that ends in error in your application. In order to understand why, you would like to be able to replay this request and/or modify its content.

In the Network tab, you can right-click on a request and there are several options :

If the error came form the server, you will appreciate the Replay XHR for a quick retry after fixing the problem.

You can also copy it to any format and modify it before replaying it. The easiest one is Copy as Fetch : it will generate the code to reproduce the request and copy it to the clipboard, you can then paste it in the Console tab :

Now, you can modify any parameters you want and see if the problem still occurs.

7 - Lighthouse

The most important one in my humble opinion ! The Lighthouse tab offers a free audit of your website.

As simple as can be, just click on the Generate report button.

Lighthouse will run a battery of tests concerning performance, accessibility, best practices, SEO and progressive webapps.

First, it will give you some marks for each category :

This is neat because it will make you want to get a 100%.

But more important, it gives detailed advices on every detected problem :

Here, it is advised to set explicit width and height attributes on images. The Learn more link gives a detailed explanation on why it is important and how to fix it.

Tip : if you have problems with your images' weight, take a look at Squoosh!

8 - Export the Network tab

This one is essential if you are working with a dedicated test team. Suppose that a tester filed a bug report but you do not understand what the tester actually did.

You probably already know that the Network tab allows you to see the executed requests with all the details concerning :

Requested URL
The request method (GET, POST, PUT, DELETE etc)
Request headers
Request body
Response headers
Status code And so on

But did you know that you could export/import the content of this tab ?

Click the export button and you will get an HAR file.

You can then later reimport this file using the Import icon located just next to the Export icon (or drag the HAR file in the Request tab directly, which is even cooler). You then have a complete trace of what the tester did along with all the request details.

9 - New : the Flexbox debugging tool !

Note : this feature is recent and things are still changing. Even the Official documentation might not be up to date

As it is a quite recent feature, you might have to activate it in the Experiments sections of Chrome settings.

Open Chrome settings :

Then, in the Experiments section, check Enable new CSS Flexbox debugging features (you might need to scroll down to find it) :

You might get a warning message with a button to reload DevTools

Now, in the Elements tab, every DOM element that has display value of flex, inline-flex or grid, you can see a flex or grid badge. Click on it to toggle the display of an overlay on the page.

You can try it on Google !

An overlay appears, showing the position of the elements. Also, in the Elements tab, there is a Layout tab that has now a Flexbox section where you can activate/deactivate the overlay each element :

Also, a panel appears in the Style tab. This panel allows you to quickly try different display options :

Conclusion

Chrome DevTools contains dozens of useful features but I decided to show only the ones I use the most.

I hope those tips will make your debugging sessions easier and help you becoming a better developer.

You can follow me on Twitter in order to know when future articles come. Also, tell me which feature helped you the most !

DEV Community: Arnaud Denoyelle

From Wow to Oops: The Vibe Coding Reality Check

The illusion of application generators

My Trip to Vibe Coding Hell. Let me start by saying that I use AI to… | by Brian Jenney | Medium

Brian Jenney ・ May 15, 2025 ・ brianjenney.Medium

The Hidden Complexity

The Real Story Behind Productivity Curves

The Dangers of Vibe Coding

The AI Moore’s Law

LLM-Assisted Development

How to Work with AI Today

Double bind the foreign key to avoid unnecessary JOIN in TypeORM

The model

Preparation : Activate logging on the local environment

Double bind the foreign key

Bonus: "SELECT" only the information you need

Conclusion

Stupid form generator

Forms take more time to develop than expected

Automatic form generators : the fake good idea

Code generators to the rescue

Build your own code generator

1) Describe the fields

2) Enrich the model

3) Apply it to templates

Put everything together

Conclusion

9 things Chrome DevTools can do for you

1 - Put any DOM element in a variable

2 - Pretty print minified source files

3 - Conditional breakpoints

4 - Preserve logs upon navigation

5 - Simulate a slow connection

6 - Replay a request

7 - Lighthouse

8 - Export the Network tab

9 - New : the Flexbox debugging tool !

Conclusion

Brian Jenney ・ May 15, 2025 ・
brianjenney.Medium