101–110 of 288 posts
Hah... I was bored and decided to just press the update button on all of my dependencies. I spend 2 hours changing things pointlessly and then deleted the branch and read why any of these updates were necessary. React Router - "wow, we have an amazing new v6"... *reads the "why upgrade"... "it has hooks now", ok they are already in the version I am using (5.2). "it has some changes to how you specify routes and you w…
"When your company won't be the first to market, because about 20% of your total development capacity needs to spent on keeping up" In the world of JS and Typescript this ratio looks more like 80%. I swear that node hipsters at my last job spent four out of five of their working days wrangling with dependencies or their transpilers, linters, packagers, bundlers and whatever the hell else needs to happen to actually m…
Timely. I was recently force upgraded to Win11. Today in fact. Last week I force-downgraded after I got an exception because it is my busy time of year. That exception was not respected and I realized fighting it weekly would be the same time investment as fixing compatibility issues. "What compatibility issues? Win11 is fine, I have had no problems." My coworkers say. Well on Day 1, 2 pretty important pieces of soft…
Just cannot accept things changing without my consent on my workstation.
"When your company won't be the first to market, because about 20% of your total development capacity needs to spent on keeping up" In the world of JS and Typescript this ratio looks more like 80%. I swear that node hipsters at my last job spent four out of five of their working days wrangling with dependencies or their transpilers, linters, packagers, bundlers and whatever the hell else needs to happen to actually m…
I’m not a TS, JS, or node fan. But if you really believe that it takes 80% of a dev’s time, week after week, to wrangle dependencies etc in ANY stack, you are either incredibly naive or really bad at math. And if developers at your company got away with that, I’d be leaving that company ASAP.
Can not agree with the React part though.
They keep so many things backward compatible. React 16 is 3, 4 years old now? I've updated pretty big code base from early 16 to latest 16 version painlessly - like in a day. Used some of the available code-modes for some really old part of the project. It worked flawlessly. Currently there are console warnings to fix certain things and that is it. No breaking changes, no nothing.
Now, React 17 will be a problem - there are a lots of 3rd party UI libs that will not work with it. But I think we are pretty well set to use react 16 for the next couple of years, making it work for 6, 7 years total. I think that is a century in terms of FE and is great.
Also, "...React pulling a sneaky on everyone and introducing hooks, which was a pretty bad move, especially if you needed to migrate to them" - just don't use hooks then - no problem.
Upgrade everything all the time and it will never be hard. You'll have full context for breaking changes, and the diff from A to B is always smaller than from A to Q, and less likely to break in strange and confusing ways.
I feel the pain, seeing non-trivial updates for Ruby, Elasticsearch and Postgres (thanks AWS) this year. Can not agree with the React part though. They keep so many things backward compatible. React 16 is 3, 4 years old now? I've updated pretty big code base from early 16 to latest 16 version painlessly - like in a day. Used some of the available code-modes for some really old part of the project. It worked flawlessl…
From ignorance, it seems like react has changed a fair amount during its lifetime, in terms of good practices, features available, etc. Where can one find resources that are both complete for a begginer and not outdated?
Earlier quoted context omitted.
This is why I badly want all updates and rollbacks to be as declarative and simple as Git commands. "Be on this version. Now."
For workstation use I most definitely don't. Linux 5.13 has several regressions that make it unbootable on my system. Sure, i can btrfs/nix/ehatever rollback to 5.12 pretty easily.... and then what? Stuck in 5.12 for thr rest of my life? Hope that someone fixes it by chance? What i mean is that I value decent changelogs, ability to diff changes between package versions, etc. much more. When a package regresses on my…
Well if you wanna debug it, go back to 5.13. I just mean I want Nix or Guix style declarative systems.
I feel the pain, seeing non-trivial updates for Ruby, Elasticsearch and Postgres (thanks AWS) this year. Can not agree with the React part though. They keep so many things backward compatible. React 16 is 3, 4 years old now? I've updated pretty big code base from early 16 to latest 16 version painlessly - like in a day. Used some of the available code-modes for some really old part of the project. It worked flawlessl…
Sort of off topic I guess, but: if I wanted to learn react nowadays (coming from extensive backend experience but not much in the front end) where should I start? From ignorance, it seems like react has changed a fair amount during its lifetime, in terms of good practices, features available, etc. Where can one find resources that are both complete for a begginer and not outdated?
As for changes during its lifetime, I would say that it is fairly on par for most web-focused frameworks, both front and backend. You could look at how ASP.NET has changed over the last few versions for example and see it being similar to React’s changes. The largest changes in React recently have been a greater focus on moving from syntactic sugar JS classes to pure functions, and React Hooks that go along with that. There’s definitely a shiny things syndrome you get if you just google for React tutorials, which is a bit annoying, but the official docs are pretty solid, and a few of the core devs are great to follow from a philosophical standpoint (like @dan_abramov).
Hope that helps!