5 ms·

>> actually listening to developers and looking at how the space develops instead of chasing own vanity projects. This is what WHATWG is. It is also why everyt

>> actually listening to developers and looking at how the space develops instead of chasing own vanity projects. This is what WHATWG is. It is also why everything is "worse" and "better" than when it was just the w3c. I don't think we have had clear, cohesive, design intent for the front end/browser in more than a decade, and it isn't getting better. I spent years working in PHP, and my life is better in Go and C... I would rather work in circa 2004 PHP code than what modern JS looks like. The whole stack of framework, tooling, linting/ts, node/bun, build/transpile... SO. Many. Dependencys... I had a 10 minute conversation on what the fuck a "thunk" is and why I would want to use it yesterday, this is the front end of 2023/4 And I give credit to front end engineers for keeping it all going, frankly there isn't enough cocaine in Columbia to get me to do it. But I'm not sure any of the people who think that this is OK or its how to build a web page are the ones we should be letting ADD features to a stack we want to be backwards compatible. Its how we end up with stray stuff like web components and shadow dom that never live up to the promise and then we drag them around for the rest of time cause space jam and what ever comes after still needs to render. I'm gonna go back to the back end, I would rather face down the expensive foot gun of autoscaling than risk my sanity working in the front end.

Izkata 3y ago
> I had a 10 minute conversation on what the fuck a "thunk" is and why I would want to use it yesterday, this is the front end of 2023/4 I believe I remember hearing thunks were old-school and nowadays it should be done with sagas... Like 4-5 years ago.
solumunus 3y ago
It’s really not that complicated.
- j4yav 3y ago
  Move your bundler and the god awful mess happening inside the node_modules folder down to the basement (make sure to put up a "beware of the leopard" sign so nobody accidentally gets hurt) and it's actually pretty nice. Sort of.
spyke112 3y ago
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).
throwitaway1123 3y ago
> "The whole stack of framework, tooling, linting/ts, node/bun, build/transpile... SO. Many. Dependencys... I had a 10 minute conversation on what the fuck a "thunk" is and why I would want to use it yesterday, this is the front end of 2023/4" Frontend hate is so prevalent on HN that you can literally cough up word salad and get upvoted as if you've just crafted a cogent technical argument. Thunks predate the invention of JavaScript by the way.
- arcbyte 3y ago
  Thunks in javascript are barely related to historical thanks. There's so little overlap that they're borderline tangential. And to the OP's argument, he's really just recounting his experience. It's a widely shared experience as you've admitted. There's a huge coterie of people who have seen things done well and seen things done badly, and while we ALL would admit modern javascript has brought some improvements over the old ways, we also believe the tradeoffs are rarely worth it and we are still building and searching for ways that are in line with the best paradigms we've seen.
  - throwitaway1123 3y ago
    > Thunks in javascript are barely related to historical thanks. There's so little overlap that they're borderline tangential. Thunks in JS are exactly the same as thunks in any other language. I would love to hear your explanation of the technical differences. You're trying your hardest to salvage some semblance of an argument from OP's rant. > And to the OP's argument, he's really just recounting his experience. He hasn't recounted a single experience, besides his frustration with understanding thunks (which as I've said isn't even a JavaScript exclusive topic). He's literally just regurgitated a list of programming terms (many of which aren't even exclusive to frontend programming). I criticized OP for not formulating a technical argument, and you've somehow responded with an even less technical argument.

Izkata 3y ago

> I had a 10 minute conversation on what the fuck a "thunk" is and why I would want to use it yesterday, this is the front end of 2023/4 I believe I remember hearing thunks were old-school and nowadays it should be done with sagas... Like 4-5 years ago.

solumunus 3y ago

It’s really not that complicated.

j4yav 3y ago
Move your bundler and the god awful mess happening inside the node_modules folder down to the basement (make sure to put up a "beware of the leopard" sign so nobody accidentally gets hurt) and it's actually pretty nice. Sort of.

spyke112 3y ago

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).

throwitaway1123 3y ago

> "The whole stack of framework, tooling, linting/ts, node/bun, build/transpile... SO. Many. Dependencys... I had a 10 minute conversation on what the fuck a "thunk" is and why I would want to use it yesterday, this is the front end of 2023/4" Frontend hate is so prevalent on HN that you can literally cough up word salad and get upvoted as if you've just crafted a cogent technical argument. Thunks predate the invention of JavaScript by the way.

arcbyte 3y ago
Thunks in javascript are barely related to historical thanks. There's so little overlap that they're borderline tangential. And to the OP's argument, he's really just recounting his experience. It's a widely shared experience as you've admitted. There's a huge coterie of people who have seen things done well and seen things done badly, and while we ALL would admit modern javascript has brought some improvements over the old ways, we also believe the tradeoffs are rarely worth it and we are still building and searching for ways that are in line with the best paradigms we've seen.
- throwitaway1123 3y ago
  > Thunks in javascript are barely related to historical thanks. There's so little overlap that they're borderline tangential. Thunks in JS are exactly the same as thunks in any other language. I would love to hear your explanation of the technical differences. You're trying your hardest to salvage some semblance of an argument from OP's rant. > And to the OP's argument, he's really just recounting his experience. He hasn't recounted a single experience, besides his frustration with understanding thunks (which as I've said isn't even a JavaScript exclusive topic). He's literally just regurgitated a list of programming terms (many of which aren't even exclusive to frontend programming). I criticized OP for not formulating a technical argument, and you've somehow responded with an even less technical argument.