5 ms·
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 supp
by valenterry 3y ago
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.
- DesertVarnish 3y ago> 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.
- valenterry 3y ago> 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.
- k__ 3y agoIf Reason/ReScript didn't fumble the bag, with their fork/rename, things could have been better.
- commonlisp94 3y agoThe operating system you are using is written in C.
- valenterry 3y agoLet's assume so. What's important though: If it had to be completely written again from scratch today, would it be done in C?
- commonlisp94 3y agoI 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.
- enono 3y agono, it would obviously be written in ocaml