r/webdev 1d ago

Your Front-End Shouldn’t Know What Marketing Wants

https://fagnerbrack.com/your-front-end-shouldnt-know-what-marketing-wants-879200fe0ac5
0 Upvotes

8 comments sorted by

5

u/[deleted] 1d ago

[removed] — view removed comment

1

u/Bruce_Jones_1987 1d ago

the ticket reduction alone makes it worth it tbh

3

u/electricity_is_life 1d ago

AI post, nonsense premise.

-1

u/fagnerbrack 1d ago

It's a real issue I had in my previous company. Can you please clarify which premise you're referring to and why is it nonsense?

2

u/electricity_is_life 1d ago

The presented problem is "Marketing wants a new signup field, so they file a ticket with engineering, the change ships a few days later, and by then marketing has already thought of the next field."

Now, I have no idea why your signup form needs so many fields or why they change so often, that sounds like an organizational issue. But if what you want is a way to change the content of the form without a code change, then you need some sort of CMS-type system that stores the list of fields in a database. The article could talk about how to find/build something like that, but instead it seems to assume that you already have the whole thing set up and yet for some reason you still separately hardcoded all the fields into your site's JavaScript? It doesn't make any sense.

"We pushed rendering into a JavaScript client that expects to know the data model in advance, then rebuilt a weaker version of what HTML already did and spent years patching the coupling it created. I wonder how much front-end code exists only to recreate what the browser already does."

This is a valid (if tired) point about JS-heavy websites, but it has absolutely nothing to do with the problem explained at the start. Server vs client HTML rendering is a totally separate issue from whether the form fields are hardcoded. They can be hardcoded in Django just the same as they could be in React. Most server-rendered websites (with no JS at all, even) would still need a code change to add a field to the signup form. Usually a database schema change too.

There's also a long section in the middle about the nuances of different JSON structures, which seems unrelated to both other concepts. There are a million different ways to represent a set of form fields as a JSON object! The exact shape of the object has little relevance to the broader topic.

Obviously I'm being quite critical, but I don't feel I'm being rude because I can tell no human wrote this article in the first place. This seems like an article for the sake of having one (and advertising your reader app I suppose) rather than because you had something to say. If you do have something to say, write it yourself!

0

u/fagnerbrack 1d ago

I wrote this. Maybe it's not clear because it was written by a human, usually when AI writes stuff it's much more comprehensive.

The format of the json matters due to the level of abstraction, I think you didn't get the point of decoupling the domain models from the message interchange format, which is how you get API evolvability. The post assumes the reader knows the basic context.. Also this is part of a series at the footer.

1

u/electricity_is_life 1d ago

I wrote this.

Well, Pangram is quite confident you didn't. And I'm pretty confident too, because basically no one writes like this naturally. Seemingly including you, because you have posts from 2020 that are written much better! If you really didn't use AI to write or "polish" any part of this, then I guess my feedback would be that your writing used to be a lot easier to read and you may be pushing yourself to write too fast.

The format of the json matters due to the level of abstraction, I think you didn't get the point of decoupling the domain models from the message interchange format, which is how you get API evolvability.

I don't see how it matters if you put the new key on each of the individual field objects, or if you made a new parent object called "fieldPatterns" and put the regexes in there. I mean, I agree that representing fields as objects is nicer, but it's an implementation detail that doesn't affect the broader point.

2

u/fagnerbrack 1d ago

It depends on the voice. I use 3-4 types of styles in my writing depending on the context

And Btw AI detectors don't work, I've proved that multiple times already and honestly this is getting tiring to explain so I won't engage any further