Comment by valenterry | Hacker News Reader

Comment by valenterry | Hacker News Reader

It might be hard to swallow but: there can never be real progress on the frontend without having a programming language that is powerful enough to properly support the developer.

Programming languages are always laughed upon and most of the time I hear frontend developers telling me that frameworks are what's important, not the language. But I think typescript shows how impactful a better programming language can be.

Unfortunately, even typescript - despite of how great of a language it is - isn't capable yet to support even basic cases.

For instance, using the features of the language to describe a nested structure of components, each of which has different dependencies that are a subset of its parents dependencies. Such a thing cannot be expressed with typescript, so frameworks/libraries all come up with their own way of doing that and in consequence giving up on typesafety and hence making it way harder to understand things and way easier to make subtle mistakes.

I hope we will see major improvements on that front eventually. However, powerful programming languages are hard to learn and take time to master - something that is often doomed to not survive in the frontend world where things are fast-paced.

> For instance, using the features of the language to describe a nested structure of components, each of which has different dependencies that are a subset of its parents dependencies

I may be misunderstanding you, but this seems tractable with React.memo. Merely encode the dependency or lack thereof in the propsAreEqual predicate.

> I may be misunderstanding you

I think so, but I probably haven't explained it well. Let's assume the following structure:

<Outer> <EditListElements> <UIElem>1</UIElem> <UIElem>2</UIElem> </EditListElements> </Outer>

Let's say EditListElements is a generic 3rd party component.

How does the definition of the props/dependencies of the elements look like?

I would like it so that when I define `Outer`, I define some props that outer needs (e.g. let's say it needs an A and a B) and then the actual props to initialize it become A, B and <Props of EditListElements>. But EditListElements is a 3rd party component, which itself derives its properties based on the children it uses. And so on.

One of the reasons to do it like this is that if I have a big, nested graph of components and I add a required dependency value to some component down the graph then all the intermediate components should have the props "automatically" updated and I will have to pass it to one of those components (potentially the very toplevel component) to satisfy the compiler. Then, it will be passed down automatically to where it is needed.

The way this is currently "solved" in react most of the time is to move those required values to some global store or so which is then accessed or at least accessible by all components. It quickly leads to a big ball of mud and it is tricky to see what a component needs (and what it doesn't need) by just looking at the component in the graph.

Hope that makes it more clear.

If Reason/ReScript didn't fumble the bag, with their fork/rename, things could have been better.

The operating system you are using is written in C.

Let's assume so. What's important though: If it had to be completely written again from scratch today, would it be done in C?

no, it would obviously be written in ocaml

I don't know, but this point is already refuted:

> there can never be real progress ...

> without having a programming language that is powerful enough

Historically there have been plenty of interesting powerful languages on the periphery, but most of the useful stuff is not written with them.

Reply on news.ycombinator.com