Hacker News new | past | comments | ask | show | jobs | submit | lominming's comments login

I did an evaluation on the various frameworks 2 years ago, and it largely came down to only these 2 choices:

- React (if you want the largest support, packages, community, but sacrifice on performance) - SolidJS [1] (best performance, composability, low-level primitives, but sacrifice on packages/community)

Every other choice like Angular, Vue, Svelte are just somewhere in between these 2 spectrums which I felt was not worth it. Either choose the one with the largest ecosystem or one which has the best primitives & performance.

- React (vdom, slow) (largest ecosystem) - Vue (vdom, faster than react) (large community) - Svelte (fine-grain, faster) (best dx pre-v5) (composability is still not as flexible in v5 compared to SolidJS) (small ecosystem) - SolidJS (fine-grain, fastest, most consistent) (dx similar to react) (small ecosystem)

[1] https://www.solidjs.com/


People who love Angular really love it, so I trust that there's a legitimate place for it. I think one of the main things people love is that the convention and tooling eliminates a ton of the noise and redundancy that the other tools tend to lead to as teams slap applications together without sufficient guard rails.

Essentially a lot of the tools we use are only meant to be view layers, and we constantly cobble together supporting layers (models and controllers for example) ad-hoc. Angular handles that off the shelf. I suspect a lot of people are put off by this because it feels imposing and they might not realize they're implementing the same stuff manually, and likely doing it worse.

I used to think it's plain old garbage but realized that's ridiculous. There are reasons people prefer it in some scenarios.

SolidJS is my favourite by a long shot, but I find myself using React because I know so many people I write for and work with are more comfortable with it. I'd be glad to use it more often if it made sense.


I'm currently learning Angular and it's an absolute dumpster fire of a framework in the sense that it offers no clear philosophy. It's just a jumbled mess of concepts and syntax.

I think where it shines though is that it's completely batteries included, which I can see being useful for large enterprises where it's near impossible to change things.

Having recently worked on a very legacy React app, it became apparent to me the value of frameworks like Angular. If you can maintain it and upgrade it gradually, React is arguably the better choice. But if you're leaving it to stagnate, Angular is a far better proposition.


I think we're on the same page here. I've also found that a non-trivial number of teams actively maintaining React apps are still totally capable of rendering them into a state of dysfunction and paralysis in the same way that stagnating apps can devolve.

They think they don't need batteries included because it's 'bloat' or the opinionated patterns are inferior, but after a couple years they've got a couple dozen seriously bad patterns and a 400kb application that could easily be pared down to 100 or so.

This isn't so much a virtue of Angular or React specifically, but a reality of the deficiencies in our industry when it comes to the human side of the equation. These people would be better off following Angular's general conventions whether they realize it or not.


So much of Angular versus React is "No one got fired for picking Google tech" versus "No one got fired for picking Meta tech" with some of the obvious problems of their "parent" organizations' approaches visible in the maintenance efforts.


In all honesty, I think neither one of those are the main measurement you should be using from a business point of view. React has a huge ecosystem, but many packages are out of date or poorly maintained. This means you either still roll your own or you take on the pain of working with the bugs or compat mismatches you inevitably get (looking at you, React 18). On the other end, I would say for the majority of modern web apps, performance doesn't matter too much, so long as it isn't absolutely abysmal. So what are the right metrics, in my subjective opinion? Readability, and by extension refactorability, and ease of iteration. In other words, developer experience, because that will literally save your business actual time and money.


Never met a corporate SPA that didn't have abysmal performance.

That said, framework choice isn't the problem, frontend devs having no clue how to design and use API's is.


I think bringing in component libraries that include the kitchen sink, the farmhouse and the farm... as well as the neighbors farm are a big issue too.


Corporations fill their ranks with junior developers, more breaking news at 11.

I remember plenty of multi page applications from big corp that ran like a dead dog too, back in the day. Or ASP sites that wrapped the ENTIRE page in a form, with all of the frustrating complications that entailed.


Hated ASP.Net WebForms over dialup for sure... massive view state, it was a mess.


ASP.NET WebForms is a mess even on localhost.


I think that's what lead into a lot of "Alt.Net" development and tooling... when the blessed ASP.Net MVC came out a lot of the alternatives just died quickly though.

I switched to straight HTML, JS + .ASHX handlers for a lot of things leading up to that point.


If you really think the performance of the framework is something you need to optimize but want to keep the react ecosystem, you could also use react (or preact) with preact signals which I think should make react perform more like newer frameworks like solidjs in terms of not rerendering entire trees of components unnecessarily.

I'm not sure this is really the first thing that needs to be optimized for most people though, despite there being a lot of frameworks whose sole reason for existence seems to be fixing this aspect of react's performance.


Any slow app would be just as slow if the team had built it using different tech, because it's the design of the software that makes it slow, not the framework.

There is no framework that has a "pit of success" that makes it inherently easy to build a fast app, so any team that uses a framework poorly is just as likely to use a different framework poorly. If they switch and things improve it's probably because the new framework happens to fit their mental model rather than any inherent function of the framework itself.

A good team that designs their code to make the most of a framework could write a good, fast app using any particular tech.


I've spent a lot of time thinking about what the "pit of success" looks like for a framework to make it inherently easy to build a well performing app ("fast" is a different subjective matter), even in some of the worst cases of a naive developer doing naive things. (I think I got really close to a "pit of success" with Butterfloat if you enjoy working with RxJS. Its defaults are tuned for smooth performance even if you are doing too much work in a component.)

There's no framework that has a "pit of success" on every subjective performance quality metric, but I do think some frameworks more than others have larger "pits of failure" that make it too easy to get bad performance even doing what you think is supposed to be the right thing. Because I've vocally picked on it many times at this point, an easy example to mind is Angular's Zone.js is a big opaque library that can accidentally drop you into a "pit of failure" without you realizing how you got there. I'm glad a couple years after I raised some warning flags about Zone.js that Angular is finally addressing that elephant in the room and removing Zone.js as the suggested option and are close to removing it as the default option.

(I'm less glad that the reason that finally pushed them to do that is adding Signals. It seems wild to me to have proper Observables and also Signals and that just seems like another potential pit full of accidentally doing the wrong thing because it looks easy but the interactions between imperative code, Signals, and Observables is going to necessarily be complex and fraught with scheduling problems. I can't say that I'm surprised that Angular development is again moving one step forward while also two steps back at the same time.)

I know others with similar rants about React Hooks and how easy it is to miss needed dependencies in the dependency list of a Hook and too easily fall into a pit of failure.

It is useful to evaluate frameworks with some small eye to "how hard does this make it to do performance right if we follow its 'best practices', even in the case of simple mistakes?"


This seems to completely throw out DX. Svelte is an enormous productivity increase from SolidJS, trading microseconds of performance for that (Svelte is still very fast) does not seem worth it at all. That's like saying your two choices are Python and C, Rust not being worth it.


> Svelte is an enormous productivity increase from SolidJS

Could you expand on this? SolidJS DX seems pretty great.


> That's like saying your two choices are Python and C, Rust not being worth it.

Not a great example since that’s actually why all the other propositioned system language replacements never took off in the way rust did. Rust is (or can be, but importantly, when used idiomatically and not just “in some form”) as fast as C.

There were lots of other languages that tried to replace C with better DX but failed because they weren’t Pareto optimal. So I kind of get GP’s point: DX alone won’t cut it.


I wouldn’t call the ecosystem of svelte small. Since it adheres to HTML and javascript so closely, the effective ecosystem is pretty much the things supporting plain javascript and plain HTML, which is a lot of things.

(Though two years ago I think sveltekit — the app framework for svelte, without which svelte is incomplete for many cases — may not have been quite ready for production, so it was probably fair at the time.)


The value proposition of Vue to me is, “We looked hard at all tools out there, especially react, and iterated on it to make it nicer to use.”


Well TBH svelte works just fine with vanilla javascript libraries, so you could argue that the ecosystem is not as small as you think. Almost every other library/framework in this space requires a wrapper around the vanilla javascript library.


You can make the same argument then for SolidJS. Almost every vanilla JS library works fine with it without a need for wrappers.


> react - sacrifice on performance

Define performance. Comparing render cycles is pointless. A better measure would be Google's web vitals, if you care about user experience.


One of my criteria these days is portability… web components are a frustrating API to use directly but one of the reasons I develop with Svelte is that it can produce web components that, should we pivot frameworks some day in the future, will be able to live inside another framework.

React absolutely fails in that regard. I try not to be a conspiracy theorist but I think React actively avoids web component compatibility as a form of vendor lock in.


React 19 has full support for web components and it scores perfectly on the “does your framework play nicely with web components” test suite whose name I don’t recall.


React 19 release was just postponed to God knows when, the post says.


> best dx pre-v5

Did something bad happen to dx in svelte in v5?


They are moving to "Runes"[0] which IMHO feel clunky compared to previous reactive declarations. There's some perf reasons, but Svelte performance was not an issue for me to begin with.

[0] https://svelte.dev/blog/runes


Bad is subjective too.

There's new syntax for props, reactivity and state that's slightly more complicated for hello world applications but you really notice the differences for even mildly complicated components.

export let foo;

vs

const {foo} = $props()

looks far worse until your doing something like extending an input and you no longer have to deal with $$RestProps ugliness

type Props = {foo: number} & HTMLInputAttributes

const {foo, ...rest} : Props = $props()

<input {...rest} />


v5 is not even released yet, so I would ignore that statement.


does this change at all with react compiler? honest question i dont know


Much needed feature for typography! The biggest pain is when I need to visually vertically center a text with an icon. If you have an [ICON] followed by upper case character (e.g. Hello), the (H) will always visually look too high to be vertically centered with the [ICON] because the actual height of the text that is calculated always account for hanging characters like "g, y", etc.


It's such a pain, there was a fantastic hn submission not long ago about the struggles with vertical centering.

https://news.ycombinator.com/item?id=40069599


Great to see more people thinking about this space. Totally agree on the sentiment that we should be able to visualize/describe and build business logic in a very simple manner. The way I've been thinking about this is something like Legos where we can compose any logic, app, workflow we want visually and that anyone can build and share these blocks. This is almost similar to NPM packages, but for non-developers.

My attempt on this is https://openexus.com where the goal is really to create some form of universal plug-and-play building blocks. Your approach is almost very low-level with direct translation to code. My attempt is slightly higher-level (but developers can create as low level as they want). More importantly, the visual diagram build on openexus is a reactive graph (almost like spreadsheet), not a sequential directional flow graph (like node-red, or yahoo pipes).

Would love to chat if you are up for it. m at lominming dot com.


Open Nexus looks great! The UI design is super clean, and the open-ness of your nodes give it true Bret-Victor-ish vibes!

I started closer to this at first (but still lower-level) and slowly got "down to earth", taking a https://www.dreamsongs.com/WorseIsBetter.html approach.


This looks super nice :) love it


Obviously there are huge similarities to solid-js and other signals based framework with creating a signal, creating computed/derived, creating effects, etc. Would it be fair to say that Svelte 5 is going to more "runtime reactivity" rather than compiled time?


I'm also someone who are driven and get excited about working on something fundamental. My recent endeavor is the result of years to figuring out what can be the fundamentals for the web -- Building Blocks for the Internet.

It would be helpful to understand why you feel like version control (git, not github), a programming language (javascript), a browser, a database are all fundamentals? They are not the first in their respective categories, just that they all became popular? I feel like your examples also lean heavily towards developer only tools?


Yahoo Pipes (or NodeRed) are what I consider “data flow pipelines” editors. These tools have very distinct characteristics: (A) usually a single piece of data or message that (B) flows through a system in one direction with (C) distinct start and end points.

Couple of core differences with what we are building:

(1) Instead of directional data flow, we have reactive data flow. For example, in the simple utility color example, [RGB Sliders] <> [Conversion] <> [HEX Color Wheel] have data flowing bi-directionally where any modules can trigger a change. Users still have the option to decide how data flows, so data flow pipelines are just a subset of what our system can do.

(2) Beyond just data or automation, we focus heavily on UI modules, allowing users to easily express interactive creations.


This is not obvious. I would show an icon, maybe a question mark, that explains what it is. Or embed the editor in a regular home page and let users go full screen or open a new window.


Thank you for the feedback. Did you by any chance manage to connect the first 2 cells? Once you do that, it will reveal a lot more content, with a more "regular" home page that you can scroll down.


Developers can create modules in Javascript very similar to writing web components or React components. The only addition is to write a declaration of the connectors (e.g. value, data, location, etc.) and use provided functions to subscribe to cell value changes.

Developers can import NPM packages, load external javascript files, use JSX, write CSS, use Typescript, etc. We will provide all the necessary tooling online so that building a module is as simple as using an online IDE like codepen. No need for downloads, building, compilation, etc.

Non-developers can also create custom modules that consist of other nested modules grouped together. We also aim to have a lightweight way for citizen developers to write modules using spreadsheet-like syntax.


The logic is actually quite simple. Once 2 cells are connected via a line, their values are kept in-sync. If one cell changes the value, the other cell will be informed of the change, and the module will react accordingly, very much like a reactive spreadsheet.

During the initial connection, we have to “pick a winner” and determine which of the 2 cells’ values to use. The logic is that the empty cell will be overridden. If both cells have values, the direction of how you connect them determines the winner. Dragging A to B will have B’s value overridden by A’s value.

However, the developer of the module, or the creator have the ability to specify the direction flow when necessary. For example, in the Github example, the Github module populates the (issues) cell via fetch call and is expected to be a read-only cell. This means that any connection to the cell will become a directional data flow out.

The simple big picture is that we are drawing lines to tell the system how we want data to flow among the different modules, very much like how we pass variables around in code.


What are your favorite use cases?


We actually did a mini internal hackathon among ourselves to see what we can do in 1 hour. We created a codepen (multiple code editors hooked up with iframes), spotify + lyrics + translation mini app, and a mini-dashboard.

Besides the common use-cases of creating apps or dashboards, we are excited about: AI apps and workflows, interactive education materials, a playground for kids to start thinking about logic, and hardware interface controls.


Clickable link: https://openexus.com


Tried "Hello" thinking that (1) it will be the easiest, and (2) probably I will get some variation of a greeting back (hi, hey, ...). Instead, I got:

Hello -> Lac


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: