Offler

That's basically every major framework apart from React and it includes some major React libraries.

They weren't used in virtually every single frontend framework though while Signals are

Nah I use Legend-State with Context to provide component stores and it's much nicer than the foot gun riddled useEffect standard React. Fine grained reactivity is fantastic.

React isn't in the list because the creator had a bad experience with backbone.js in 2013 and dislikes Signals. The team have kept true to his preferences without considering modern Signal approaches, concepts like components, dependency injection and TypeScript, npm packages which provide better encapsulation, discoverability and modularity than the state of the art in 2013.

I work on FX trading applications with hundreds of thousands of lines of code. Full fat desktop application replacements. Good luck not using a framework. 20-30 developers with multiple clients with their own devs.

Look at legend-state, it's most definitely not Redux (in a good way IMO).

Signals are used in every framework except React. Observables weren't. That's a huge difference.

Indeed at a certain scale the "easy" approach ends up becoming a mess. A simple counter isn't complex enough but this is a great idea and would be a positive for the language.

Every framework is moving to signals, apart from React and I'd say if this became a standard even they will. This is like Promise. It's a sensible shared concept.

I much prefer the explicit get/set methods. MobX I think used the magic approach as did svelte and I believe svelte have realized it's a mistake. It makes it harder to reason about the code, better to be explicit.

Signals are fine grained reactivity. React is coarse grained reactivity. Legend-state adds signals to React and I'd recommend it over Redux/zustand which we used to use.

I'd rather have the Irish electoral system then the American one any day.

Another vote for LazyVim, it's been great.

Linux is great on such hardware. I've a 10 year old XPS 13 running Pop_OS and it's perfectly usable.

A React project wouldn't have the same issues.

There are many countries in the world who would love to have an economy as strong/modern and prosperous as Japan.

Angular 2 also requires that level of tooling (both allow you to use ES5 and don't require tooling but most devs won't use them like that).

It sounds like the sort of mistake newbie React developers make, you quickly learn to decompose your render into smaller components.

It sounds to me like you are doing React development incorrectly. You should aim to break down your mockups into small components, preferably stateless components (introduced in React 0.14) and only have the higher level components act as wrappers that pass down data into the small stateless component leafs (which should be the majority of your UI).

Mithril appears harder to read than equivalent JSX.

const links = ctrl.pages().map(page => <a href={page.url}>{page.title}</a>);

return <div> {links} <button onClick={ctrl.rotate}> Rotate Links </button> </div>;

Compared to

		m("div", [
			ctrl.pages().map(function(page) {
				return m("a", {href: page.url}, page.title);
			}),
			m("button", {onclick: ctrl.rotate}, "Rotate links")
		]);

edit: Mind you both look awful due to HNs poor formatting ability. Honestly how did this website become so popular with tech people?

Really? You have React, Angular and Ember. Three libraries or frameworks for building web applications. If you aren't building a web application you might not need any of them.

Just use React as the other two are copying/converging toward React.

All the other web app UI frameworks? Noise, they won't amount to much and add very little. The last release worth paying attention to was React 2 years ago. Hardly a breakneck pace.

Respect disease let people die when they contract them.

npm is getting its house in order when it comes to browser package management. I wouldn't bet too heavily on something else.

Well the question is why bother with those other tools if one tool (Webpack) can do everything you need?

It reminds you of React because he's talking about React :)

Fairly standard for such a low rent, she's lucky she didn't have mice skittering over her feet in her kitchen...

Basically JavaScript is a tool that I can leverage in more places then CS and CS offers me very little advantage over ES6.

I think the reason React is so popular is due to the developer experience. It's a simpler mental model where you no longer have to worry about your previous state and how to transition the view to the correct current state based on it.

I'm not sure why it's terrible practice, the only reason I can think of is a performance one. As I said earlier in the thread though that's only a problem if you create infinite lists and never clean up after yourself.

The correct way to design such components would be to only create DOM for elements in view. Which is why this test is flawed.

You mean a grid? A component one is often asked to add to web applications for businesses. I've added 4 in the last week alone to apps I've worked on. It's bread and butter stuff.