This has to be an error in the documentation:
Should be:
Civet: A Superset of TypeScript
91–100 of 237 posts
Re: Civet: A Superset of TypeScript
#92Its not about how concise or short your code looks, its how about much time the new intern coming tomorrow needs to understand those 1000 line files. I find the syntax very hard to remember and confusing
Pretty much what I feel about Rust
Re: Civet: A Superset of TypeScript
#93Typescript with a dash of F#
Re: Civet: A Superset of TypeScript
#94I think the most exciting aspect here is this might actually push JavaScript to add some missing features that can make a lot of difference, the pipeline operator for example can really improve the design of JavaScript code and has been proven already in several languages, C#, swift, kotlin to name a few I know
Re: Civet: A Superset of TypeScript
#95Lol. A superset of a superset. I wonder how far we can go with this
Re: Civet: A Superset of TypeScript
#96One nice aspect of Python compared to TS/JS is the presence of list, set, map, and generator comprehensions. How far in that direction is civet likely to go? I see that arrays can be built from a for...of expression.
Re: Civet: A Superset of TypeScript
#97This has to be an error in the documentation: Should be:
Depends on the framework. You can use class= in Preact.
Re: Civet: A Superset of TypeScript
#98Really redminds me of coffeescript, lots of special syntax that doesn't really help readability? I have a hard time understanding the motivation of this project other than syntactic sugar-maxxing JS/TS.
Languages like this don't make sense anymore. You can just pick a mature, feature-rich language you like (Rust, Kotlin, Python, probably many more) and transpile to JS.
All those mature feature-rich languages started as "languages like this make no sense"
Re: Civet: A Superset of TypeScript
#99We need a language that compiles to js with strong typing not another ts!
Re: Civet: A Superset of TypeScript
#100This is terrible. I was so happy CoffeeScript died a quiet death. Now someone thinks of this.
Keep it simple. Code should be easy to read. Also, ain't nobody got time to learn yet another obscure abstraction that will add only a marginal productivity gain at best (and probably sacrifice readability + add another build step + add another learning curve to new devs in the process).