291–300 of 540 posts
Earlier quoted context omitted.
You literally just run: > npx create-next-app@latest Press Enter a few times for default settings and voila, you have a hello world app up and ready to run.
Just because it’s a one liner to install something doesn’t mean you aren’t installing a big, complex, over-engineered thing.
I get the impression that React is trying hard to catch up with the more modern, easier, faster and cheaper alternatives. But instead of fixing the root problems (rerendering and often required memoization, leaky abstractions) and make React easier, it becomes more complex. If the end result was great, I would understand all the effort. But it isn't. React is even slower in real world than the benchmarks show. Next i…
https://react.dev/blog/2023/03/22/react-labs-what-we-have-be...
Earlier quoted context omitted.
After kicking and screaming about learning yet another React framework I took the time to build an app fresh in NextJS and it really was a breath of fresh air, felt more like a mature, simpler form of React.
Feels like bloated garbage to me. "Hold on, let me make an MVC React framework with a Node API, so you can call your APIs from another API!". Thanks Next.js. Really wanted this. Honestly, might as well go back to Angular at that point - no redundant "API" there, at least. Also, automagic, automagic everywhere. "Let me just intercept your request and send it to a HANDLER, wow." "Let me just have a magical 'getServerSi…
It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left.
const { count, setCount } = useState(0);
let count = 0;
Vanilla JS libraries typically work out if the box with it without some bespoke wrapper or adapter for your framework. ("bind:this" is really handy.)
Web development with 99% less BS. Lets you focus on your problem, not on your framework's abstraction leaks.
Earlier quoted context omitted.
Feels like bloated garbage to me. "Hold on, let me make an MVC React framework with a Node API, so you can call your APIs from another API!". Thanks Next.js. Really wanted this. Honestly, might as well go back to Angular at that point - no redundant "API" there, at least. Also, automagic, automagic everywhere. "Let me just intercept your request and send it to a HANDLER, wow." "Let me just have a magical 'getServerSi…
Have you tried SvelteKit yet? I can't say it lacks magic, but that magic is focused on eliminating boilerplate, not hiding where everything is coming from and going to. It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left. const { count, setCount } = useState(0); becomes let count = 0; There is no more useMemo(…) or useEffect(…). They just don't exist.…
Not sure if the OP is here but on Firefox clicking the "API reference" button on the top left causes the full page transition to stutter. The profiler says more than 150ms is spent in a getBoundingClientRect call in a componentDidMount triggering reflow + style computation and 30ms on set Element.innerHTML. That seems excessive especially since I'm looking at this on a recent M1 Macbook.
Earlier quoted context omitted.
You are using one. Craigslist is the canonical example. There are actual forums of normies and the most notorious meme factory on the internet is hardly a wonder of UX technology. We are not on some subreddit for a reason.
> We are not on some subreddit for a reason. This has other reasons though, like the fact that this site has better moderation and better users in general.
The simple truth is people are drawn to websites for what they get out of them.
Earlier quoted context omitted.
Basically avoiding the mistake Angular made (moving from 1.x to 2+)
And yet Angular is now the less complicated framework and easier to work with (IMO).
Earlier quoted context omitted.
Hah, that breed of management predates the JS world of crap. My current manager sees no problem in the job postings ridiculously listing every single language/platform we have worked with, even 30 year old 8086 projects, even when any new hire will most likely be touching none of that and will be writing some mundane C for an ARM. "It doesn't hurt to list everything!" - Him "Why the fuck would someone want to apply t…
I'm thinking of joining Kroger to help with the Albertsons merger. They are looking for Java developers, cool, some sanity. Learned they have decided to build all new stuff in Go. Like WTSF people? I can find no justification for building mundane business systems in Go. Ugh...managers.
Or you're on AWS moving toward a more event-driven or serverless architecture where Java doesn't really have the same flexibility (and you don't want to retool your builds for GraalVM)? Go lambdas are really fast and trivially easy to write.
You want substantially faster build times to reduce developer idle wait cycles?
There are plenty of reasons to move to Go.
(Note: I last coded a Java service last year in v17, and my first Java code was using v1.02. I'm no Java hater.)