Hacker Newsnew | past | comments | ask | show | jobs | submit | rednb's commentslogin

I don't think so, because so called nerfing manifests itself in ridiculous code quality, or even in failing to do a comprehensive code analysis which results in "actually there is a bug in the implementation i've just done because this flow has 5 steps and i didn't bother to review them all before confidently laying down my plan", and this can happen 4 times in a row during a session.

This is definitely not about dealing with the frontier of AI. I wasn't part of the nerfing chord, but Astra changed my mind. Quality got me to upgrade from Pro x5 to Pro x20 on launch day. A couple of days later was dumb af, horrendous code quality etc...

Something fishy, or at least unethical is going on. Not sure it impacts API users though.


I'd take this kind of benchmark with a grain of salt. At this point, I have a set of comprehensive guidelines covering both backend and frontend work, and for the frontend we go as far as explaining what we a good design is in our visual system, and even how to conduct a visual review when screenshots are handed to the model.

Deepseek 4.1 ranks very low in this benchmark but it has proven so capable that after being simultaneously on Max x20 and Pro x20 subscriptions, i've transitioned to using DS 4.1 as a daily driver and am very satisfied.

My point is, i think their overall ranking makes sense, matches my experience with out of the box capabilities for vague and underspecified tasks. But seeing a model rank low in their ranking does not mean that the model is incapable. Having skills and guidelines has a lot of influence on what you get out of a model.


You use DS through Open Router? Which harness?

I'd love to hear more, I'm considering jumping ship. I'm running a Debian desktop if that's a concern.


I use the direct API from deepseek using Opencode, no problem to report, works like a charm.

Except maybe that the model often believes that he is running out of context, and needs to rush so i occasionally need to jump in to tell it that it still has plenty of room left.

But this does not degrade the quality of my overall experience in a meaningful way.


Thank you. I might just check that out.

Have you used 10b/5b tokens over the course of a week or over the course of a month?

It was 9.4B to be exact and it was over the course of two days lol. It was between two projects so 99% of them were cached reads.

The GPT was about 1B on two projects on 300$ worth of plans all on Astra and I capped out on usage.

Anthropic caching must be better because the cache rates are better on Claude models.


It is because of things like that that i'm using Android. I feel like one of those boomers having no clue about tech whenever i am handed an iphone: everything feels like a trick, a set of secret gestures and recipes that everybody has mastered but me.

Not criticizing because i can see that many people love Apple products precisely for this reason. Apparently this makes the UX friendly and intuitive. But it didn't click for me.


Android is just as bad. But it has one huge advantage: you can install apps on it.

Can't say I agree - I honestly tried using an iPhone for a few weeks, and I still couldn't reliably get where I wanted, because there's a good chance some input on the way would suddenly result in a totally different effect.

It feels like 80% of the UI has non-obvious overloads. I must have either skipped the tutorial or been too blind to find it, because otherwise these things are anything but intuitive. I've never struggled as much with any Android device, even with exotic manufacturer UIs.


It's true of android too, you're just used to it. Even Graphene eliminated the back button, and makes you swipe left from the right side instead, and the app switcher and home buttons, and makes you swipe up-right from the bottom.

No, I genuinely have not encountered the same reliability issues on any Android devices, even on my very first one.

I'm not a big fan of such gestures (mostly due to discoverability), but the few times I've used an Android without the navbar the gestures still felt reliable, even if I had trouble remembering them.


I got a Pixel 10, installed GrapheneOS. Then Google Play (which is sandboxed). I have 99,9% of all apps and a barebones launcher and some barebones fossify apps. Its pretty good, ugly if you let it but not bad

Android apps also have the icon-tap-and-hold actions…

I think you underestimate what a massive country China is and the scale of their military. Russia is already quite an adversary, but China is at an even higher level. By some metrics, they have already surpassed the US military.

So it is very unlikely that a neighbor will have the audacity to attack them, and even if this happens, i'd expect the war to be over rapidly. Just like if Canada or Mexico tried to attack the US.


I think the consensus is that Russia proved itself barely capable against just Ukraine. Also I didn't say someone has to attack prc, it's more likely to go the other way round and as many historic examples showed no matter how big you are people defending their home land will not make it easy.

Russia is more than twice the size of China. Hasn’t helped them to stay protected from drones.

The scenario we are all dancing around is if there is a war over reunification. That would be between the worlds two superpowers. No one would walk into a nuclear Holocaust on purpose I bthink, but miscommunication happens. Even if no other nations intervened, the reunification would definitely destroy all the worlds leading fabs, and even if it didn't, I read ASML can and would shut their machines down remotely. So those researchers would shift to figuring out what they can do at the 28nm node... Meanwhile the rest of us ponder why old powerful men can't let things be.

> OpenAI reduced prices and Anthropic increased weekly usage limits.

As a Max x20 and Pro x20 subscriber, can tell you that it doesn't matter since they continually move the baseline of token use So in practice you feel that you're continually getting less from your subscription.

While it never happened to me in the past, i reached my weekly limit within 3 days using Opus 5. And the Open AI weekly limit essentially is a Claude Max x20 5-hour limit. Not even talking about the baseline in intelligence : on release day Astra was so good that it lead me to move to Pro x20. Now it's dumb af and token use is insane.

Deepseek 4.1 Flash has been a lifeboat for me, finally able to work without being constrained/distracted by limits and with what is in my view even better intelligence than Opus 5 for a fraction of the costs. DS is not messing up my brain with load-bearing pseudo jargon in every sentence. It respects coding guidelines, and completes even the most complex tasks most of the time in one shot.

DS 4.1 had been able to add complex features to my repo without breaking a sweat (330k lines of F# + 4M circa lines of an Angular frontend). Writes very idiomatic F# and respects our guidelines and style perfectly. Just completed an extensive UI/UX research and implementation work.

I am ditching both x20 subs and will only keep a Pro x5 because wife does a lot of design work and needs solid image generation capabilities.


You are literally linking to a page published by Visa's Investors Relations Department.

The problem is that like all cartels, they hold progress back. Things could be even more efficient than the current state of affairs. For example we could have open standards with thousands of local players, much faster settlement times etc...

There are also aspects such as the fact that due to this concentration of power, the whole world is subject to US sanctions, such that a EU citizen sanctioned by the US is effectively cut off from civilization.


I like how providing an incredibly efficient payment network is framed as holding progress back.

I'd frame it as making the standards for competition very high.

I don't see people getting super ideological about their inability to create monocrystaline turbine blades or 2nm semiconductors in their garages. Why payment networks? Because computers? The overall network is way more complicated than a specific technological system or clever open standards document.

These networks would be usurped if someone could actually come up with a better system. The economy insists upon it constantly.


“It works extremely well” doesn’t establish “its prices and restrictions are justified”. much better, less parasitic systems are possible, look at brazil and PIX. "These networks would be usurped if someone could actually come up with a better system" the problem is the network effects with payments is so strong that this is wrong. to explain it simply, Network effects and customer lock-in mean the best system doesn’t automatically win.


I 100% agree that their business is operated extremely well and delivers lots of value.

I am just saying that in my opinion, society would be even better off if this industry wasn't controlled by a cartel and i pointed 2 examples of how.

One difference between this and turbines, is that payment networks are sitting at the heart of the economy of countless countries. Turbines have a very different risk profile, much more modest and localized.

Russia was for example cut off from high-tech maintenance contracts but has been able to deal with it by manufacturing their own replacement part + there are maintenance cycles and spare parts so any disruption in service is not immediate unlike payments.


It should be said that being on a US sanctions list doesn't appear to carry the same weight it once did. A Japanese citizen was added to one this month and her bank was able to effectively ignore it, not sure about options where credit cards are concerned, but there are local alternatives which don't rely on US payment networks.


Well said, these talking points pushed by EU politicians for decades need to stop. US white collar workers have access to pretty much the same benefits than EU ones, but have a much higher after tax compensation, even taking health care into account.

And nowadays, with the erosion of the social safety net pushed by the French government, the gap is even more narrow. There definitely are huge inequalities there, US are far from being the heartless place EU politicians like to depict.


If you end your water fasts at 48h circa, you're missing out on most of the benefits as the body fully enters fasting mode past 36h-48h. So in a sense you're ending the fast when it is just getting started.

Can't give you medical advice, just a benchmark tip: a short water fast is 3-5 days, the first 2 days being the most difficult ones.

My personal experience is that mind/spirit plays a major role. If i'm down mentally, i'll break my fast prematurely. If you think about it, the only difference between fasting and starving are your motives and mindset. So this is a major item, that people approching fasting from a purely medical angle often fail to appreciate.

Make sure you are at peace, and embracing a mindset of healing, spiritual renewal. Have something to do. For example, as a Christian, this is a time where I'll read the Bible, sing/workship more frequently throughout the day, and of course rest. You can do something equivalent independently from your religion.

I don't know if this mental angle can help with your headaches, but consider giving it some though in case this can help. That's all i can think of i'm afraid. Just my 2 cents.


Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as it required me to move back to mixing presentation concerns with business-logic and data concerns (basically have the backend produce the UI, which is whole point of HTMX).

This is not a criticism but I suspect that the people enjoying HTMX are either people preferring old-school server-side rendering or react users.

Just sharing my experience, because HTMX is the absolute darling of hacker news.

Since i mainly develop real SPA, i found that is more complex than just using typscrpit if you build something non-trivial as managing state on the server is not fun at all.

In my opinion if you are happy using angular, you'll find that HTMX is a step backward in terms for dev experience. Can't speak about react, but since it is not a battery included stack unlike Angular, i can understand why many people find they'd be better off moving things server-side instead of messing around with 15 third-party libraries. My 2 cents


I agree. We are moving away from HTMX at work, to React. (After we moved away from Angular. That was…a choice…that I didn’t make.)

Here’s the thing: there’s still a place for HTMX. Lots of places. But “building an SPA but not actually and SPA” is not a lane for HTMX. Nor do they promote HTMX for that purpose. Really quite the opposite.

Different tools for different jobs. (Me? I honestly love React, just a more minimal stack. Zustand and TanStack and Vite. No Redux or Next.JS)


Yeah, typically I end up building websites (for myself and others) in basically three "lanes". Static HTML/CSS files, great for docs, presentations, reports and similar. Or, websites with some interactive/dynamic elements, HTMX is great for this. Or, fully fledged "client-side apps" where it's more of an application than website, then I go full out dynamic programming with ClojureScript and similar approaches.

I'm not sure why so many people seemingly fall into the trap of trying to find one tool and then use that absolutely everywhere. I mean, I'm familiar with it as in "it's fun" as I used Nix as a framework for a static website builder, but I keep seeing people making those sort of choices professionally too. Like when React first became popular, then suddenly people try to jam it into absolutely everything, until they slowly walk back and then after some years agree that maybe it's good for some things, not for everything and not as a default.


As someone who has conducted a ton of systems design interviews, the "I used these tools at my last job so I will use them for this completely different problem" is bamboozling.

OTOH, there are advantages to comfort picks. You know the APIs, you know the common libraries in the ecosystem, you know the quirks and pitfalls. It might not be optimal—and in production it compounds—but for dinky personal projects or finite-scoped professional things, it's understandable.


Ha, that was me and Hugo, back in the day, for static sites.

And, yeah, HTMX is truly great for sites with limited interactivity. You really, really do not want or need a full React Leaning Tower of Pisa stack for a simple presentational website.


> Here’s the thing: there’s still a place for HTMX. Lots of places. But “building an SPA but not actually and SPA” is not a lane for HTMX. Nor do they promote HTMX for that purpose. Really quite the opposite.

> Different tools for different jobs. (Me? I honestly love React, just a more minimal stack. Zustand and TanStack and Vite. No Redux or Next.JS)

My concern with is that i build line of business applications for a living, and literally, every project i work on ends up growing in scope such that even the simplest ones, reach a point where the customer asks for items that are just much simpler to do with a front-end framework. And these are often cross cutting concerns, such that it is not as easy as simply adding some js to one page.

Example: "i want to be able to reorder all the columns of all the tables of the website, and hide some columns, with my preferences remembered for each table". Customers pull that kind of thing off their hat every time, such that even "basic websites" can move out of the trivial territory any time. And this is just the most trivial example i can think of.

I want the tech stacks i use to be future proof, as in not having to rewrite everything when requirements become more complex (as it is also typically a time where we aren't given much time budget, as they need it for yesterday).

For something for which i fully control the roadmap, i may consider htmx (but even then, even my own products grow in ambition rapidly) however for customer projects i find this choice way too risky.

I need to be able to capitalize on the tech infrastructure i've built as requirements get complex, both due to customer time constraints and because this is where we get some of the highest profit margin from our work. Having to rework most of what i've done every time a complex requirement comes up, would be inefficient with this regard.

To me it's a case of knowing your tools in depth, to make meet most requirements (including from a performance perspective). Maybe erlang or go would have been more suited for a project from a philosophical perspective but since i specialize in .NET + angular, unless there is hard blocker, i'll use this tech stack, and everything is fine from the perspective of the customer. But i gain that the project is future proof and i won't need to reengineer it when it moves of its initial sweetpot.



Thanks for sharing, I agree with what he says.

I've reached a point in my career where i can essentially call the shots as far as engineering and even product direction is concerned.

But recently had to do some consulting as an IC due to circumstances (worst case scenario deal closing delay), and i can tell you that there are places where non-technical people make tech decisions without consulting anyone. Also in my already quite distant qconsultant past (wow, time flies) while it has always been common for me to sort out requirements, and help with business analysis to align them with engineering, even when you dismiss flying unicorns, the class of core requirement evolutions that can make you regret choosing a tech stack is still very large. I've seen a couple of folks fired literally due to this.

Even now that i call the shots and sell products rather than time, the roadmap uncertainty is still high (largely driven by the need to make products user-friendly enough based on feedback), so i default to .NET + angular as it keeps my game open.

B2B2C at the cross-roads of ecommerce, fintech, blockchains. So you need to deal with vendor integration requirements while making the integration user-friendly from a UX perspective + and keeping your own core UX premium, especially for the B2C segment, and being competitive. Requirements change fast, especially at the beginning, so you don't want your engineering to constrain you or make things more difficult than necessary.


Nice. Curious about your views on SolidJS?


I don't understand (possibly because I lack Angular experience): what is it about a .NET backend using HTMX that requires presentation concerns to be mixed with business logic?

Don't you have to maintain that separation either way? Your core/application logic shouldn't know how its result is ultimately represented. That could be JSON or HTML over HTTP, Protobuf over a TCP stream, or a custom binary protocol over a Unix socket.

Obviously those representations matter at the presentation/transport boundary, but why should choosing HTML force that concern into the business logic?


HTMX requires you to return HTML chunks (and calls that hypermedia) that get dumped directly into the client-side HTML.

So instead if returning data (JSON, XML, whatever), every part of your API now needs to return parts of client-side UI, and be aware of changes in it.


I know. HATEOAS...

I understand the issue of mixing state models.. angular SPA style vs HATEOAS.

But that still doesn't answer what I was asking about mixing presentation concerns into business logic. Returning HTML means the presentation layer has to know about HTML. Why would that require the business logic to know about it?


> ... managing state on the server is not fun at all.

Do you not have a database for your backend? Managing state is kind of their thing.


Are you not familiar with building web apps?

So, when building for the web you'll essentially have 2 different categories of state: server and client.

Server state is obviously what's pulled fromt the db, but that's 100% not where something like form state should be stored. Or button toggle state. Or whether a modal is open, etc.


I have written web apps and about 80% of the sorts of things you are talking about can be handled with just html/css and I just use javascript for the other 20%. It's not like when you use htmx it disables all other javascript APIs.


We are talking about how state is stored, not about CSS.

And it makes me think you haven't had as much experience as you think.

How do you deal with form state using CSS? Where does it get stored? In the html as elements? So not on the server?


> How do you deal with form state using CSS? Where does it get stored? In the html as elements? So not on the server?

For really simple stuff you can use CSS sibling selectors: https://jsfiddle.net/Kqscu/4/

For more complicated stuff, it is in the html as elements. With htmx you can often do this by making a request to the server to update a subtree; the server doesn't need to know the state that the user is seeing, just what is happening in the specific request.

Sometimes just updating html subtrees isn't quite enough, and then I use javascript. Transient state that is only concerned with what is presented to the user is probably not best done on the server.


I agree this is a scope or focus thing. Different tools for different things.

If you are already maintaining a tool chain, a supply chain and skills in an SPA framework for multiple customer-facing, client-driven projects, I don't think you have much of a use for HTMX. Hence why at work, we have our full-time frontend engineers doing this, because it gives you the most flashy quality.

I am an infrastructure engineer. I have privately tried out a couple of SPA frameworks, The complexity to set this up for the first time is immense. And if you have rarely touched projects, the churn of the tooling and dependency ecosystem is taking up a significant amount of time for something that may be nice to have at work, or a pet project at home.

It's not cool if you have half a day to touch an old project and everything has rotted away around it so nothing interesting gets done. Something like Pydantic, Flask or Django + Jinja generally doesn't do that. And HTMX can make it nicer fairly cheaply.


There are an army of people using SPAs for problems best served by a simple and more traditional website. It has been a thing since SPAs started showing up so you have a whole generation who think that Next.js is just how you build for the web.

Then HTMX is to them what the micro-ORMs were for me (and, if you've been in .Net for a couple of decades, I suspect you too).


It was so bizarre seeing people go from pure SPAs, to the concept of "hydrating" a website (ok still makes sense to a point), to coming up with server-side rendering like it's novel.

I mean sure, things like Next, Gatsby, etc can theoretically create the best of both worlds - static site for search engines and no-js users, content first, and very fast client-side rendered content afterwards. But that's a lot of extra engineering, considering a good server-side rendered website is also fetched and rendered within milliseconds.


> managing state on the server is not fun at all.

Really? I've never found that difficult. Sessions exist, URL parameters exist... Perhaps in a complex SPA you can have trouble, but so many of the "applications" I've worked on are just glorified documents.


I haven't used sessions in over a decade and haven't regretted that decision once. It opens up a whole new class of problems you don't have when using client-side frameworks.


So what do you use instead?


It depends on the specific data. Do you have anything that you store in session in mind?

Having the client/server split has made this a lot easier to reason about. I store client state on the client and server state stays on the server.


I’m talking about auth, like a session cookie. What do you use for auth?


I use Entra, so the session cookies are created through login.microsoft.com. Which means I'm not actually managing the session.

When I said I don't use sessions, I should have specified I don't use them for application state (or roles and stuff).


I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue HTML is the most efficient wire format for interactive web apps, especially with streaming + compression.

Seriously DB->json->client->toHtml

DB->toHtml->client

Just imagine if that html wire format also conveyed the interactivity too and you eliminate the issues. And you can always seperate whatever concerns you want in whatever tpl lang of your choice.

Also htmx 4 is kinda just an worse datastar funnily enough In it's own way.


Datastar relies way to much on IDs everywhere that it's not ergonomic and turns into a chore. It's also a bit too complicated for its own good trying to solve everything.


As far as I understand D* only uses id (which is a pretty normal HTML attribute?) to key morphs in SSE. I only use one id for fat morphs on the body, and even if I needed more I'm not sure I'd find that any less ergonomic than other web standard attributes (class for example I have to use religiously in my day job with tailwind, etc).

Can you elaborate on the "too complicated" part? It seems a lot simpler to me given the slim surface area of the APIs?


I totally agree. When we started splitting presentation from content (CSS) that was a wonderful step forwards. And splitting back-end and front-end concerns similarly makes for a cleaner and more elegant design in both codebases.

IMO HTMX is a weird regression in our design patterns. Hopefully a temporary anomaly. I'd never choose to work in a company that adopted this mixing of front and back end code - it's a red flag as far as I'm concerned.


For me htmx is a utility library to spruce up a couple of interfaces here and there that benefit from a bit of reactivity. Anything more complex I really don't feel that it's the right tool. Or that there is any great tool to build SPAs.

There is sometimes this trends on projects of using anything like a universal hammer. And then they SPA their project.


> mixing presentation concerns with business-logic

That's on you not on your platform


Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: