The real question is how the hell some circles were able to push such complexity onto mainstream tech and what will it take to prevent it from happening again.
Next.js is infuriating
581–590 of 602 posts
Re: Next.js is infuriating
#582Does anybody have Vercel's mailing address? I would like to send them a "Have a good day at school!" card for this issue, which will be old enough to attend elementary school next year: https://github.com/vercel/next.js/issues/10084
Main address (if a company registered address): 440 N Barranca Ave #4133, Covina, CA 91723
Re: Next.js is infuriating
#583Earlier quoted context omitted.
What specifically is heavyweight about OTEL? At its core it's a standard for producing structured logs along with some standards for exporting/collection. The heaviness is really implementation-specific and can vary stack to stack There's even a handler for monolog in PHP - they are not necessarily mutually exclusive https://github.com/open-telemetry/opentelemetry-php/blob/mai...
Yes but instead of just logging to a text file for example you need OTEL, thats my point. The fact that Monolog has a handler for this tool isnt relevant, but it shows that there is one more layer of complexity tacked on.
That doesn't really mean it's heavyweight though; an extra layer, sure (but I don't even really agree that it's complex - you set it up once and then mostly just log the same way you would with any other).
You can still log to a text file if you want to run locally, but for something like next.js where you're intended to deploy production to some cloud somewhere (probably serverless) the option of _just_ writing to a text file doesn't really exist. So having OTEL as an ootb supported way to do o11y is much better than the alternative of getting sucked into some vendor-specific garbage like datadog or newrelic
Re: Next.js is infuriating
#584Earlier quoted context omitted.
> Why can’t logger().info() just work in a sensible way? I think OTEL is pretty sensible for a vendor-free and if you want to have a console logger you can use the console exporter[0] for debug mode during local development. Also if Next is designed as a framework to make it easy to build production-grade apps, having a standardized way to implement o11y with OTEL is a worthwhile tradeoff? If you view that as being o…
Because making it easy to run and monitor NextJS is never in their interest. The difficulty of that is what pushes people that make it to production with Next onto their platform. The goal is to provide more impressive preoptimizations that complicate the stack more and make it more difficult to run NextJS yourself and actually use any of them.
I don't really know anything about self-hosting Next apps - but if you're deploying to k8s, it's not really that difficult or far-fetched to run an otel collector sidecar for your applications. It's already common to run some kind of prometheus scraper or other service to collect logs/metrics from your services but instead of having to have different collection methods for APM vs logs vs traces you can have it all aggregated in one place using OTLP format
Re: Next.js is infuriating
#585I 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.
This. It's what inspired me to build a static site generator and web framework built from first principles: https://mastrojs.github.io
Re: Next.js is infuriating
#586Earlier quoted context omitted.
"Frontend" is literally the integration of Web Platform APIs. So you need (1) the knowledge of what platform APIs exist (2) the ability to reason about existing abstractions (3) the ability to define abstractions. In modern life all three are considered unsafe things. Therefore to prevent people from entering invalid states exists The Framework: useless abstraction layer that does nothing besides be conventional . Th…
I don’t think you actually answered the question but I totally don’t mind because it was a fun read. Old Vue is nice, we still have some Vue apps and they’re just running without major headaches. I do recall some distinct issues with properties introduced on objects after initiating the component not being reactive, but it has mostly been an acceptable experience
>I don’t think you actually answered the question but I totally don’t mind because it was a fun read.
That's probably the better outcome here. If you know enough things to find what I wrote entertaining, rather than vexing, chances are you're able to pick right tools for jobs just fine.
Meanwhile treadmills are gonna treadmill; if I've got one answer to everything it's to stay off them. Mighty difficult when everyone's trying to drag you onto one.
I do recall some distinct issues with properties introduced on objects after initiating the component not being reactive
Wasn't that what they fixed using Proxy (making ES6 finally a hard requirement for anything at all)?
>Old Vue is nice, we still have some Vue apps and they’re just running without major headaches. >but it has mostly been an acceptable experience
Better than one could say about the current generation stacks. Big vibe like vendors are trying to cargocult ZIRP-associated patterns (as if those were what produced value in pre-2020s Web and totally not all the human creativity that used to be channeled into the medium before the masks started falling off.)
Re: Next.js is infuriating
#587Re: Next.js is infuriating
#588Earlier quoted context omitted.
I don’t think you actually answered the question but I totally don’t mind because it was a fun read. Old Vue is nice, we still have some Vue apps and they’re just running without major headaches. I do recall some distinct issues with properties introduced on objects after initiating the component not being reactive, but it has mostly been an acceptable experience
>I don’t think you actually answered the question but I totally don’t mind because it was a fun read. That's probably the better outcome here. If you know enough things to find what I wrote entertaining, rather than vexing, chances are you're able to pick right tools for jobs just fine. Meanwhile treadmills are gonna treadmill; if I've got one answer to everything it's to stay off them. Mighty difficult when everyone…
> Wasn't that what they fixed using Proxy (making ES6 finally a hard requirement for anything at all)?
Maybe, but I haven't touched Vue in a long time.
> Better than one could say about the current generation stacks.
For sure. I still have some projects that use what I like to call "jQueryScript", where there's just a bunch of unprocessed (or only minified) JS files with `$("#foo").click(function() { ... })` stuff everywhere. Looking back, it wasn't all that bad.
I just wish there was a pattern that is simple, works with plain, modern JS without any big dependencies (I don't want 600 node modules installing a frontend framework, please) and is easily modular and integrates nicely with other stuff (so likely either manipulating DOM nodes directly or using WebComponents)
Out of protest, I have some smaller projects that have their GUI templates stored in `` tags and manipulated with plain Javascript. Anyone that opens the code will see it and think "wtf?" and then be like "oh... uh sure". The largest one I had written was 1000s of lines of code like that, kinda like a classical MVC pattern where a view (class manipulating DOM nodes) renders a model (a JS object or class). The controller would subscribe to custom events (defined by the view), update the model and call `render()` on the view. It had a lot of small classes, which was a bit too verbose to my liking.
Re: Next.js is infuriating
#589Earlier quoted context omitted.
Because making it easy to run and monitor NextJS is never in their interest. The difficulty of that is what pushes people that make it to production with Next onto their platform. The goal is to provide more impressive preoptimizations that complicate the stack more and make it more difficult to run NextJS yourself and actually use any of them.
I don't really know anything about self-hosting Next apps - but if you're deploying to k8s, it's not really that difficult or far-fetched to run an otel collector sidecar for your applications. It's already common to run some kind of prometheus scraper or other service to collect logs/metrics from your services but instead of having to have different collection methods for APM vs logs vs traces you can have it all ag…
Just by bringing up k8s you are making their point. It should be dead simple to do logging without having to set up hardly anything. I shouldn't even need to know what a sidecar container is.
Re: Next.js is infuriating
#590Earlier quoted context omitted.
> If it's PHP it's on the server. It's JS it's in the browser. Never needing to question that has been a huge boon for us. In what way has that been a boon? Context switching between languages, especially PHP, seems like an even bigger headache. Is it strlen($var) or var.length or mb_strlen($var)? Do you ever output JavaScript from PHP? My biggest question though is how do you avoid ever duplicating logic between js…
spoken like a middle manager. why would anyone send JavaScript from the php? why care about duplicating a couple json translations and null checks... it's all code is today anyway. and switching languages? you can't use most of js as it is. even something as simple as split() have so many weird bugs that everyone just code from a utils lib anyway.
Oh hey, insults. Those are fun.
spoken like someone who's not experienced enough to realize that duplicated code needs to be kept in sync, and then when it inevitably isn't, it'll lead to incidents, and also can't write JavaScript without using leftpad.