Hacker News new | past | comments | ask | show | jobs | submit login
Nue.js: Rethinking Reactivity (nuejs.org)
76 points by tipiirai on Oct 2, 2023 | hide | past | favorite | 145 comments



Summarizing:

- It re-renders on click

- It mutates pop/push/... to observe arrays

- Otherwise, you have to manually call `update()`

IMO, don't touch this. All of this has been tried before. It also looks like lists are unkeyed. If you receive another list from the server, you have to do the diffing yourself.

It's disappointing that a framework proclaiming to solve all issues of frontend dev, while evidently understanding none of them, will go uncriticised by HN.


Will go uncriticized? The comments are full of these kinds of posts dismissing it off hand based mostly on self-declared "understanding".

The ceremony and huge verbose architecture astronaut frameworks has been tried before. But the people on this enterprisey very professional corporate busywork hype train are probably too inexperienced to rember the SOAPs and J2EEs and Enterprise Java Beans and dependency injection frameworks and Boosts to understand what drag they are to development and software quality.

It'll blow over again in a few years but it's quite sad that the same mistakes have to be repeated.


I was referring to the last time this framework was posted. I'm glad to see that it's being taken apart much more thoroughly this time around.

If you consider keyed lists and reactivity mechanisms to be "enterprisey very professional corporate busywork", then I don't know what to say to you.


Thank you Pekka! (Making a super wild guess that you are from Finland and your name is Pekka :)


I am from Finland but Pekka is the beginning of my surname. The nick is just some old system-assigned login name that stuck (your's seems the same).

Thank you for Nue and bringing much needed simplicity and elegance to frontend dev! I'll be sure to at least try out Nue for the next frontend project that could benefit from a framework.


This comment gave me PTSD. Been there, lived that.


This does just seem like a worse version of knockout.

In knockout (with typescript annotations), the equivalent would be:

    let count = Knockout.Observable<number>(0);
And it's then much clearer when you want to access the value of the observable with count() or update it with count(1234) or count(x => x+1 ).

( I may have hallucinated the ability to pass a function to the observable ).


At least there were observables. Here, you're on your own if there are any external updates (timers, sse, etc...).


Yes. If there are timers, SSE, or fetch responses you must explicitly call the update() method.


Lifecyle of every JS framework seems to be.. 1. Look how little boilerplate we have! 2. Oops actually we need more boilerplate.


React has gone down in the amount of boilerplate.


Every framework? Which comes to your mind first?


Keys are unnecessary in Nue, just like many, many other framework abstractions. If you receive another list from the server, Nue takes care of it automatically. No need for diffing.


https://github.com/nuejs/nuejs/blob/a5c844494852cdbe3282fdc5...

Am I correctly reading that you just throw away and re-render the entire DOM?


"Keys are unnecessary" in what way? The only reason they are necessary in React etc. is to keep DOM mutations to a minimum. Are keys unnecessary because you always re-render the whole list, making for very inefficient updates?


True. When the array changed, the view is indeed re-rendered. Nue is probably not a good pick ATM for UI's with hundreds of rows and when list re-rendering performance is critical. I'll add the key- support if this becomes a frequent issue.


It's not just about performance, although that is of course a big part. What if I have child components with state that I don't want re-rendered? Suddenly I have to track the state in the parent to keep it from disappearing on every array change.

This has big architectural implications, and it worries me a bit that you only see it as relevant for benchmarks.


> if this becomes a frequent issue

This becomes a frequent issue in any app at scale.

If your app is at a small enough scale that it doesn't run into this issue, I would not recommend using a framework: just use vanillajs &/or some modular utility components.

If you're working on a small app & want to do it in a framework because you anticipate scale, use one with key support.


Hardly a frequent issue. I use zero apps in real life with more than 30 items on a single view, let alone 100 or 1000 — that all needs to be completely changed in one operation without re-rendering.

It's a common theme in benchmarking apps though, which will ultimately be the main reason for adding the key support.


> I use zero apps in real life with more than 30 items on a single view, let alone 100 or 1000

I do.

You've now disqualified this entire framework over a single issue, number of items in a list.


This is so demotivating. I wasn't prepared to this large downplaying of Nue.


There's a few elements to understand here:

1) In general, in the open-source community, there's a LOT of JS frameworks and many of them have caused developer frustration. This has lead to people being generally more skeptical of ANY new framework, just because there's so many & its considered a saturated space, so critique will be more strict.

2) With JS taking over as the "everything language", there's also some general backlash against JS itself.

3) On HN, this is even more pronounced for some reason.

However, apart from the above, most of the negative comments seem to just be direct replies to certain claims you've made on HN (keys unnecessary & the ES6 DSL): there aren't as many negative comments on the actual submitted website. Personally I quite like it - I particularly love the narrative history lesson & to-the-point inline examples; you're a great communicator. As for thte library, there's elegance in simplicity, & while the framework may not be practical at the moment for some applications, there's still value in using software that is essential grokkable.


You're trying to upset the applecart by saying your "framework", which has been developed in relative isolation, is better than the other top 4 contenders. Well, you better have some hard proof of that.

Saying that you don't use lists, isn't helping.


Thank you lucideer! Great, kind points. Made me feel better.


I was talking about the applications I personally use frequently, like Slack for example. Unlike the parent said that "this becomes a frequent issue in any app at scale", I just don't see this happening on the UI's I personally use.

Having said that: they key-optimization thing will be implemented. The more frequent issues get a higher priority. Maybe it's this one.


I built an app that listed all 20,000+ of my blade computers on a single long page. They were arranged in a grid that mapped to the way they were racked in the data center, which made it super easy for a technician to get an overview of the status of the entire system. 12 blades per chassis and 1-8 chassis per rack.

The page took about 2-3 seconds to load (mostly downloading the json data to render the page), but once it loaded, it rendered and more importantly, updated very quickly as new data would roll in. If I had to re-render the entire dom every time there was an update, the page would have been unusable.

It feels like you can't see past your personal use case. You're trying to convince HN that your framework is better than the top 4 projects out there and HN is pushing back and saying... umm... no.


Note that Nue will probably work just fine for your use case. The list is not re-rendered when individual items on the list are updated or when new items are added. Currently only re-rendered when the whole list is sorted or replaced with a new one. Based on the feedback here looks like I need to optimize these two mass-operations as well.


I don't want to manage the list on the client side.

I just do a replacement of the data retrieved from the server, and it all magically works because the ID's don't change.


Indeed. It's rare to see real-world scenarios where thousands of items are mass-manipulated on the client side. They exist, but rarely. The lists are typically appended/prepended or individual items are updated.


> Indeed. It's rare to see real-world scenarios where thousands of items are mass-manipulated on the client side. They exist, but rarely.

I'm not sure this is correct. Almost all apps that I write that display live data are built by replacing the whole client-side array with updated server-side array data, and the other commenters seems to work similarly. With your current approach I'd have to write a complete diffing logic to modify the array in-place locally, especially if I don't want child components to be re-mounted.


This comment section on HN has more than 100 items in a single view.


> will go uncriticised by HN.

Says the comment at the top of the thread criticizing the project.


Sad that this is on front page.

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?


> Having just count=0 is stupid and you will learn it the same way as Svelte did.

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.


I think you are insane for this take. It should be very clear from a cursory glance what is reactive and what is not if you want your code to not become spaghetti rapidly.

Signals w/ getter/setter are incredibly nice for this.


Insane is cool. Nue is a heavy promoter of the separation of concerns pattern — which is the most effective way to avoid mixing different kinds spaghetti ingredients together. These small, extra $- characters are minor factors.


> Insane is cool

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!


Thank you for this! People here are so discouraging


>>which is the most effective way to avoid mixing different kinds spaghetti ingredients together

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?


I'm not sure I'm convinced. If I open a random file in a project and see `count=0`, how do I know if it's a global variable used by legacy code, a reactive variable, or something else entirely?


Consider opening a Nue file and knowing that the components are based on ES6 classes. Then it's rather obvious.


This explanation can be used for any library though, consider that you know how the internals work, then it's rather obvious. If you don't know Nue and stumble on this it's just another flavor of unknown black box. Sure, the syntax might be nice for you, just like Awk and Vim are nice for some people, but it doesn't mean other people have a chance of understanding what's going on without looking up the documentation.

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?


I'm sure React users also know whether they are dealing with a functional component or whether they are using hooks for state management.


The core difference is that in that case what's happening is clear from the code, functional components start off with a function declaration whereas class components start off with a class declaration. This isn't true for Nue, you have to have read the docs to understand anything that's going on, otherwise you have no clue. In general though, while I understand it's your project and you have strong emotions towards it, looking through the rest of the comments it doesn't shine a good light on the project if you argue tooth and nail against any and every criticism. Many of the criticisms are perfectly valid, a lot of these things have been tried before and there's reasons why there were abandoned.


Hmmm.... I think that's because to use one of the React hooks you need to import them from React. If you create your own hook it'll eventually use something like "useState" internally, which leads you to "import { useState } from 'react'".

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 an ES6 variable.

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.


It is _absolutely_ an ES6 variable. Nue transpiler takes the code between the script tags and creates a true ES6 class instance from it. The larger examples are no different from the count=0 in here.


> It is _absolutely_ an ES6 variable.

> 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.


Please read the article and the section "Reactivity under the hood": https://nuejs.org/blog/rethinking-reactivity/#reactivity-und...

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 compiled code

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.


The code inside the script tags is ES6, the pre-processor does not "masquerade" it as the parent commenter says. It's taken as is. Also not sure what in this discussion is relevant.


> The code inside the script tags is ES6, the pre-processor does not "masquerade" it as the parent commenter says. It's taken as is.

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.


for my surprise, count=0 is indeed ES6. I thought const, let or var were mandatory but it seems to not be the case.

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.


Sorry, which code?

If you want getters and setters, you'll use standard ES6


> Sorry, which code?

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.


When a Nue component is compiled it creates a native ES6 class directly from the contents of the inner script tag. The ES6 code is not traversed at all, let alone altered. That is: count = 0 is a native ES6 class instance variable.


where is the class instance in count = 0?

It is implied, it will be supplied by the framework after compiling the code. So no, it is not a ES6 class instance variable.


The update() method is there because Nue does not make a difference between reactive variables and other variables and it's impossible to know if a state changed when there is no specific DOM event or array manipulation call.


I think its kinda great its on the front page, I only work in backend so this looks quite appealing like ALL tech demos do. Love to see it pulled apart in comments with explanations I understand haha


Agreed


This is the cycle of JavaScript frameworks. You create something deceivingly simple that tramples upon idiomatic usage but looks great for a todo app. Beginners realize the hard way that this doesn't scale because deep reactivity shouldn't be a default, they no longer know what a vanilla JS variable should behave like, and code is un-readable.

Let the bundler minify your JavaScript. Less characters !== simple.


I prefer thinking scalability more literally (like Chris Coyier): an approach that works for a small site and remain the same approach for a large site. Nue's approach is MVC, which is a project not released yet. Check: https://nuejs.org/tools/

Less characters in source code is obviously a better metric for simplicity than what there are on the minified code (Nue wins on both btw)


I appreciate your effort on creating a full ecosystem from the ground up. I'm doing the same, the more the better. It brings me an old time hackers vibe. We don't need 10s of VC-backed frameworks trying to lockdown users to cash them. I hope you plan to continue doing this work by yourself in place of launching a PaaS/SaaS on top of it.


Thank you, Alan!


The best kind of JS framework is no framework, especially for small teams.

Especially now that self encapsulating modules are a thing and server side templating can fill in html's lack of import tags. Reusable components sound great in principle, but trying to replace one that's used in 30 different locations with small nuances in each spot leads to complete debugging hell, just like typical overzealous polymorphism.

Allegedly we're even getting optional typing soon, so TS will become obsolete as well.


> Allegedly we're even getting optional typing soon, so TS will become obsolete as well.

I'll be surprised if tc39 allows it.


> encapsulating modules

I love vanilla JS. Are you referring to web components?


I was referring to just general JS modules that can import other modules but don't see the global scope, which was arguably the main problem with vanilla JS. But web components are awesome as well, albeit not as critical.


Speaking of web component I just created this framework a month ago, https://realm.codes


Author here. After releasing Nue JS here just two weeks ago[1], the most common questions were: “How does reactivity work”? and “How is this different from Svelte”? This article attempts to answer those.

[1]: https://news.ycombinator.com/item?id=37507419


The reasons for not using/supporting typescript[0] seem irrelevant.

1. Is wholly immaterial.

2. Is pure conjecture ("Dynamic typing is a good thing") that I happen to vehemently disagree with.

3. Also wholly immaterial.

[0]: https://nuejs.org/faq/#ts


A lot more material than your claims of "immateriality" with no justification though.

In fact it's rare to see "material" reasons for using TypeScript. Mostly baseless claims how static typing is "obviously better".


I don't need to "justify" their immaterialness. The OP needs to explain how it is material.

But whatever...

The merits of ES6 are also present in typescript. Thus claim 1 is immaterial.

Claim two is rebuked by intellisense and very strongly argued against in a shared-code world.

Claim 3 is presumptive that TypeScript would be the only transpilation, despite nue itself being a transpiler. In addition to all the other bundling modern products use for treeshaking, minification, etc. This is an insignificant and thus immaterial point.

("justification" enough for you?)

Did you even read the FAQ?


Jenk — can you help me with a list of valid reasons to choose JavaScript so that the TypeScript community is pleased? This would help me a lot. Thank you!


I would love to but I just can't see how it could be done.

I am interpreting the task as "how can we make people who favour strong typing favour not use strong typing?" - something that I just don't think is possible.

I guess the nearest experience you'll get is a zealous API convention that is inuitively consistent/discoverable, but then I would still favour a type system to remove that concern anyway.


The question is more like: "What are the benefits of choosing JavaScript over TypeScript?" You must know that there are pros and cons in every language. There is a reason languages like JS, Python, Zig, C, Go, Rust.. exist.


Given TypeScript is a superset of JavaScript, it's actually a question of "Would you prefer it if we took these (TypeScript) things away?"


I was asking you to take a little distance from the TS-world and use your experience (and maybe emphaty) to look about the pros of JS. Preferrably a list that pleases the TS community. The fact that JS is an "universal language" and runs natively on browsers and Node is a definite one, but then again.. this was a question for you.


The "pros" of JS exist within TS.


My hot take is that you can't reason with a cult.


For me, Typescript is more like documentation combined with Grammarly.


1. Proxies are painful to say the least on TS.

2. Code completion can be done also without static typing. Also relying on code completion is a strong smell of a bad codebase. The "very strong arguments" rarely have any empirical basis.

3. Transpilers/compilers are bad and more transpilers are worse. I would prefer a pure browser framework though. A lot of projects would be and are fine without treeshaking, minification etc. And those are practically never needed for development where the compilation step causes most harm.


For someone who opened with an accusation of baseless claims, you haven't done a very good job of providing a basis for your own claims.


Saving a few lines in a Hello World example is not the super great argument many of these web frameworks think it is...


More than a few lines in a Hello World example is a very damning argument against a framework.

Less code is better and DRY is by far the most important principle in software engineering.

Sadly every second generation seems to have to learn the hard way that the mega enterprise architecture astronaut stuff is a huge waste of time and produces bad software.


DRY is by far the most overrated software engineering principle and constantly pushing for it only leads more developers down the way of creating wrong, irreversible abstractions.


Interop, achievable via web components, is far more important than syntax, the last ms of performance, or shaking of 1kb in large applications contexts.

Hence, I strongly encourage the author to compile to web components instead of a custom output to increase/achieve interop.


There's a lot of discussion around Web Components in Nue JS discussion forum. Can I ask you submit your thoughts here? https://github.com/nuejs/nuejs/discussions/44

Would love to hear the details! Sample code would help a lot understanding the problem/solution. Thanks!


NueJS: “It’s just HTML!”

The HTML: <button @click=“count++”> {count} </button>


Please read the whole sentence. It starts with: If React is “Just JavaScript, then...” React users often say that "It's just JavaScript" but then they write:

  return (
    <div>
      <h2>You clicked {count} times!</h2>
      <button onClick={() => setCount(count - 1)}>
        Decrement
      </button>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>
    </div>
  )
Nue is the opposite side of the same coin.


> If React is “Just JavaScript, then...”

React is just JavaScript. React+JSX is JSX. This:

  <button onClick={() => setCount(count + 1)}>{count}</button>
Is sugar for:

  React.createElement('button', { onClick: () => setCount(count + 1) }, count)
True, the JSX version is most popular, but it's trivial syntax sugar with no "magic." This is different then Angular, Vue, Svelte, etc templates


isn't that just syntax sugar? I believe it compiles into (for some el function and safe string tag)

    return el("div", { children: [
      el("h2", { children: [safe`You clicked ${count} times!`]) },
      el("button", { onClick: () => setCount(count - 1), children: [safe`Decrement`] }),
      el("button", { onClick: () => setCount(count + 1), children: [safe`Increment`] })
    ]});
The "it's just javascript" part comes from having no hidden getters, setters or proxies littered in code that may or may not behave as how we expect, and not littering the html with react-specific attributes for iteration, events, etc


It surely is. React is a good pick for frontend engineers who prefer to use JavaScript or TypeScript. Nue is designed for UX engineers, who prefer a HTML- like syntax for defining the structure & layout.


Do people generally say React is “just JavaScript”? I’ve seen it said about Svelte, never React.

In any case, why market your framework with an equally poor comparison?


Yes people say that, and it is 100% true.

You can use all React features without any special tooling.


It's funny how React and other frameworks spent so much effort abstracting the render loop, meanwhile Nue is just like "call update()". And in the end, Nue looks a lot simpler to use.


> nue looks a lot simpler to use

Than what? I couldn't imagine react being hard, maybe for novice developers that just start with programming in general.

> React and other frameworks spent so much effort abstracting the render loop

Considering how big is community adoption and teams that are working on big 3 frameworks, they're doing it not "just because" and not to make your app slower. There are reasons for this and this new library will learn them as well, just like svelte did with their reactive variables approach.


Now I'm curious. Why do you suppose the render loop's performance was so important to the React team, then? It surely wasn't for no reason, and I'm not going to be convinced that React is more complex "just because."


For the benefit of other commenters: the parent said "simpler", not "easier".


What exactly is hard about React?


I am very impressed by the examples, they are so easy to read. I have zero experience with React, Svelte and JS in general, but after reading the examples make me want to learn more.


Thank you! So glad to hear this


same old template based data binding, just like observable never existed.

Most of the problems with data binding stem from the fact that there is not a prorammable understandable primitive for us to reason about it. Yet time and time again people try to hide such primitive behind some magic templates, hooks, runes and that kind of nonsense


Mind sharing your favorite frontend framework that got this right with an observable pattern?


have you heard of RxJS or Mobx? They both can be used in any mainstream front-end framework, though the combination is usually RxJS for Angular and Mobx for React.


I sure have! So Mobx + React is your favorite combo?


I'm so disappointed with react these days but yes, it used to be.


I love the idea of this and see great potential. The one blind spot I have is how to scale and DRY the application with shared libraries and outside plugins.


Thanks! You can import code on a top- level script tag. Will provide examples.


My brain is too smooth to grok this.

This calls a referenced function:

    @click="addFruit"
This executes an expression:

    @click="images.pop()"
What if I have a expression that returns a function that should be called?


It's using the event listener properties like "onclick" or "onload" as "@" gets replaced with "on" in the code from what I see so you will have this more oldschool event handling: https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Bu...

it also has some additional things here:https://github.com/nuejs/nuejs/blob/a5c844494852cdbe3282fdc5... so might not work the same way, didn't spend much time to check it just a glance.


This the same as in standard JavaScript DOM event call. If you want to call a returned function in JS, you can do: <button onclick="getFunction()()">. Similar behaviour in Vue (and Nue)


Its a typo then?

    onclick="addFruit"
is not the same as

    onclick="addFruit()"


The onclick="addFruit" calls an instance method between the inner script tags. Similar to how JS would call a global window.addFruit with a similar syntax.


Keyword being "similar", as in, not the same. Its neither the behaviour of html onclick attribute, nor dom onclick attribute.


I think I'm one that is a bit fatigued by the idea of learning a new thing w/o enough wins here.

On the other hand, the unproductive critique in all the comments makes me think everyone forgot how hard it is try to make something better.


For me there are two tiers.

1. The problem is so basic, I get it done with useState/useReducer

2. I problem is complex, and needs something more explicit like RxJS, or I'll lose my mind.


Patiently waiting until the pendulum swings back to async binding js events to elements by classes and ids and any inlining gets frowned upon.


Not sure what you mean. Can you provide some sample code so I can undesrstand the issue / use-case?


Not sure why but separation of concers was hammered so hard for a while that I cannot accept any inlined javascript or css at all. For me the reason is clear, I do not need to scan the html to know what a particular piece of code is doing and will just assume these ids are somewhere out there.

The first example of the site would become:

    <div>
      <h2>You clicked {count} times!</h2>
      <button id='decrement'>Decrement</button>
      <button id='increment'>Increment</button>

      <script>
        count = 0
        $('button#increment').on('click', () => { count++ })
        $('button#decrement').on('click', () => { count-- })
      </script>
    </div>


Glad to hear people still care about separation of concerns! It's been so untrendy. Particularly after Tailwind came around.


A bit more magic to need a new framework:

  <div>
    <h2>You clicked {count} times!</h2>
    <button id='decrement'>Decrement</button>
    <button id='increment'>Increment</button>
  </div>
  <script>
    count = 0
    increment.click(() => { count++ })
    decrement.click(() => { count-- })
  </script>


So we've come back to MVVM KnockoutJS-style frameowkrs after they went out of fashion oh so many years ago.


Are you talking about Svelte- like two-way data bindings? Like here for example: https://svelte.dev/blog/write-less-code — Same works in Vue. MVVM is Not implemented in Nue yet.


This does not look scalable.

Also debugging prod code will be a pain.

Cool tech demo but I would not use this for bigger projects


When building larger projects you should consider using a MVP (model-view-controller) pattern to separate your view code from the business logic. This way you can keep the view code simple, and the model code out from view-specific abstractions. This is called separation of concerns and is the primary way to build scaleable applications. I'll tackle this topic in detail along with a more complex demo application when Nue MVC project is released: https://nuejs.org/tools/#nue-mvc

Nue will be absolutely fantastic for scaling large applications and teams!


I'm starting to become a fan of your motivation (although count = 0 is still not ES6 classes variables). Good luck scaling it! Are you creating this framework out of your own necessity or just because it can be done? Any medium/large app using it to showcase?


Nice! Definitely my own necessity. Unfortunately no large showcases, because the toolset is not ready yet.


We are just making our way through every permutation of frontend API at this point.


> ES6 classes make your code look amazingly compact and clean. You can add variables, methods, getters, setters, and async methods with the cute and short syntax.

Huh, I didn't know that. I still don't know that :)


As Svelte move away from this, I think it is valid that some framework will pick on it and continue developing this route. It was one of the reasons I ditched Svelte so it won't make me use Nue.js.


Not sure what you refer to as "this" or "it". Both Svelte 4 and Runes are are quite different from Nue.


Svelte became famous for count = 0 and $count working as reactive constructors. The only change in Nue.js approach is removing $.


looks good at first glance, but I am not very happy with "count++"

everything inside "" should be string; otherwise it's confusing.

this is my personal preferences and it applies to any project


You can also call instance methods from the @click handlers. Nue syntax is heavily inspired by Vue.


having js code in html attribute is not something I want (`@click="count--"`) I'd rather have longer, actual js code as a trade-off


You can call an instance method as well, as seen on the examples. Similar to what you can do in Vue and with a standard JS 'onclick' handler.


As I would like to call it, the new shiny js tool of the week. Aren't we all already tired of this


Going through the nue the tldr I got is "bring back simple html friendly declarative directives (hello AngularJS)"

Nice to see people trying to push boundaries

Nue might not be a great option for building large scale web apps; it however could be a great way to add reactivity to simple websites. We don't need to have the full fledged webpack monstrosity for every little site.


Nue is a breath of fresh air. Those who are suffering from a prisoner's dilemma under React will obviously say "How can you do this?" You should mostly ignore them. Hope the ecosystem around Nue flourishes. Can't wait to use it.


Why does the majority of front end developers have trouble learning OOP and spend their whole time trying to avoid it?

Signed: a concerned Angular (the best framework there is in the whole world) developer


How performant is this?


Unfortunately no benchmarks yet. Nue is very new. Will be there some day!


lol the JS crowd have fatigued themselves reinventing the wheel a dozen times to the point where they’re now just haters. Good luck op!


Thank you, Mack — I can feel it!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: