Having just count=0 is stupid and you will learn it the same way as Svelte did. Comparing it like that when they explain all the issues in Svelte 5 is even more dishonest. Any variable can be state and/or be reactive and they arent marked? GL with that. You need to manually call update after fetching data, why?
I obviously disagree. This is not only compact, but also standards- based. It's an ES6 variable. I don't expect Nue to change here, like ever. Svelte internals are quite different.
Signals w/ getter/setter are incredibly nice for this.
I love your attitude. This library is not for me right now but I appreciate the pioneering. React also got a lot of hate in the beginning ("re-render on every change is insane"), people forget. Good luck!
I don't know if you've ever had spaghetti, because the ingredients _are_ meant to be mixed together. Maybe you were looking for another analogy?
Speaking of which, how do you interface with global variables in that case? Say I want to instantiate a global variable when the component is created, how do I do that?
Functional components on their own are not distinguishable from a good old Javascript function. I guess the presence of JSX and/or hooks give it away. I'd say it's half true that glancing at a random .js file it might not be immediately obvious if it's React or a function, but with some digging you should be able to find out by following the imports.
It's absolutely not an ES6 variable. count=0 may be valid ES6 but in a NueJS setup it's not parsed by the JS interpreter: it's preprocessed. What actually gets served and parsed by the browser is an entirely different piece of code & that makes it inherently changeable in future releases.
Also, while count=0 is technically valid ES6, most of the larger examples on the page are not; this is a DSL like any other, with all the drawbacks that brings. Masquerading as ES6 syntax won't fix that.
> Nue transpiler takes the code between the script tags and creates a true ES6 class instance from it.
the second phrase negates the first. It will be a ES6 variable, it isn't.
You'll see that the compiled code is pure JS and parsed by the JS interpreter on the browser, unlike the parent commenter states.
The argument being made here is that the pre-compiled code is not ES6. Of course the compiled code is - I can't see how that's relevant, that's the same for every JS FE DSL.
This is flatly untrue - multiple commenters have outlined why this is untrue above.
> Also not sure what in this discussion is relevant.
It's relevant because the original comment is advocating for Nue.js on the basis that the DSL is standards-based, which is untrue. Designing something that looks like a standard without actually adhering to that standard does not equate to being standards based, nor does it benefit from any of the advantages of a standards-based approach.
---
fwiw, while my use of the word "untrue" above seems strong, I want to state clearly that I don't believe you're deliberately trying to mislead anyone here. Your intent seems benign, but I would just suggest learning a little bit more about the approachs of various frameworks, templating systems & DSLs over the years.
On Nue.js case tho the count=0 is misleading as it is a class variable that can get a setter and getter but in Nue.js code it is a normal variable that can't have a getter/setter. So the code doesn't really do what it is supposedly doing.
If you want getters and setters, you'll use standard ES6
a normal "count = 0" used in the examples.
a Nue "count = 0;" isn't the same as a ES6 "count = 0;". It needs compilation. I think trying to convince developers of the opposite won't help much grow a community.
It is implied, it will be supplied by the framework after compiling the code. So no, it is not a ES6 class instance variable.