Concerns Regarding Custom Keywords #506
Replies: 2 comments 1 reply
|
Thank you for raising your concerns – even if it looks LLM generated. However, I disagree with the first two points – really the only thing that is a relative struggle is the tooling. It's a misconception that adding additional syntax is a barrier to entry. I've been fortunate to be apart of many very special projects and languages and really, syntax is like an API. A good example is Svelte 5 and "runes", which is re-using JavaScript and re-purposing it, which had the exact same knee-jerk reaction. In reality it didn't cause any issues at all. Another good example is Flow, which introduces plenty of new keywords and a syntax – literally no-one cares. Ripple isn't JavaScript/TypeScript. Ripple is a new language that is a superset of TypeScript. Just like how TypeScript/Flow is not JavaScript. |
|
Thanks for the reply and indeed I used AI to refine the grammar but these are some of the things that I could think of I am not sure if Ai will be able to come up with exactly these maybe it can I have not tried. Anyway I see its your project and I see your point of view, I would say good luck with it and I hope people use it |
Uh oh!
There was an error while loading. Please reload this page.
Hello everyone,
I must first express my appreciation for the significant effort and time you have invested into this really interesting project and for sharing it with the world.
I would like to raise a specific concern regarding the use of special keywords within the framework. My primary concern centers on developer ergonomics. While the concept might offer certain benefits, such as a more declarative syntax, I believe the potential costs may ultimately outweigh these gains.
The Challenge of Non-Standard Syntax
Introducing custom keywords presents several hurdles:
Increased Barrier to Entry: A new non-standard syntax must be learned solely to use the framework, this creates friction and significantly increases the learning curve for developers.
Deviation from Core Language: The use of new keywords pushes the framework outside the familiar territory of JavaScript/TypeScript, for experienced developers this can make the code feel unfamiliar or "alien."
Tooling Requirements: Non-standard keywords can sometimes lead to initial complications with editor tooling, syntax highlighting, and linting, although these issues can often be resolved with dedicated plugins, it introduces an extra setup requirement and more burden on developer to create dedicated tooling.
I strongly suggest exploring alternative options that remain fully within the native JS/TS syntax, these could include utilizing standard language features like plain functions, classes, or decorators, even if it necessitates sacrificing some of the syntactic sugar the new keyword currently provides.
I am particularly interested in understanding: What are the core benefits that the new keyword is solving that cannot be achieved with standard language features like functions or classes?
I look forward to hearing your thoughts on this matter.
Cheers
All reactions