7 ms·

I’ve seen C#/Java projects with just as many dependencies, but much inferior dependency management. To be honest, this reads like you’ve only experienced front

I’ve seen C#/Java projects with just as many dependencies, but much inferior dependency management. To be honest, this reads like you’ve only experienced frontend from the outside, it’s really not that bad. Besides all the croft is still pretty much optional, you don’t really need that much in 2023 to create something nice, but as frontend engineers we typically care about the code not becoming a total mess, because of lots of prior burns, that’s why i always introduce mandatory linting and formatting as a pre-commit hook where ever i can. It’s such a small thing, but boy is it nice when all the code always looks and feels more or less the same. I’ve tried the same for C# but it seems like the community does not care to the same degree.

spion 3y ago
I've spent 12 years in the JS ecosystem. It really is that bad and it got significantly worse in the past couple of years. It was hard to see it however until I tried working in some of the newer ecosystems like Elixir, Rust, Go. Things break all the time and a variety of tools and technologies just don't work with eachother. Making choices is like stepping on land mines - tomorrow the ecosystem might decide that choice was wrong and abandon all effort into it (e.g. next server components breaking most css-in-js libraries). It doesn't have to be this way, there are ecosystems where this is not the case. Despite that there is still a lot to like and enjoy. TypeScript is really excellent, building UI with things like tailwind can be a pure joy when you get into the flow, reactivity libraries like MobX / Solid and frameworks like Svelte largely make you feel like you're only writing business logic when managing state, etc. But overall the ecosystem is extremely "internally incompatible" for lack of a better word
- spion 3y ago
  here is a sample of well-meaning maintainers franatically trying to deal with situations like these and maintain some semblance of compatibility https://phryneas.de/react-server-components-controversy https://phryneas.de/react-server-components-controversy
- throwitaway1123 3y ago
  > next server components breaking most css-in-js libraries This is a legitimate gripe, and React Server Components in general have introduced a lot of complexity. It's worthing noting though that you don't have to use server components and Next's new App Router. The Pages Router still works. I'm ok with a framework occasionally (not excessively) introducing a new way of doing things as long as the old way is still supported (much like React still supports class components despite the introduction of hooks).
  - spion 3y ago
    My point is that this sort of thing doesn't happen so lightly in other ecosystems. And the "you don't have to use it" excuse isn't used when the project clearly wants to move in that direction: - others will jump on the feature and use it. you might not have to use it but libraries you depend on may decide otherwise and rewrite - you didn't have to use ReactHooks, but try using Apollo client or react-query without them now, or try finding any non-hooks documentation in general. - you will slowly see bugs being neglected if they're not about the new and shiny. - there is no equivalent of useContext for class components So the word "supports" here carries very little weight in practice because the rest of the ecosystem constantly rewrites.
    - throwitaway1123 3y ago
      > My point is that this sort of thing doesn't happen so lightly in other ecosystems. React has been around for 10 years (almost 11 since we're a few days away from 2024). Many of the ecosystems you're holding up as the epitomes of stability have had their fare share of large scale changes in that same time frame. Remember go before generics, or Rust before async landed [1]? Elixir's Phoenix didn't even have its first commit when React was released [2]. > there is no equivalent of useContext for class components Class components can still use context [3]. They obviously can't use the useContext hook, because class components aren't compatible with hooks, but that's kind of a tautology. > you didn't have to use ReactHooks, but try using Apollo client or react-query without them now, or try finding any non-hooks documentation in general. Library authors moved to hooks because sharing stateful logic was difficult before hooks. I never bought into the GraphQL hype train, but I remember there being a ton of verbose render props necessary to make GraphQL libraries like Apollo work before hooks. I don't think anyone really complained about data fetching libraries adopting hooks. You could argue that the react devs should have created the perfect library in 2013 complete with hooks, but I can forgive them for not having perfect foresight. Like I said, if an API changes occasionally over a decade I'm ok with it. Technology should be stable, not frozen. [1] https://areweasyncyet.rs/ https://areweasyncyet.rs/ [2] https://groups.google.com/g/phoenix-talk/c/l8kIhc_LC7o https://groups.google.com/g/phoenix-talk/c/l8kIhc_LC7o [3] https://legacy.reactjs.org/docs/context.html#classcontexttype https://legacy.reactjs.org/docs/context.html#classcontexttyp...
neonsunset 3y ago
C# has https://github.com/dotnet/format https://github.com/dotnet/format but because C# is, well, not JS, the importance of linting is far less significant. Instead, there are hundreds of out-of-box analyzers that highlight problematic patterns or likely mistakes in the code and there are even more that you can enable through extensions (like Roslynator) or through packages that are 'dotnet add package' away. On the package management - it couldn't be more different between Java and C# and it's incorrect to compare the two. .NET has few if any issues of the former.

spion 3y ago

I've spent 12 years in the JS ecosystem. It really is that bad and it got significantly worse in the past couple of years. It was hard to see it however until I tried working in some of the newer ecosystems like Elixir, Rust, Go. Things break all the time and a variety of tools and technologies just don't work with eachother. Making choices is like stepping on land mines - tomorrow the ecosystem might decide that choice was wrong and abandon all effort into it (e.g. next server components breaking most css-in-js libraries). It doesn't have to be this way, there are ecosystems where this is not the case. Despite that there is still a lot to like and enjoy. TypeScript is really excellent, building UI with things like tailwind can be a pure joy when you get into the flow, reactivity libraries like MobX / Solid and frameworks like Svelte largely make you feel like you're only writing business logic when managing state, etc. But overall the ecosystem is extremely "internally incompatible" for lack of a better word

spion 3y ago
here is a sample of well-meaning maintainers franatically trying to deal with situations like these and maintain some semblance of compatibility https://phryneas.de/react-server-components-controversy https://phryneas.de/react-server-components-controversy
throwitaway1123 3y ago
> next server components breaking most css-in-js libraries This is a legitimate gripe, and React Server Components in general have introduced a lot of complexity. It's worthing noting though that you don't have to use server components and Next's new App Router. The Pages Router still works. I'm ok with a framework occasionally (not excessively) introducing a new way of doing things as long as the old way is still supported (much like React still supports class components despite the introduction of hooks).
- spion 3y ago
  My point is that this sort of thing doesn't happen so lightly in other ecosystems. And the "you don't have to use it" excuse isn't used when the project clearly wants to move in that direction: - others will jump on the feature and use it. you might not have to use it but libraries you depend on may decide otherwise and rewrite - you didn't have to use ReactHooks, but try using Apollo client or react-query without them now, or try finding any non-hooks documentation in general. - you will slowly see bugs being neglected if they're not about the new and shiny. - there is no equivalent of useContext for class components So the word "supports" here carries very little weight in practice because the rest of the ecosystem constantly rewrites.
  - throwitaway1123 3y ago
    > My point is that this sort of thing doesn't happen so lightly in other ecosystems. React has been around for 10 years (almost 11 since we're a few days away from 2024). Many of the ecosystems you're holding up as the epitomes of stability have had their fare share of large scale changes in that same time frame. Remember go before generics, or Rust before async landed [1]? Elixir's Phoenix didn't even have its first commit when React was released [2]. > there is no equivalent of useContext for class components Class components can still use context [3]. They obviously can't use the useContext hook, because class components aren't compatible with hooks, but that's kind of a tautology. > you didn't have to use ReactHooks, but try using Apollo client or react-query without them now, or try finding any non-hooks documentation in general. Library authors moved to hooks because sharing stateful logic was difficult before hooks. I never bought into the GraphQL hype train, but I remember there being a ton of verbose render props necessary to make GraphQL libraries like Apollo work before hooks. I don't think anyone really complained about data fetching libraries adopting hooks. You could argue that the react devs should have created the perfect library in 2013 complete with hooks, but I can forgive them for not having perfect foresight. Like I said, if an API changes occasionally over a decade I'm ok with it. Technology should be stable, not frozen. [1] https://areweasyncyet.rs/ https://areweasyncyet.rs/ [2] https://groups.google.com/g/phoenix-talk/c/l8kIhc_LC7o https://groups.google.com/g/phoenix-talk/c/l8kIhc_LC7o [3] https://legacy.reactjs.org/docs/context.html#classcontexttype https://legacy.reactjs.org/docs/context.html#classcontexttyp...

neonsunset 3y ago

C# has https://github.com/dotnet/format https://github.com/dotnet/format but because C# is, well, not JS, the importance of linting is far less significant. Instead, there are hundreds of out-of-box analyzers that highlight problematic patterns or likely mistakes in the code and there are even more that you can enable through extensions (like Roslynator) or through packages that are 'dotnet add package' away. On the package management - it couldn't be more different between Java and C# and it's incorrect to compare the two. .NET has few if any issues of the former.