Earlier quoted context omitted.
or directly in powershell, `Start-Process myproc.exe -Environment @{ FOO = 'bar' }`
What an absolutely awful syntax. How Powershell ever got popular is beyond me.
Right? This is your brain on Windows.
Next.js is infuriating
481–490 of 602 posts
Re: Next.js is infuriating
#482I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else. In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts. Next.js is easily the worst technology I've ever used.
Sounds like Javascript's answer to Spring.
Java Spring is at root a way to combine large software components (singletons) together in a controlled manner (dependency injection). It doesn't really have an opinion on what you do with it, or even if you use it for webapps. In fairness the Servlet API (which predates Spring) was and always has been really good (which is why it's still the foundation of everything webapp in the Java ecosystem). Oddly enough, logging in Java was a mess but became really good when slf4j and logback became the de facto standard. The OP's problem is trivial in Java, Spring, Spring Boot, or Dropwizard.
Java doesn't offer isomorphic React SSR, but in most cases that is a questionable feature. Most SPAs don't need or want search-engine indexing or require instantaneous-seeming load times.
Re: Next.js is infuriating
#483Earlier quoted context omitted.
This is a silly no true scotsman argument. First you don't say what you mean and then stick up your nose when no one has any idea what you're on about. Anyone is capable of making up an arbitrary set of requirements that no language nor framework fulfills. This doesn't change the fact that for most languages and frameworks, logging is a boring, solved problem. That Next.js doesn't bring that to the table is more than…
Nope my dear, you're the one insinuating that logging works out of the box in production quality deployment without any kind of additional configuration or code changes, hence please make use happy, where that is the case. Word vomit into standard output isn't production quality .
It seems you might've missed functional reading class. The first thing I led with was that you need to import and initialize logging which covers both of those. You're the only one insinuating the strawmen you're arguing against. This isn't Reddit, surely you can do better.
Re: Next.js is infuriating
#484nuxt.js is also infuriating and we need another article on it
Re: Next.js is infuriating
#485Earlier quoted context omitted.
> My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting That is my opinion as well. Things like SSR are forced onto users with a very smooth onboarding, but I'm concerned that in practical terms this perceived smoothness can only persist if the likes of us pay the likes of Vercel for hosting our work. In some degree I f…
Might have? The official React docs recommend Next. That capture happened... two years ago? (Perhaps there's a good blog post there, if it doesn't exist already)
Yes - there's been a very obvious shift in the "official" React positions over the last 2-3 years. It's regrettable that they have moved so sharply away from the simplicity and "doing one thing well" philosophy that made React so successful in the first place. I've used React since those early days and built successful, long-lived projects with it so I'm genuinely sad to see it fall so hard.
Objectively that sadness does not change reality however. At least within my own professional network no-one seems comfortable starting a new project using React today. Almost 100% of the paid front end work I've been involved with myself or discussed with others recently is now using alternatives - most often Vue though I've seen other choices at least seriously considered. I've even had a couple of recruiters I haven't worked with for years suddenly reappear desperately looking for someone to take on React work and openly admit it's because they are struggling to find anyone good who wants to go near it. All of this is a sharp contrast with the market of the early 2020s when React was clearly the preferred front end choice. And all of this is surely a direct response to the push to make React a full stack framework, the added complexity that has introduced, and the apparent capture of official React development by Vercel.
Re: Next.js is infuriating
#486My 2cents: Nextjs with page router was a very nice (and simple to learn but powerful) framework.
I have always developed backend apis in nodejs with express and used Nextjs for frontend only and just when I needed SSR.
Developing projects this way had always been a joy.
App router did change everything and destroyed the good reputation of Nextjs: it is hard to learn, to manage and does offer few concrete advantages
Re: Next.js is infuriating
#487Maybe this is a good place to ask... but I was actually considering Next.js as a replacement for Gatsby.js project that is a few years old, but is growing at a steady pace. Given all the negative sentiments, what are better alternatives? I don't even use any SSR, or GraphQL capabilities. The main thing I liked about gatsby vs previous "bring your oown library(router)" are: very little configuring, nice dev server, ea…
I've rebuilt multiple gatsby projects in NextJS recently, and mostly it's actually been pretty nice. However, the crazy high level of abstraction and black-boxing does mean occasionally we run into bugs caused by undocumented behavior and have no idea what is the right way to handle them.
Hmmmm, that sounds like it would work, but is also a bit concerning :) I’d rather not have some mystery bugs, and considering all the open issues in GitHub…
Re: Next.js is infuriating
#488nuxt.js is also infuriating and we need another article on it
oh no
Re: Next.js is infuriating
#489Earlier quoted context omitted.
Sounds like Javascript's answer to Spring.
Java Spring is at root a way to combine large software components (singletons) together in a controlled manner (dependency injection). It doesn't really have an opinion on what you do with it, or even if you use it for webapps. In fairness the Servlet API (which predates Spring) was and always has been really good (which is why it's still the foundation of everything webapp in the Java ecosystem). Oddly enough, loggi…
Best explanation of spring I have ever read.
And while Spring has it's rough edges and quirks it is still an incredibly stable framework. Next, on the other hand, is a box of surprises that keeps on giving even when you think you saw it all.
Re: Next.js is infuriating
#490Earlier quoted context omitted.
Only 3/40 Svelte maintainers work at Vercel and they mainly finance work on Svelte core. SvelteKit day-to-day is primarily maintained by folks outside Vercel
A little disingenuous to say “only 3/40” maintainers. Which 3? And how percentage of the total work hours invested per month do those 3 represent?
The number 3, 4, and 5 contributors to SvelteKit in the past year work at Vercel:
https://github.com/sveltejs/kit/graphs/contributors?from=8%2...
Rich and Simon are incredibly important, but they're in it for Svelte and the community more so than a paycheck from Vercel. Tee has been doing most of the maintenance on SvelteKit currently funded by community donations. And this isn't counting other infrastructure like vite-plugin-svelte or the Svelte CLI which are entirely maintained by volunteers. I don't think Vercel funds a majority of the work on Svelte even if it might be close to it.