ookblah

you're making a strawman here. it was never black and white and i never advocated all humans being replaced with machines so we have zero interaction with each other.

every technological push has been to automate more and more and every time that's happened we've reduced socialization to some extent or changed the nature of it (social media anyone? and yes, this also has everything to do with remote vs in-person, etc, all which pull the lever on what level of socialization is acceptable).

just because it doesn't fit your particular brand doesn't mean it's wrong, and it's clear this is pushing on your line where you find it unacceptable. i could just as well argue that people who do not show up to an in-person office are not "socialized" to the degree society needs them to be.

the debate has always been to what degree is this acceptable.

and just to play devil's advocate maybe some people don't enjoy that? remove the issue of training the next generation for a moment.

just like with open vs. closed offices or remote vs in-person, maybe some people have all the human interaction they want outside of work and don't mind "talking" to some AI as long as it gets shit done in the manner they want.

basically nails every point i've wanted to say but couldn't lol. also in the end the endless posturing gets tired and we go back to getting shit done. either it helps you are it doesn't.

AI critics always have to make strawmen arguments about how there has to be a human in the loop to "fix" things when that's never been the argument AI proponents ever make (at least those who deal with it day to day). This will only get better with time. AI can frequently one-shot throwaway scripts that I need get things done. For actual features I typically start and have it go thru the initial slog and then finish it off. You must be reviewing the entire time, but it takes a huge cognitive load off. You can rubber-duck debug with it.

I do agree if you have no idea what you are doing or are still learning it could be a detriment, but like anything it's just a tool. I feel for junior devs and the future. Lazy coders get lazier, those who utilize them to the fullest extent get even better, just like with any tech.

nice. so basically we are so "back" to the icons i saw from my packard bell desktop shitty navigator OS like 30 years ago lol. everything is truly cyclical (also in fashion like what gen-z is wearing) and i'm old enough now i guess so it a little jarring to see these things playing out before my eyes.

its about consistency to me. if you have a lot of time to kill on potential issues then sure. stopped using abnb when i traveled once and the AC was broken/leaking b/c the host thought i wouldn't mind it, then asked if i would be fine waiting 1-2 days while a repair guy came to fix it. thankfully the host was apologetic and worked with me and airbnb to get the refund, but i still had to book a hotel elsewhere.

with some chain hotel at least i know what to relatively expect in terms of service and amenities and have someone to complain to to make it right.

the future is probably something that looks pretty "inefficient" to us but a non-factor for a machine. i sometimes think a lot of our code structure is just for our own maintenance and conceptualization (DRY, SRP), but if you throw enough compute adn context at a problem im sure none of this even matters (as much).

at least for 90% of the CRUD apps out there, you can def abstract away the entire base framework of getting, listing, and updating records. i guess the problem is validating that data for use in other more complex workflows.

knowledge gap and consolidation just gets wider, like before. the internet rotted peoples brains but also brought that knowledge to people who would have never had the opportunity to learn.

those who use the tools to accelerate their learning will do so and others who use it just to get by will see their skills atrophy and become irrelevant.

okay, but code still has to be written. you can be a master architect and if the codebase requires X lines they have to come from somewhere. i'm just having a hard time grokking how you you can spend 1-10% of your time coding and actually ship anything at speed. esp if you imply you're not far away from the real engineering work.

or maybe at these companies the product is pretty stable or you're in an area where it's more optimizations vs. feature building?

you know, maybe understand actual frontend dev issues more deeply before arguing against toolsets you are unfamiliar with. none of your suggestions/generalizations actually address my actual real world issues and rather they are non-issues in modern dev.

the type of apps i'm talking about aren't just a "theme.css", so whatever mythical large app you're talking about that adheres to this rigid css standard while being easy to maintain i'm ready to be proven wrong lol.

every page in our app is a "component" which could have many sub components, some reused. i think it's actually very common in large scale apps so maybe we're not even starting on the same foot.

would you not consider opening the web inspector "hunting down" when i can just understand the full thing just by looking at the element itself? to your example, let's say now you want to put your search bar next to another item, but that item requires that there be 4rem right margin. Then you put your search bar next to another item in another component that requires 8rem top margin. this starts breaking down at scale. in the past we would just inline the margin value. eventually this moved to basic utility classes which evolved into tailwind.

and with your code, you've just proved my point. i find tailwind overly verbose (necessary evil), but honestly i don't even need to open the "inspector" to understand how this will look. you can give me that 12 months from now and i can understand exactly what it is in 10 seconds. with "alert" i have to referencing something else. and this is just a handful of lines, imagine if your component is larger than that. it's also a bad example because i will just eventually roll the styles for "alert" into its own class if it makes sense. get the best of both worlds.

again, i challenge you to just consider that a lot of other people as smart as you have thought through these issues and made the according trade-offs. the example you're giving is just way too simplistic and pretty much like every example someone gives in these threads.

yeah and when you do that for 100s of components i'd rather just see a utility class on the button itself vs hunting down its meaning in the related section of the component.

this is exactly the shit i was annoyed by when scaling, having to scope a .my-component-X section for literally every component and then grokking it later. you're basically taking the worst part of CSS (hunting down the meaning of a selector) and duplicating it for every component.

now maybe you say name it better or more semantically? congrats you recreated BEM lol. literally all the arguments used against it are purists for purity sake or thinking people haven't gone through this same thought exercise.

just use whatever is best for the task. i still use css the "traditional" way.

/rant

yeah i'm just tired of making the same argument over and over. for what it's worth i've been doing CSS "properly" since the time when that site was a thing.

back in the backbone days, now vue/react and before tailwind this is EXACTLY what we did, scope the styles down to the component, then layer it on top of the global styles. so sure, .my-selector a is specific to that component.

the "side effect" happens when your app starts to span 100s of components and you need slight variations for everything. you're telling me you can assure me that none of your master global classes contain any design definitions that could not possibly be reused? i'm calling bullshit. it's like saying your backend 100% never has any duplicated functions.

so with that out of the way, let's say you do get your global styles like 90% of the way there. so in each component you scoped it down. now lets say for one button you had to adjust the margin a bit, or another the styling is somewhat diff. multiply this by 100s of different components.

tell me now how me opening a file, seeing "button variation-class-1 variation-class-2", then going down into the component <style> section and looking up exactly what the variation and what properties were used is in anyway "better" than just seeing some super powered inline style directly in the button. it's the same complexity and now you've gotten rid of the prime benefit of CSS hierarchy and split the "style and structure" in just one independent component.

at some point you can't possibly create the number variations you need and you can't extract out "reusable" parts. maybe you have 5 buttons and only 2 need the 20px margin. do you create a "button 20px" class and do that in each component? no. at some point you will just inline it because it's easy, or you will create your utility class except it will be worse than tailwind.

yeah, and then one day you want .button, but with a variation. GREAT. but oh no, now there's this other button that has a little bit of a change but not enough to create a separate class. maybe we'll just inline it... but no, i need a mobile selector here or i have some complex hover style. i know, let's create a basic utility class to help me out here. hmm, starting to look suspiciously like tailwind...

now multiply this problem by more people working on an app, with different isolated components that they never even dreamed of during css zen garden's time and this is how something arose. we've tried creating centralized css sheets and it just doesn't work at scale.

so yeah, a necessary evil, but i wouldn't call it an anti-pattern. it grew out of real needs. we had bootstrap and all these css frameworks attempting to make "order" about of something that honestly after decades of working with i don't think can be ever be fully "clean". people just gotta move past it.

mobile selectors, "group" selectors, hover styles... the list goes on and on. like all things, it depends on how your workflow. if you have a super defined hierarchy and naming scheme you can reference then sure, centralize all your CSS. if you have many components and multiple people working on them sometimes it's better to separate everything out and enforce with a guide.

i can't tell you how frustrating it is to open a component and have no idea what you're looking at because you worked on the thing months ago, or you change one thing in your centralized CSS and have no idea what the side effect are. with tailwind i can see exactly the styles i'm looking for.

FOR ME, works better to have a core style file and then move everything to something like tailwind per component for maintenance.

tired of seeing the same simplistic arguments against utility frameworks. if you can't see the merits of it then you obviously aren't working on projects that need that, but don't criticize it blindly. it's not for lack of CSS knowledge.

yes, that is one aspect of it.

1) refactoring. copy paste, re-arrange, extract, delete and rebuild the connection. i have the mental model and tell the LLM do do it across multiple files or classes. does it way faster and exactly how i would do it given the right prompt which is just a huge file that dictates how things are structured, style, weird edge cases i encountered as time goes on.

2) new features or sections based on existing. i have a service class and want to duplicate and wire up different sections across domains. not easy enough to just be templated, but LLM can do it and understand the nuances. again, generate multiple files across classes no problem.

i can do all these things "fast". i can do them even faster when using the LLM, it offloads the tediousness and i save my brian for other tasks. alot of times i'm just researching my next thing while it chugs away. i come back, lint and review and i'm good to go.

i'm honestly still writing the majority of the code myself, esp if it's like design stuff or new features where the requirements and direction aren't as clear, but when i need to it gives me a huge boost.

keeps me in the flow, i basically recharge while continuing to code. and it's not a small script but a full fledged app, albeit very straightforward architecture wise. the gains are very real. i'm just surprised at the sentiment on HN around it. it's not even just skepticism but outright dogging on it.

i think everyone here has extremely different ideas of what AI coding actually is and it's frustrating because basically everyone is strawmanning (myself included probably), as if using it means i'm not looking at documentation or not understanding what is goin on at all times.

it's not about having the LLM write some "starter pack" toy scaffold. i means when i implement functionality across different classes and need to package that up and adapt, i can just tell the LLM how to approach it and it can produce entire sections of code that would literally just be adaptations of certain things. or to refactor certain pieces that would just be me re-arranging shit.

maybe that's not "boilerplate", but to me it's a collosal waste of my time that could be spent trying to solve a new problem. you can't package that up into a "code snippet" and it's not worth the time carefully crafting templates. LLM can do it faster, better, and cost me near nothing.

yeah i definitely enjoy the craft and love of writing boilerplate or manually correcting simple errors or looking up functions /s. i hate how it's even divided into "two camps", it's more like a big venn diagram.

i mean how far are you willing to take that argument? every decade has just been a new abstraction, imagine people flipping switches or in raw assembly talking about how they don't "understand" you now with your no effort. or even those who don't "understand" why you use your autocomplete and fancy IDE, preferring a simple text editor.

i say this as someone who cut my teeth on this stuff growing up and seeing the evolution, it's both. and at some point it's honestly elitism and gatekeeping. i sort of cringe when it's called a "craft" because it's not like woodworking or something. the process is both full of joy but so is the end result, and the nature of our industry is that the process is ALWAYS changing.

you accumulate a depth of knowledge and watch as it washes away in a few years. that kind of change, and the big kind of change that AI brings scares people so they start clinging to it like it's some kind of centuries old trade lol.

just letting you know one of the flying boxes had clipped through the text i was editing, hard to recreate it but happened randomly.

I'm finding this as well. I can't trust it to go beyond boilerplate or PoC's or I risk lagging behind in understanding and actually slowing down in the long term. Best workflow is to tackle silo'd problems and iterate on them with LLM.

I will say in terms of fixing boilerplate or doing tedious work it's a godsend. The ability to give it literally garbage formatted content and return something relatively structured and coherent is great. Some use cases I find:

- Rapidly prototype/scaffold a new feature. I can do what takes me hours/days in magnitudes of less time and saving my brain energy lol. 90% of it is usually garbage, but I just need a PoC or direction and I can sniff out what approach doesn't work (goes with the above of not doing too much at at time)

- App typically has a lot of similarly structured sections that can't be DRY for whatever reason. Fix in one area, feed to LLM how to solve the problem and then apply it to X number of other sections. Boom, edits 20 files and saves me tedious hours of doing it manually and potentially screwing it up.

- Run logs and sections of code in an initial bug to see if I'm missing something obvious up front. Helps dive into the right areas.

- Transform garbage content into something else when I can't be bothered to write a complicated regex or script for.

sorry for the snark, but missing the forest for the trees here. unless it's just some philosophical idea, use the tools that save you time. if anything it saves you writing boilerplate or making careless errors.

i don't need to "hand write" every line and character in my code and guess what, it's still easy to understand and maintain because it's what would have written anyway. that or you're just bikeshedding minor syntax.

like if you want to be proud of a "hand built" house with hammer and nails be my guest, but don't conflate the two with always being well built.

because then those churches and schools will just leave the US! /s

yeah except a lot of those companies almost went bankrupt trying to make those cars for enthusiasts and only for them.

porsche and lambo didn't see the outsized success they have now (financially) until they started pumping out SUVs. hell, the purosangue was made precisely to capitalize on that boring market segment.

i feel there's a little suvivorship bias at play here. i think the important thing is to not forget your enthusiasts perhaps, but a lot of these "successes" wouldn't even be around were it not for appealing to the greater masses. ofc some market segments fare better and you can build a business around enthusiasts.

u know the landscape is terrible when something like this can be funded, series A no less. zero diligence.

good luck getting the average person to even get past the 2nd slide with basic calculations lol. he's preaching to the choir.

i remember this guy crying on TV during the covid drop about how the world was ending only to be buying up everything behind the scenes lol.

a lot of weird llm generated stuff hitting fp now

I guess for every grift for AI hype there's the other side seeking to capture an audience that rejects it and making super hyperbolic statements to get there lol. This doom and gloom is also getting just as tiring.

Like imagine rejecting the internet in it's entirety because the "dotcom" era was way overhyped. That's what the author sounds like right now. Whatever rises out of the ashes of this hype will be far more useful than what we had before and we all move forward.

Articles like this honestly confuse me. I really do not understand this sentiment that that some coders have where it feels like every line they write is like some finely chiseled piece of wood on a sculpture they made.

Since day one I've always liked to build things much like the author, my first line of HTML to CSS, frameworks, backend, frontend, devops, what have you. All of it a learning experience to see something created out of nothing. The issue has always been my fingers don't move fast enough; I'm just one person. My mind can't sustain extended output that long.

My experience with AI has been incredibly transforming. I can prototype new ideas and directions in literally minutes instead of writing or setting up boilerplate over and over. I can feed it garbage and have it give me ballpark insights. I can use it as a sounding board to draw some direction or try to see a diff angle I'm not seeing.

Or maybe it's just the way that some people use AI coding? Like it's some magic box and if you use it you wont' understand anything or it's going to produce some gibberish? Like a form bikeshedding where people hold the "way" they code as some kind of sacrosant belief. I still review near every line of code and if something is confusing I either figure it out and rewrite it or just comment on what it's doing if it's not critical.