Hacker Timesnew | past | comments | ask | show | jobs | submit | more marcos100's commentslogin

I believe the future will be to feed all your docs into a LLM for people to query.


As a backend dev, I love the technology. The problem is that you have to choose between a not-so-scalable solution (Server, signalR) or a minimum 2mb initial payload (WASM) that can easily go to 5mb.

Interested on how many concurrent users you have for Server to be a problem. Can you elaborate more on your performance issues?


I may have made a mistake in designing the architecture of our app. Since we're a small team, I opted for a big ol' monolith, hosting our APIs on the same server as our Blazor Server app. We normally serve a few hundreds requests per second on our APIs, which is totally fine. However, sometimes we got some spikes up to thousands of requests per second, which has the unfortunate consequence that our Blazor Server app becomes laggy and starts to drop WebSocket connections frequently. So, now, we are in the process of moving our API controllers to another project, which will be hosted on a separate server.


Sounds like you did everything right then. Started off simple, now your business is taking off, failures aren't catastrophic (they're grey, not black, from what it sounds like) and splitting out a component shouldn't be too hard, so you'll be ready for more scale soon. All while maintaining the business!


.NET 8 solves that exact problem as far as I can see. You can opt into auto mode and it uses server side Blazor until the client downloads all assets, then in subsequent visits it uses the WASM runtime. Seems to be a good compromise.


Is 5MB a real problems? Theoretically it may look big, but I have seen many websites much bigger, not to mention all video/image we download are already skewing download by a lot. Considering runtime is cached for long time, I don't see a real blocker. First page render would be an issue but SSR solves that.


> Is 5MB a real problems?

Well if you want to make small fast loading html pages with a minimal js library, and end up at a few hundred KB that you can understand, profile and optimize, then that is impossible with blazor. So it's a very real problem.

If you want 5mb blobs and do not care about what is going on inside, how to optimize or reduce the memory and bandwidth usage, then it's not a problem, works just as well as the websites you have seen, with 200 node dependencies.


On a phone, 5MB it not ideal. On a corporate desktop, not an issue.


Exactly. At least you have to show that you know what you're doing and it's deliberate. Depending on the seniority, I expect some kind of justification in the comments, like "it's O(nˆ2), but since the input will be very small, it's ok".

In real life people do a lot of O(nˆ2) code without realizing, and usually it's just some unnecessary loop inside another loop. I want to know that you care about some things.


Rewriting also costs less. Be it a typo or significant parts of a code. This allows you to try more things.


Because "we don't have the budget".


That "we" may be too low on the org chart, and the qualified manager may not be aware of the problem.


Exactly! Gramma and my luddite uncle are the most vulnerable to whatever bad actors want to do.


Agree, but for me, maybe because I'm so used to not having them that, when I see it, it grabs too much attention. It doesn't feels right.


Here you have selection bias. If you're a US company and you have to bring someone from outside the US, you'll probably bring the better ones and, as someone already said, if they are fluent in English, they are probably at the top.

Come work for a Brazilian company to see the that we have mediocre people everywhere.


Unless you really want it, it's usually better to skip v1 of anything, Apple or not.


Didn't WhatsApp had like 50 employees in total when they were sold to Facebook?


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: