I see a lot less programming topics, in general.
Lots of political opinion posts. There seems to be an influx of non technical people posting culture war nonsense.
The people who left reddit due to the API pricing had to go somewhere I guess
Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?
101–110 of 136 posts
Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?
#102IMO a JavaScript revolution is quietly brewing. Today’s frameworks have gotten amazingly complicated and EcmaScript spec is gaining new capabilities at a rapid clip, so some of critical features for modern web dev is built in. This project is a great example of what’s coming https://www.arrow-js.com . I think the right move will become avoiding these large and complicated frameworks unless they’re truly called for.
That, while well intentioned, is probably wishful thinking. Large frameworks do not exist to provide technology capabilities or features. They exist to supplement skill deficits in people, primarily around architecture and composition, and any such features are built upon the stylistic premise they provide.
> They exist to supplement skill deficits in people, primarily around architecture and composition
That's just another hot take which makes no sense if you think about it. Being able to fit complex features into already existing abstractions is an even more sought after skill with frameworks than without. Frameworks exist to standardize architecture, not to mitigate skill issues.
Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?
#103IMO a JavaScript revolution is quietly brewing. Today’s frameworks have gotten amazingly complicated and EcmaScript spec is gaining new capabilities at a rapid clip, so some of critical features for modern web dev is built in. This project is a great example of what’s coming https://www.arrow-js.com . I think the right move will become avoiding these large and complicated frameworks unless they’re truly called for.
I’m starting to feel the same way. React’s big selling point when it came out was that it was “easy to reason about”, and that was true at the time. With hooks, server components, and 10,000 different strategies for managing state and side effects, I can’t say React is easy to reason about anymore. We can do things now that were impossible back then, but now we need to do even more than that, and it feels like it’s t…
Hooks are particularly bad to reason about. I can't figure out why hooks seems to be the official Way, it just leads to a bunch of spaghetti functions. The old object-oriented approach might feel old and creaky, but OOP was invented for user interface. Functional programming, not so much.
Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?
#104Earlier quoted context omitted.
How can you "fetch something when your state change ?". It's the main use case for useEffect.
You can just trigger fetch in the function that does the state change.
Agreed, this is the correct approach. Overusing effects makes control flow difficult to understand and has many unintended consequences. The misuse of effects is so widespread the React team had to address it with Strict mode in React 18.
Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?
#105Earlier quoted context omitted.
I’m starting to feel the same way. React’s big selling point when it came out was that it was “easy to reason about”, and that was true at the time. With hooks, server components, and 10,000 different strategies for managing state and side effects, I can’t say React is easy to reason about anymore. We can do things now that were impossible back then, but now we need to do even more than that, and it feels like it’s t…
Hooks are particularly bad to reason about. I can't figure out why hooks seems to be the official Way, it just leads to a bunch of spaghetti functions. The old object-oriented approach might feel old and creaky, but OOP was invented for user interface. Functional programming, not so much.
The why of hooks is actually easy to explain, it's just that nobody does it.
A complex UI component will usually contain different aspects A, B and C. Each of these requires hooking into the component lifecycle in various ways.
In a class/interface-based system, you have to sprinkle parts of A/B/C around in each of the lifecycle methods. The only way to abstract and contain this is to make `` `` `` subcomponents, which comes at a significant cost.
Hooks instead allow you to group the bindings to the component lifecycle by aspect instead. You end up making a `useA(…)` `useB(…)` and `useC(…)`, which can not only run directly inline, but can also pass values directly from one to the other, setting up a complex, unconditional reactive data flow in a handful lines of code.
In my experience when hooks go wrong it's for a few reasons:
- people don't understand how they should useMemo for derived state, and instead emulate the old way with useEffect/setState
- react doesn't have an official hook for stateful derived props (i.e. useMemo which has access to the previous value), which leads to a hundred adhoc solutions in every code base
- people order their components the wrong way, nesting a source of truth inside a component that needs to derive from it
- sometimes, the side-effect free rendering model is a poor fit (e.g. mouse gestures, timers) because there is no guarantee every event is followed by a render... it's much easier to just use idempotent state changes on mutable refs here and tell the react core team to stuff it.
By the way, OO pretty much always implies retained mode UI. What React does it bring the benefits of immediate mode UI to a mostly retained world, and this is where FP excels, because you can use optics/lenses/cursors and all that meta-data-manipulation goodness to deal with mutations.
Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?
#106Lots of template languages of the week though. As if software engineering didn't have recorded history.
Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?
#107IMO a JavaScript revolution is quietly brewing. Today’s frameworks have gotten amazingly complicated and EcmaScript spec is gaining new capabilities at a rapid clip, so some of critical features for modern web dev is built in. This project is a great example of what’s coming https://www.arrow-js.com . I think the right move will become avoiding these large and complicated frameworks unless they’re truly called for.
That, while well intentioned, is probably wishful thinking. Large frameworks do not exist to provide technology capabilities or features. They exist to supplement skill deficits in people, primarily around architecture and composition, and any such features are built upon the stylistic premise they provide.
> They exist to supplement skill deficits in people
This take really does not take into account the huge value added of 1) not having to roll your own SPA code and 2) the availability of a large workforce that is all familiar with a common design paradigm.
Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?
#108JS developers: fairly progressive
HN: fairly conservative
JS developers: hey here's an update to a library that's been around for 8 years HN: Why are there new JS frameworks every day???
Also HN: Why aren't people posting about JavaScript here?
Edit: I'd fix the formatting but it's not worth it, HN can't bother to interpret a line break, I can't be bothered to accomodate.
Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?
#109Earlier quoted context omitted.
I’m starting to feel the same way. React’s big selling point when it came out was that it was “easy to reason about”, and that was true at the time. With hooks, server components, and 10,000 different strategies for managing state and side effects, I can’t say React is easy to reason about anymore. We can do things now that were impossible back then, but now we need to do even more than that, and it feels like it’s t…
Hooks are particularly bad to reason about. I can't figure out why hooks seems to be the official Way, it just leads to a bunch of spaghetti functions. The old object-oriented approach might feel old and creaky, but OOP was invented for user interface. Functional programming, not so much.
Functional programming is excellent for UI in a FP context. It’s only awkward with eg React because it has to swim in a sea of imperative APIs—the underlying language, render target, and the world of libraries people expect to integrate with it.
Even eliminating/substituting one of those (underlying language) can go a long way towards making FP UI a nicer experience. For example, Reagent[1] in ClojureScript has a state management approach that’s conceptually similar to hooks, but it uses the language’s own reference type semantics in a way that makes it much less awkward. It’s still a challenge to integrate (JS) libraries with side effects, but the community does a pretty good job of wrapping the more popular ones in idiomatic functional APIs.
The concept that ui = function(state) is incredibly powerful if you can stay within the concept. It can have some performance downsides, but even those can benefit from a language/foundation designed for it (eg with Clojure[Script]’s persistent data structures).
Re: Ask HN: Anyone else notice that HN isn’t full of JavaScript frameworks lately?
#110IMO a JavaScript revolution is quietly brewing. Today’s frameworks have gotten amazingly complicated and EcmaScript spec is gaining new capabilities at a rapid clip, so some of critical features for modern web dev is built in. This project is a great example of what’s coming https://www.arrow-js.com . I think the right move will become avoiding these large and complicated frameworks unless they’re truly called for.
Arrow.js looks very interesting.
Definitely going to try it out.