Schiphol at Amsterdam had this for a year or so, you could bring any type of liquid and leave everything in the bag. But they reverted the liquid rule, if I remember correctly, because of the confusion it caused.
This happened due to a change in regulation in Europe.
Some airports, like AMS or MUC, invested on new machines with higher detection capabilities, and decided to allow all liquids and improve efficiency in boarding. The EU updated the rules claiming those new machines were still not sufficient and airports should go back to forbidding liquids.
It was a mess. I remember flying from MUC and being allowed all liquids and on my return flight, also from EU, when trying to fly with a normal water bottle, security people looked at me wondering what the f I was doing: "Don't you know liquids are not allowed, sir!?"
Schiphol has been very relaxed. I once had a water bottle with probably 200ml of water still in it in my bag. I was told to not do that again and they gave me the bottle back.
I dont know what really happened here. Maybe his curse word did prompt a block, maybe something else caused the block.
But to be honest I've been cursing a lot to Claude Code, im migrating a website from WordPress to NextJS. And regardless of my instructions I copy paste every prompt I send it keeps not listening and assuming css classes & simpliying HTML structure. But when I curse it actually listens, I think cursing is actually a useful tool in interacting with LLM's.
From my own observations with OpenAI's bots, it seems like there's nuanced levels.
"Don't do that" is one level. It's weak, but it is directive. It often gets ignored.
"DON'T DO THAT" is another. It may have stronger impact, but it's not much better -- the enhanced capitalization probably tokenizes about the same as the previous mixed-case command, and seems to get about the same result. It can feel good to HAMMER THAT OUT when frustrated, but the caps don't really seem to add much value even though our intent may for it to be interpreted as very deliberate shouting.
"Don't do that, fuckface" is another. The addition of an emphatic and profane quip of an insult seems to generally improve compliance, and produce less occurrence of the undesired behavior. No extra caps required.
It was fine when it started, it's the addition of useEffect and hooks that messed everything up. Although normaly I prefer functional, for react classes were 100 times better
I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches.
I’d rather have a honest framework than a chimera.
I have not followed SwiftUI recently but when it was introduced I quite liked to have the main composition in SwiftUI and then writing more complex components in pure UIKit. Both could be used what they are best suited for. But trying to shoehorn good interactivity into a SwiftUI component always ended in horrible code.
What about Elm? I think most people could grasp the elm architecture in an afternoon. To me this MVU style is pretty much perfect for UI.
I think a lot of the time React appears complex and hacky is because we tried to solve world hunger with one component. I've worked on plenty of React projects that were very easy to scale, modify and iterate because they focused so heavily on small independent stateless components.
Elm is awesome until you try to use it in an actual app. The amount of pain we went through trying to make a basic web app with a sidebar and a few pages... I don't remember the specifics, it was a few years ago, but I don't think Elm has changed much since then (it was 0.18).
> I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches.
Functional does not mean no state, just constraining state to inputs and outputs. Breaking that is a choice, and not good design.
Elm, for example, provides all of that with one escape hatch: ports. It is really well-defined and that not fall into any of the impossibilities you mention.
I also have the same somewhat controversial opinion, the frontend community wasn't ready and (still isn't) to organise a functional codebase.
The second problem is that React has a "draw the rest of the owl" mindset. Sure you have nice frontend components but now what about caching? data transfers? static rendering? bundle size & spliting? routing?
The reason for React’s “draw the rest of the owl” (which is a great way to describe it) mindset is that it’s born not as a framework but as a library, and to this day self-identifies as such. It by design tells you nothing about and is agnostic with respect to how you organise your code, where to put tests, what bundler to use, etc.
IIRC React itself doesn’t even know anything about the Web or DOM, as that integration is supplied by the pluggable reconciler, which lives in a separate library (ReactDOM).
One could argue that with the amount of batteries included perhaps it ought to undergo a grand status change, but until then it’s hard to blame on the authors of a library that they are not delivering a framework.
Did it not work? Many successful and complex sites and apps use React—whether directly or via a framework (Next, Astro, or something homegrown)—and indeed many frameworks are built on React.
> math tools or pdf generation
In this case the original scope of the library was “reactive rendering”, which sort of makes sense.
I've been there since the early days of React and I haven't seen a single React codebase which isn't a pile of duck-taped random packages, often leading to poor user performance.
Maybe it can be done, maybe not, but the average front-end dev doesn't have the insights to fill the gaps that React has left.
Some codebases are better than others, more mature open-source projects tend to be more polished, closed enterprisey things can be nightmare fuel, but that’s all probably universal to a degree and not specific to whether you’re using React or not. (OK, dependency mess is at least somewhat specific to JS.)
My real development experience started with Django—arguably one of the best-documented proper frameworks out there even before it reached 1.x—and let me tell you: the kind of garbage I have seen once I started doing it professionally still makes me shudder[0].
I agree with you in the sense that the choice to forgo a framework and use only a bunch of libraries directly should be very carefully considered. Frameworks exist for a reason. The decision should be made with the full understanding that one would implicitly undertake a task to create a framework (even if it is a narrowly specialised one just for that project). A lot of what you do if you go with raw React will not actually be front-end development: prepare to be vetting dependencies for (or implementing yourself) very basic functionality, fighting bundlers, trying to get TS to use correct global typings for the context, managing version hell to get all of the above to interoperate, etc.
(By the way, any mistake you make will be on you. Picked a test runner that was discontinued? Some transitive dependency got hijacked? There is no one else to blame. There’s no BDFL and expert core dev team vetting things, knowing when and how to write from scratch if there’s no trustworthy third-party implementation, orchestrating working version combinations, or writing migration guides.)
[0] Indeed it would be hubris to claim I myself have never ever architected something I would later call a monster held together with bits of duct tape.
It worked as in react is the de facto frontend choice.
It didn't work as in if I were to ask for the router, state management, etc library, there would be a combinatorial explosion of react "frameworks", all sucking in different ways.
I am (and supposedly grandparent also) on the option that react leaves out way too much that would still be well in the scope of a 'UI framework', and while modularity can be a good thing in certain things, more modular, more moving parts does increase complexity.
Yeah, as a solo dev quite new to frontend, that made me nope out of React almost immediately. Having to choose a bunch of critically important third-party dependencies right out of the gate? With how much of a mess frontend deps seem to be in general? No thanks.
I settled on Svelte with SvelteKit. Other than stumbling block that was the Svelte 4 -> 5 transition, it's been smooth sailing. Like I said, I'm new here in the frontend world and don't have much to judge by. But it's been such a relief to have most things simply included out of the box.
Even when it's the same router package, these things break backward compatibility so often that different versions of the same package will behave differently
That router thing seems crazy. I'm all for having options that are available. But not having, at the minimum, some blessed implementations for basic stuff like routers seems nuts. There is so much ecosystem power in having high-quality, blessed implementations of things. I'm coming from working primarily in Go, where you can use the stdlib for >80% of everything you do (ymmv), so I feel this difference very keenly.
> There is so much ecosystem power in having high-quality, blessed implementations of things.
Indeed. I work mainly in Angular because while it's widely regarded as terrible and slow to adapt, it's predictable in this regard.
Also now with typed forms, signals and standalone components it's not half bad. I prefer Svelte, but when I need Boring Technology™, I have Angular.
90%+ of all web apps are just lists of stuff with some search/filtering anyway, where you can look up the details of a list entry and of course CRUD it via a form. No reason to overthink it.
I know you are saying you do work mainly in Angular, but for others reading this, I don't think this is giving modern Angular the credit it deserves. Maybe that was the case in the late 20-teens, but the Angular team has been killing it lately, IMO. There is a negative perception due to the echo chamber that is social media but meanwhile, Angular "just works" for enterprise and startups who want to scale alike.
I think people who are burned on on decision fatigue with things like React should give Angular another try, might be pleasantly surprised how capable it is out of the box, and no longer as painful to press against the edges.
Strong disagree. Angular is cursed to the bone. It got a bit better recently but its still just making almost everything totally overcomplicated and bloated.
I'd say what you call bloated is in many cases basic functionality that I don't have to go looking for some third party package to fill. There is something to be said for having a straightforward and built-in way to do things, which leads to consistency between Angular projects and makes them easier to understand and onboard to.
IMO, it is only as complicated or simple as you want to make it these days, and claiming otherwise likely is due to focusing on legacy aspects rather than the current state of the framework.
FWIW, I'm not arguing that it's the "best" or that everyone should use it. Or that it doesn't still have flaws. Just that it is still firmly in the top set of 3-5 frameworks that are viable for making complex web apps and it shouldn't be dismissed out of hand.
Hooks were fine, but their implementation in React was barkingly insane. Vue's notion of "composables" is very similar, but not dependent on order, so you can use them in conditional statements without breaking the world. I don't even want to think about doing a complex Vue app without the VueUse library.
I feel like the main challenge is where to be "loose" and where to be "strict", Claude takes too much liberty often. Assuming things, adding some mock data to make it work, using local storage because there is no db. This makes it work well out of the box, and means I can prompt half ass and have great results. But it also long term causes issues. It can be prompted away, but it needs constant reminder. This seems like a hard problem to solve. I feel like it can already almost do everything if you have the correct vision / structure in mind and have the patience to prompt properly.
It's worst feature is debugging hard errors, it will just keep trying everything and can get pretty wild instead of entering plan mode and really discuss & think things true.
Just this week, sun-tue. I added a fully functional subscription model to an existing platform, build out a bulk async elasticjs indexing for a huge database and migrated a very large Wordpress website to NextJS. 2.5 days, would have cost me at least a month 2 years ago.
AI is helping me solve all the issues that using AI has caused.
Wordpress has a pretty good export and Markdown is widely supported. If you estimate 1 month of work to get that into NextJS, then maybe the latter is not a suitable choice.
it's wild that somehow with regards to AI conversations lately someone can say "I saved 3 months doing X" and someone can willfully and thoughtfully reply "No you didn't , you're wrong." without hesitation.
I feel bad for AI opponents mostly because it seems like the drive to be against the thing is stronger than the drive towards fact or even kindness.
My .02c: I am saving months of efforts using AI tools to fix old (PRE-AI, PREHISTORIC!) codebases that have literally zero AI technical debt associated to them.
I'm not going to bother with the charts & stats, you'll just have to trust me and my opinion like humans must do in lots of cases. I have lots of sharp knives in my kitchen, too -- but I don't want to have to go slice my hands on every one to prove to strangers that they are indeed sharp -- you'll just have to take my word.
Slice THEIR hands. They might say yours are rigged.
I'm a non dev and the things I'm building blow me away. I think many of these people criticizing are perhaps more on the execution side and have a legitimate craft they are protecting.
If you're more on the managerial side, and I'd say a trusting manager not a show me your work kind, then you're more likely to be open and results oriented.
From a developer POV, or at least my developer POV, less code is always better. The best code is no code at all.
I think getting results can be very easy, at first. But I force myself to not just spit out code, because I've been burned so, so, so many times by that.
As software grows, the complexity explodes. It's not linear like the growth of the software itself, it feels exponential. Adding one feature takes 100x the time it should because everything is just squished together and barely working. Poorly designed systems eventually bring velocity to a halt, and you can eventually reach a point where even the most trivial of changes are close to impossible.
That being said, there is value in throwaway code. After all, what is an Excel workbook if not throwaway code? But never let the throwaway become a product, or grow too big. Otherwise, you become a prisoner. That cheeky little Excel workbook can turn into a full-blown backend application sitting on a share drive, and it WILL take you a decade to migrate off of it.
yeah AI is perfect at refactor and cleaning things up, you just have to instruct it. I've improved my code significanlty by asking it to clean up, refactor function to pure that I can use & test over a messy application. Without creating new bugs.
You can use AI to simplify software stacks too, only your imagination limits you. How do you see things working with many less abstraction layers?
I remember coding BASIC with POKE/PEEK assembly inside it, same with Turbo Pascal with assembly (C/C++ has similar extern abilities). Perhaps you want no more web or UI (TUI?). Once you imagine what you are looking for, you can label it and go from there.
I am a (very) senior dev with decades of experience. And I, too, am blown away by the massive productivity gains I get from the use of coding AIs.
Part of the craft of being a good developer is keeping up with current technology. I can't help thinking that those who oppose AI are not protecting legitimate craft, but are covering up their own laziness when it comes to keeping up. It seems utterly inconceivable to me that anyone who has kept up would oppose this technology.
There is a huge difference between vibe coding and responsible professional use of AI coding assistants (the principle one, of course, being that AI-generated code DOES get reviewed by a human).
But that, being said, I am enormously supportive of vibe coding by amateur developers. Vibe coding is empowering technology that puts programming power into the hands of amateur developers, allowing them to solve the problems that they face in their day-to-day work. Something that we've been working toward for decades! Will it be professional-quality code? No. Of course not. Will it do what it needs to do? Invariably, yes.
It is wild. I must admit I have a bit of Gell Mann amnesia when it comes to HN comments. I often check them to see what people think about an article, but then every time the article touches on something I know deeply, I realize it’s all just know-it-all puffery. Then I forget and check it when it’s on the many things I do not know much about.
My cofounder is extremely technically competent, but all these people are like good luck with your spaghetti vibe code. It’s humorous.
Just look at the METR study. All predictions were massive time savings but all observations were massive time losses. That's why we don't believe you when you say you saved time.
You should know better than to form a opinion from one study. I could show you endless examples of a study concluding untrue things, endless…
I’ve been full time (almost solo) building an ERP system for years and my development velocity has gone roughly 2x. The new features are of equal quality, everything is code reviewed, everything is done in my style, adhering to my architectural patterns. Not to mention I’ve managed to build a mobile app alongside my normal full time work, something I wouldn’t have even had the time to attempt to learn about without the use of agents.
So do you think I’m lying or do you just think my eyes are deceiving me somehow?
I think any measurement of development velocity is shaky, especially when measured between two different workflows, and especially when measured by the person doing the development.
Such an estimate is far less reliable than your eyes are.
So if people want to do more and better studies, that sounds great. But I have a good supply of salt for self-estimates. I'm listening to your input, but it's much easier for your self-assessment to have issues than you're implying.
It’s a very good point. I have full control and everything is incredibly uniform, and more recently designed with agents in mind. This must make things significantly easier for the LLM.
The work was moving the many landing pages & content elements to NextJS, so we can test, iterate and develop faster. While having a more stable system. This was a 10 year old website, with a very large custom WordPress codebase and many plugins.
The content is still in WordPress backend & will be migrated in the second phase.
Google ads are very time & location dependent, the fact that it's showing to you might be a bad sign since you are most likely not close to Durban and this seems like an ad you only want to run locally.
Yes our ads were geo-fenced when I had them on. We have always had a good web presence, I think the conclusion is that nobody looks for services on Google, and our reliance on it above other channels is now no longer viable
Everybody looks on Google for services; or ChatGPT googles/bings it for them. Still the same.
We had a 10x jump just last month for my own company.
For bigger company I consult with we had stable revenue last 2 years even though search traffic declined by 50%, our Google ads still perform the same. In general buying intent still seem to come through Google, only 10% via GPT.
It will become more and more, but a full drop in 3 months means something else is wrong.
reply