21–30 of 114 posts
Earlier quoted context omitted.
Just the fact that Yarn seems to be the dominant package manager now when it seems like last week it was npm. What will it be next week? I truly wonder, do people use this stuff for software that is expected to be maintained for 5-10 years? I feel that with the speed at which everything changes, gets deprecated, discontinued, succeeded, etc. you'll spend a good chunk of your time staying up to date with the current j…
Naw it's back to npm
Earlier quoted context omitted.
Just the fact that Yarn seems to be the dominant package manager now when it seems like last week it was npm. What will it be next week? I truly wonder, do people use this stuff for software that is expected to be maintained for 5-10 years? I feel that with the speed at which everything changes, gets deprecated, discontinued, succeeded, etc. you'll spend a good chunk of your time staying up to date with the current j…
Naw it's back to npm
In a better language, this would be the programmers choice on a case-by-case basis, with no need for the higher-ups to break or fix everyone's behaviour at once.
Either return a Page(Future(Components)) or a Future(Page(Components)).
I find it fascinating how frequently the best practices change, and how dogmatically people still want to follow best practices. As an industry, we spend absolutely incredible amounts of work refactoring working code into the new paradigm.
most of the js ecosystem is made of stream of consciousness kludge that is constantly being "refactored" and "deprecated"
effing tiresome as hell dealing with that sh-t...and this mentality seems to have seeped entirely into nu-dev as i see it also in other ecos now
Earlier quoted context omitted.
It's insane how toxic the js environment is. it seems like if a project is over 6 months old, nothing will work. When I yarn install on an old project, i'm rolling the dice. I had a 2 year old next.js side project i was working on and the amount of work to make it work the latest version with just updating the dependencies and reading the upgrade docs were infinitely more complex than just starting over from scratch.…
Just the fact that Yarn seems to be the dominant package manager now when it seems like last week it was npm. What will it be next week? I truly wonder, do people use this stuff for software that is expected to be maintained for 5-10 years? I feel that with the speed at which everything changes, gets deprecated, discontinued, succeeded, etc. you'll spend a good chunk of your time staying up to date with the current j…
What does dominant even mean in such a short term context? It hasn’t even been 10 years.
As far as companies go, we move so slowly that when someone brings up a tech fad, the fad is gone by the time the committee actually gets to decide. So we stick with the status quo.
I find it fascinating how frequently the best practices change, and how dogmatically people still want to follow best practices. As an industry, we spend absolutely incredible amounts of work refactoring working code into the new paradigm.
I have a harsher take, 95% where react is used it is used without the need.
Terrible shitshow. Web dev is all broken and horrible. Well at least the popular stuff is. No idea why anyone uses this outside resume building.
Earlier quoted context omitted.
You could already use functional components before. The main issue with React now is all these hooks and effects.
The whole point of hooks is to substantially simplify "effects stuff", as compared to the total uncomposability of class components. While the specific implementation of hooks has its bugbears, I think it's pretty telling that nobody else is using class components either, even in projects with fundamentally different engines like Svelte.
How do you mean? React components were composable from the get-go; this is practically the definition of a component: you take a piece of ui, you encapsulate it in a component, and then you can compose it with other components into more complex UIs.
Class components were reacting to component's life cycle as opposed to hooks that react to data changes; but there was nothing stopping you from extracting reusable pieces of logic into standalone functions and using them in lifecycle methods.
I thought the whole point of hooks was to support the React fiber architecture, because closures are immutable as opposed to class fields.