In my limited anecdotal experience, Kimi K3 is a bit better than Opus 4.8 and Qwen3.8 Max is disastrously bad. It can reason fine, but the moment it tries to do something it gets stuck into long second-guessing loops with no progress. It sometimes refuses to try and debug a problem even after multiple suggestions. I'm sticking to K3.
HN user
isqueiros
This looks pretty cool, but I'm pretty sure my imported sens from Deadlock has gone wrong. I have 0.68 in game and it feels significantly slower on the app.
This is exactly my vision. I can barely get AI to output my code how I want it to after hours of planning and refining.
If you think you can be "specific" enough for AI to match your "creative vision", then maybe you're not really creative.
At least one! We might even get two.
I already thought the deal was bad to begin with, but if you look at the numbers like this it feels even more catastrophically bad, damn.
This is not even considering they basically bought all the PR issues that came with Blizzard.
Not surprised to see this is common. At my company basically everyone and their mother are using Claude Code via Bedrock, despite us having company-wide Windsurf, Copilot and ChatGPT Enterprise accounts
You should try some of the newer OLED panels. They're all glossy and look really good.
I'm just hoping they make figuring out contactless payments a priority.
tailwind is very much not a problem for accessibility? if your content is semantic and you add the appropriate aria tags, whether or not you have 300 classes or 1 will make no difference for screen readers
It's literally just vscode? I tried it the other day and I couldn't tell it apart from windsurf besides the icon in my dock
Interesting. I haven't investigated, so I don't know where the 40mb comes from.
Don't get me wrong. 5mb is a lot for this, yes. This app, coded with love and interest could easily be made under 1mb.
Seems like you are part of the first group then, not the second. The fact that you are interested in learning and are using it as a tool disqualifies you from someone who has little clue and just wants to get something out (i.e. just spit out code)
40mb is way too much for a JS bundle... Even with a framework you could do this with 5mb or less.
this would make it even closer to the dangerously similar travel planning app "wanderlog"
it’s trying to solve a problem category that traditionally requires explicitness, not magic.
i've been thinking basically this for so long, i'm kinda happy to be validated about this lol
Vehicle tax in the Netherlands is already weight-based. This is why the tax rate for EVs is higher than gas cars. The thing is that if you live in Hilversum and are able to import a car from the US, you don't mind the higher tax to begin with
I find Neovim to be surprisingly sluggish. That's of course after installing extensions, but I don't find it particularly performant. Zed feels way snappier.
a mug cannot function when upside down and yet when you change the arbitrary orientation of a map it can still function the same you literally missed the point of the _title_ of the article, quite impressive
maintaining a large jquery/native js codebase vs a react one is not even in the same ballpark.
even when not being opinionated react foundationally has more structure for complex code.
This is one of those types of comments to change one's whole world view.
The notion that history is just on some inevitable pre-planned path is not a new idea, except now the actor has changed from God to technology.
I'm gonna fucking frame that. It goes hard
I don't think you get what I mean, and frankly your tone is quite disappointing. I haven't seen you properly engage with criticism once and all your responses are combative and petty. I'm not gonna grace you with a response.
I did not. ShadCN data table requires these. Check their docs
You made the choice to include Shadcn.
ps: I have a deep understanding how React works, even on how the actual codebase works.
I'm starting to doubt that.
You can't say you don't "allow CSS-in-JS" and then not allow class manipulation. These two are quite literally the only ways you can dynamically style DOM elements.
I've just come to the realization that the developer most likely inquired ChatGPT to write examples for "Modern React" implementations and just went with it.
This is yet another clickbaity title from the same developer. On the last thread, there were multiple instances of criticism that were dismissed or ignored.
Reading through the article, there are many places in which the information is incomplete, wrong and downright dishonest, imo.
Through Radix UI, Tanstack Table, and TypeScript interfaces. This results in approximately 170 lines of code, versus 40 lines in Hyper.
You made the choices to include these. TypeScript boilerplate is inevitable in good quality code. Tanstack and Radix UI add an immense number of features that your plain table just doesn't have. You're also omitting the fact that you import all components automatically with your IDE.
ShadCN table requires six different transpilers: ESBuild, JSX Transform, Rollup, TypeScript, Tailwind, and PostCSS.
Exactly two of these are actual "transpilers" (tsc and esbuild), and only one is used in the compilation step. The JSX transform is performed by esbuild, rollup is a bundler, TypeScript is only used during development, tailwind is not a transpiler at all and PostCSS only transforms CSS for greater compatibility.
Modern React components aren't reusable across projects with varying design requirements because the design is hardcoded in the component.
None of these things are inevitable in React. It's a really bizarre example because this only seems to point to a specific limitation/design flaw on Shadcn specifically.
By contrast, Hyper colocates your typography concerns into a single CSS file, acting as the single source of truth for your h2 an p element styling: [global styling]
If your argument is that components are not reusable across projects, then it's really funny that you're applying your styles globally. What if I don't want my paragraphs to look like that? Then I have to manually override it, duplicating CSS code. This is also legitimately just possible with "Modern React", you can just add CSS and use it however you'd like.
cryptic utility classes like dark:bg-lime-400/10 size-[max(100%,2.75rem)]—is systematically eliminated.
You mean you're not using Tailwind. Which is possible in React.
Nue is the "framework" (think Next.js + Astro, but simpler)
Next.js and Astro are both frameworks which are totally incompatible with one another.
This whole article seems to stem from a fundamental misunderstanding of (or a lack of desire to understand) what React is or does, and how to fix it. It's genuinely impressive that you were able to build a framework from scratch instead of just... googling your issues? Some of these were solved ages ago and don't require a whole new stack to be created.
I also believe there is a real argument to be made against React everywhere, but that is beyond the scope of this comment. What I can say is that this comparison would be a lot better if it were against Astro or SvelteKit, which will solve most of the issues you have (boilerplate and bundle size), while also providing a much better supported experience.
This seems incredibly shortsighted. If you're building an application by yourself you're gonna remember the relations and dependencies - but even on a small team (say ~4 devs) or even if you don't pick it up after a while, there is going to be stuff you forget.
It's also nice when you move stuff around, you can rely on the LSP to rename and fix everything that breaks. If you have a simple website it's fine, but when you start to have multiple components... Losing typing is a huge deal.
I'm not sure if I got this correctly, but it seems like you're misunderstanding what Vite actually is or does.
For having built what is essentially a bundler, I would've guessed you were more familiar with what it does, or, perhaps even have used it to build your tool.
Vite can bundle framework-less html files. It can create an SPA without any JS faff. You just have to point it to the right direction. When you instantiate a Vite app, you have to make the conscious decision to use React under the hood.
As for Nue, I think it's a cool idea, but I don't see what it does that I couldn't do with Astro, which has way larger community support and can work with pretty much all JS frameworks OOB.
BTW, I think it's really disingenuous to compare a React SPA bundle with an SSG output. You have essentially no functionality for handling state mutations beside events. You could achieve a much better middle ground by using a compiled framework like Svelte or Solid.