16 ms·

Show HN: Nue – A React/Vue/Vite/Astro Alternative

• deleted 3y ago
  [deleted]
• deleted 3y ago
  [deleted]
• ash 3y ago
  Hello Tero! Do you have project example using Nue (however small)?
  • tipiirai 3y ago
    Hey! You can clone and play with this: https://github.com/nuejs/create-nue https://github.com/nuejs/create-nue — it showcases Nue JS, which is currently the only thing completed from the Nue Ecosystem. The only real Nue project atm is the nuejs.org website.
    • _d3Xt3r_ 3y ago
      Noob here, but also a former web dev from the Web 1.0 days, looking to get back into the game. Like you, I dislike much of the modern web frameworks and all the bloat and unnecessary complexities that come with it. I roughly tuned out of this stuff when JQuery became mainstream and everyone and everything started using it, and I couldn't be bothered to keep up any more, nor did I feel inclined to invest my time in such a bloated framework. I did come back to webdev every now and then for casual projects, but every time I did, the world moved from one fad framework to the other, which made me dislike this messy ecosystem even more. In particular, one environment/toolset that I really disliked was Node.js. Every time I did anything with Node, it always turned into pulling down a gazillion dependencies, and eventually down the line, that led to stuff breaking because some random dependency of a dependency was no longer compatible a with newer version of node or something. It basically put me off modern webdev for good, to the extent that I web back to using plain ol' php for the backend, and since then I've been exploring using pure HTML5+CSS3 without any Javascript for the frontend, but I've been seeing limitations like not being able to do stuff like real-time form validation etc. Which brings me to your example: # install dependencies npm install May I enquire why you're using npm here? Exactly what dependences are you pulling down? I thought the whole point of Nue was to avoid bloat like Node.js and dependency hell? Isn't Nue supposed to be a self-contained library/ecosystem? Can I use Nue without touching any Node stuff at all?
      • tipiirai 3y ago
        I hear you! I went all-in to jQuery- scene. Even wrote a semi-famous library called "jQuery Tools" (oldies know). Then came React and I wrote Riot to simplify the syntax. Then I sidetracked to a startup world for (too) many years and watched aside how the frontend ecosystem grew to it's current dimensions. Node uses a single dependency, htmlparser2 [1], in the package.json [2]. The HTML parser is used to traverse the HTML that is written on the Nue files. I quickly _thought_ of writing my own parser, but right now I'm having my eyes staring at Bun's native HTML parsing capabilities. Instead of Node, I'm using Bun to develop everything. I need less dependencies with it, because things like JS minification or .env file parsing are biult in. Avoiding NPM dependencies is a high priority! [1]: https://github.com/fb55/htmlparser2 https://github.com/fb55/htmlparser2 [2]: https://github.com/nuejs/nuejs/blob/master/package.json#L12 https://github.com/nuejs/nuejs/blob/master/package.json#L12 [3]: https://github.com/oven-sh/bun/discussions/1522 https://github.com/oven-sh/bun/discussions/1522
• JohnMunsch 3y ago
  I don't want to poop all over someone else's project (hell, it's hard as hell to do anything like this), but I have to say that this feels like exactly what you said, a React/Vue/etc. alternative. But that is absolutely not what I want and not what I think will do people the most good in the long run. Another project that largely ignores that custom elements and Shadow DOM are readily available on every modern browser (including the ones on your phone) and instead chooses to "simulate" components instead is... short sighted. I crave something that attempts to fill in the missing pieces between something like say Angular and Lit. Give me something that treats a Web Component as its underlying tech for components but offers good support for animation. Something that comes with simple support for migrations (Ala Ruby on Rails) but doesn't include a ton of tooling for CSS that is not really needed anymore (I'm looking at you React) or was created before JS Modules and is still not making good use of them (ahem... Angular). So, if someone is still stuck in React land, maybe this will be what they are looking for, but for someone keen to use what is built into modern browsers for speed and smaller apps, this seems like something we should pass on.
  • niutech 3y ago
    Have you tried Stencil (https://stenciljs.com https://stenciljs.com)?
    • JohnMunsch 3y ago
      Not yet, but I may give it a try. The JSX this is as off-putting as a case of leprosy though. The idea that React needed to invent something new that wasn't JavaScript was absolutely terrible.
      • niutech 3y ago
        You don't need to use JSX. Stencil integrates with other frameworks such as Vue or Ember: https://stenciljs.com/docs/overview https://stenciljs.com/docs/overview
• niutech 3y ago
  Nice project, well done! However, it is more like an alternative to Petite-Vue or Riot.js rather than full-blown Vue or React. Therefore your comparison vs headlessui-react/vue is like apple vs orange/banana: headless UI listbox is much more complicated than your implementation. You can easily make a listbox in Vue using a similar amount of code as Nue. One thing which is lacking in your Getting Started (https://nuejs.org/docs/nuejs/getting-started.html https://nuejs.org/docs/nuejs/getting-started.html) is how to use Nue without a build step, in order to progressively enhance existing HTML websites like Petite Vue: `<script src="//unpkg.com/petite-vue" defer init></script>` or Alpine.js: `<script src="//unpkg.com/alpinejs" defer></script>`? How is Nue performance compared to other JS frameworks? Could you add it to https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...?
  • tipiirai 3y ago
    Thank you! You are right: Nue takes inspiration from Vue 2.0, petite-vue and Riot. I'll make the comparison more fair, but it doesn't take out the fact that React/Vue promote use of "spaghetti" code where logic/layout/styling are mixed together making the code hard to read and causes the size to grow. Everywhere I look the projects are unnecessarily big. Very often in the factor of 10x too big. Pretty sure Nue JS will always need a build step. I don't like the idea to load the compiler and run JS exec() on the client side. Heavy and unsecure. Haven't checked performance yet. I want to see this project getting more traction before deep diving to benchmarking
    • hackerman_fi 3y ago
      I jumped straight to comparison (as it’s listed first) and was let down because the comparison seemed borderline deceiving. The other examples had hundreds of lines of logic and types for example.
      • spoiler 3y ago
        Also, it was comparing a headless library with a concrete (and rigid) implementation. You could use the a similar amount of React code to get the same concrete implementation. Probably not intentionally deceitful, but it a ridiculous comparison.
• nsonha 3y ago
  [flagged]
  • deleted 3y ago
    [deleted]
  • lolinder 3y ago
    Can you clarify why you believe this, rather than just posting a shallow dismissal? "Horseshit" does nothing to help me understand your point of view other than make it clear you feel something very strongly.
    • Semaphor 3y ago
      While their wording takes some work, it’s simply not "just HTML". Even less so than react is "just JS". It’s a DSL applied on top of HTML.
      • lolinder 3y ago
        Agreed, the distinction matters and it's worth respectfully pointing out. Thanks!
      • deleted 3y ago
        [deleted]
    • nsonha 3y ago
      [flagged]
• benatkin 3y ago
  Svelte is mentioned on the site but not in here. Is it harder to put Nue, or another framework, forward as an alternative to Svelte/SvelteKit? I think SvelteKit is batteries-included while still being fairly small and easy to understand.
  • tipiirai 3y ago
    Svelte is indeed a bit different to how the internals are implemented and what kind of compilation results are created. However it is a component-based UI framework and they also compare themselves to React a lot. When Nue ecosystem is completed, it can be compared to Nuekit.
    • benatkin 3y ago
      Well, I like Svelte, and so far I don't want to write code in Nue, based on the examples. The last I looked on HN there were 67 upvotes and 34 comments. That's less than double the number of upvotes to comments. I think it's being ratioed not because people dislike the attempt at writing a web framework with a different syntax, but because the site and the text claim it's competitive with all these frameworks.
      • tipiirai 3y ago
        It's me replying to everything in here :)
      • robertlagrant 3y ago
        I think "ratioed" is a pretty weak signal in general, and especially here. At least compared upvotes to commenters, not comments.
• CSSer 3y ago
  Would you mind sharing some details about how you made this? https://nuejs.org/compare/component.html https://nuejs.org/compare/component.html It’s very cool. I’m on my phone, but I’d like to investigate more later.
  • tipiirai 3y ago
    Thanks! It's a custom made script to generate a HTML page with `pre` blocks to render the source code on a file. Then a Nue-based zooming app on top of it. The images on the site are screenshots from this app.
    • deleted 3y ago
      [deleted]
  • cornedor 3y ago
    This is done using css columns. The slider controls the font sizes, and the column width is set to 30em, which increases when the font size increases.
• madmod 3y ago
  This looks great! Reminds me of crank.js in that it leverages native language features (generators) to greatly simplify interactive html. Please add a mailing list to the homepage so I can keep up to date with your progress. A blog with smaller updates would be nice also.
  • tipiirai 3y ago
    Thank you! Good idea. I'll add blog + mailing list. I have a lot on my mind! (lol) Before that you can follow Nue on Github and notifications from there: https://github.com/nuejs https://github.com/nuejs
• pier25 3y ago
  Congrats looks great. Can't wait to see the whole vision with Nuekit. Not a fan of the Vue template syntax but it's not a deal breaker. I really love that you don't need a bundler.
  • tipiirai 3y ago
    Thank you! I'm glad this initial launch got some traction so I'm absolutely going to cross the finishing line. The ecosystem code is actually done and the website is made with Nuekit. Need to polish the code, rewrite some pieces, and document everything — which is the time consuming part.
  • meowtimemania 3y ago
    +1 on not requiring a bundler. It makes it so much easier to try out on just 1 or 2 pages when you don’t have to also add a compiler.
    • tipiirai 3y ago
      Exactly. And bundlers are quite big monsters. Vite, for example is 32MB on disk.
• rafael-lua 3y ago
  > Tailwind or any other CSS-in-JS system is not the recommended way to implement styling I see, I'm not the target audience here, I can't see myself going back to the old ways. But I am happy that people who can't get into the wonder world of utility classes also have frameworks with their philosophy in mind from the core, which could provide more modern solutions for their preferred way of styling. Let's see how this projects evolves overtime, best of luck!
• oooyay 3y ago
  How does cross-component state work? I'm thinking something like Pinia in the Vue ecosystem. You might've mentioned it on the site but I couldn't find anything about it.
  • tipiirai 3y ago
    State manager / Router is on the roadmap. Check "Nue MVC" from https://nuejs.org/ecosystem/ https://nuejs.org/ecosystem/
• lolinder 3y ago
  Your comparison of the various ListBox implementations[0] feels disingenuous. I know Vue best, so I looked at that implementation in detail, and it's got a lot going on that you don't attempt to replicate in your version. A few key features that are missing: * Search—in the Headless UI version there are several hundred lines dedicated to making typing work for jumping to specific list items. * Multiselect—Headless UI supports multiple selections, yours does not appear to. Again, this accounts for a large number of extra lines in the Vue implementation. * Focus management—Headless UI has a lot of code dedicated to smoothing out the focus management. In my testing, your implementation has pretty buggy support for using tab to navigate. * The Headless UI version dedicates a lot of lines to types, where your Nue implementation is dynamically typed. This may be a feature for you, but in my mind those type declarations are doing important work. * In general, the Headless UI implementation tries to be flexible for many use cases [1], while yours only needs to support the one demo list. These kinds of comparisons are most persuasive if you can write all the implementations from the ground up, using idiomatic patterns for each framework and identical feature sets for each implementation. When you do that, it's easy to compare and contrast the frameworks. As it is, it's like comparing a house to a garden shed: yes, you've used fewer lines of code, but it's not obvious to me that that's a feature of Nue and not just a byproduct of a less ambitious component. [0] https://nuejs.org/compare/component.html https://nuejs.org/compare/component.html [1] https://headlessui.com/vue/listbox#component-api https://headlessui.com/vue/listbox#component-api
  • 420official 3y ago
    It also seems a little disingenuous to suggest tailwindcss requires 800kb to build a webpage
    • tipiirai 3y ago
      Is there such suggestion? I merely counted the amount of HTML/CSS/JS tailwindcss.com has on their frontpage and put it in a comparison chart. They key take there is that inlining styles to markup and loadinng the utility CSS makes it hard to keep the initial TCP packet below 14kb, which is a limit for extremely fast loading performance.
• theogravity 3y ago
  Congrats on the launch! Looks really interesting. I'm looking through the documentation and am having trouble understanding the slots example: https://nuejs.org/docs/nuejs/component-basics.html#slots https://nuejs.org/docs/nuejs/component-basics.html#slots I'm unable to see the relationship between the <slot /> tag and the looped content in the 2nd code snippet. Can you clarify that in the documentation? Edit: I think it would have made more sense if you included the @name="media-object" attribute in the first snippet.
  • SparkyMcUnicorn 3y ago
    It appears to be similar to Vue. The first snippet is the <media-object> component, and the second snippet is using the component. Everything inside the component tag goes into the slot.
    • theogravity 3y ago
      I'm from a non-vue audience, so the context would be lost on someone like me.
      • tipiirai 3y ago
        Can you clarify? Not sure I understand what you mean.
        • theogravity 3y ago
          My background is React, and I have no Vue experience at all. I only figured it out by looking at the previous section's code before slots to see that attribute and noticed that the slots example first snippet was missing the attribute I mentioned that would connect the pieces together
  • tipiirai 3y ago
    Thank you! The slot syntax is borrowed from Vue. The difference is that there can be only one slot, and not multiple named slots. I can see that the slots example needs improvement and more detail. I'll make it shine because slot is such an important feature and helps you build reusable code. I'll work on the docs as a whole, now that I'm getting this valuable feedback from here.
• thatxliner 3y ago
  How does it compare to Svelte?
  • tipiirai 3y ago
    The syntax is HTML- based, strong preference to separate styling/logic from the UI code, and keep it familiar with UX developers [1] (not JS developers), there is no need for Bundlers like Webpack or Vite, and it's written in more minimalistic fashion. Your app is probably smaller too if it's anything more complex than a TODO- app, because Nue is only 2.3gzipped and the compiled files are very small too. [1]: https://css-tricks.com/the-great-divide/ https://css-tricks.com/the-great-divide/
• ilrwbwrkhv 3y ago
  This is fantastic. As much as the web changes and people complain about "new frameworks" everyday, all the major frameworks are surprisingly similar. Rethinking things from the ground up and making it smaller and more RAM efficient, is absolutely brilliant. More frontend devs needs to stop following the herd and think for themselves and look back at how hackers used to work back in the day to use as little memory as possible. These days I look at apps like Slack and feel such terrible sadness and despair. Projects like Nue at least have the right spirit and attitude.
  • tipiirai 3y ago
    This. So glad to see there are still people who care about minimalism! I asked here on HN the other day that "why your login screen loads 6.4MB of resources" and they said that VSCode is ~200MB and gdocs is ~30MB so it's not that bad. That's the spirit these days. I want to make things very, very differently. Not just because of the size, but maintaining a codebase with 5k lines is so much easier than maintaining 500k lines.
    • davedx 3y ago
      The problem is more in the ecosystem side than the core libraries side. Many front end devs build UIs for a day job and when they’re developing some new product requirement they don’t think twice before pulling in react-widget, react-ui-this, react-router, react-accordian. This is the main issue that creates bundle bloat and maintenance pain down the line. I don’t know what the solution is there.
      • zelphirkalt 3y ago
        Better education or being more informed would help. Knowing the basics well, like HTML and CSS, to already avoid some of the JS. Then knowing a backend language can help with actually considering simply rendering templates on the server using some template engine, like done for decades. Some knowledge about setting up a HTTP server would probably also help. Knowledge would help being able to take a step back when needed and think: "Do I actually need much interactivity here?" Question is how we get web developers to learn those, instead of the next (ha) hyped JS frontend frameword.
• demondemidi 3y ago
  Do you plan to support this for 5 years or more? Because that's the kind of LTS I need to take this seriously.
  • abdellah123 3y ago
    Read the source, it's a few hundred lines of code. It's very much possible to treat is as your own app code and "maintain" it. Kudos to the author, the best thing about this is that the source is concise!!
    • da39a3ee 3y ago
      I disagree that vendoring / forking a 3rd party library is a good idea.
    • demondemidi 3y ago
      You do not understand how software is written. We do not support third party tools. We expect third party tools to be supported. Otherwise they are of no interest. We have other priority items to focus on.
  • tipiirai 3y ago
    I plan to develop this as long as there are people using it. If the world changes and a new jQuery comes around, then I have to see how to adapt. But the goal is to stabilize the code and make it production ready. Same for all project on the Ecosystem. By looking at todays traction, I'm highly motivated to continue with this project. I'm working full-time actually because I don't have a day job atm. I like it.
• hknmtt 3y ago
  New day, new JavaScript framework...what's new? Anyway, I highly recommend Quasar if anyone's looking for something new to use. Been using it for two years now and after 20 years of coding I felt happy using JS. Not that Vue is not good but quasar just has it all and is built on top of Vue.
  • tipiirai 3y ago
    Thanks for the pointer. Quasar seems more like an UI library. Like Material UI or Chakra. Not directly comparable with Nue JS. It's comparable with the upcoming Nue UI though: https://nuejs.org/ecosystem/ https://nuejs.org/ecosystem/
• Aleksdev 3y ago
  Looks neat! Will keep an eye on it.
• bashtoni 3y ago
  I wonder what the rise in AI assistants like Github Copilot will mean for new projects like this? Will people avoid adopting them because code won't be auto-generated efficiently? It wouldn't be a barrier for me or many people that read hacker news, but I suspect there is a growing subset of the developer community for who this would be an issue.
  • tipiirai 3y ago
    Depends on whether Nue becomes relevant. New projects are obviously unknown to AI, but they learn as the world starts adopting them.
  • professoretc 3y ago
    That's what I'm a bit afraid of. Will software engineering get "stuck" with just the tools we have right now, because LLMs won't be able to help with anything newer? If you're thinking, all we have to do is wait for OpenAI to re-scrape the web and re-train GPT on the new material, well... LLMs don't "learn" so much by looking at documentation, as by looking at examples. And a new tool is not going to have a lot of examples out there, simply by virtue of being new.
    • smokel 3y ago
      Also, people are already misusing LLMs to generate blog spam, which regurgitates existing knowledge. Future LLMs will have to train on that as well. The "Selfish Gene" strikes again.
    • sparkie 3y ago
      LLMs don't just regurgitate examples, but the have some internal model of the world and can learn new things. See this example: https://szopa.medium.com/teaching-chatgpt-to-speak-my-sons-invented-language-9d109c0a0f05 https://szopa.medium.com/teaching-chatgpt-to-speak-my-sons-i.... A sophisticated enough LLM should be able to read a documentation and learn a language faster than a human programmer, but we're nowhere near that stage yet. Aside, this is not going to stop people learning and using a language if it provides benefits. Not everyone is on the AI hype train. I personally couldn't care less - I don't trust any current AIs to write correct, bug-free code and so I just avoid them. Then again, I also don't trust most humans to write bug-free code and I tend to avoid them too. Formal verification should be the way forward, and this is why new languages, which can embed proofs, should continue being developed and improved, ignoring the AI hype. When the AI can write code in formal verification languages, I might consider it.
• gcau 3y ago
  Here is what some of it looks like. ``` <div @name="media-object" class="{ type }"> <img src="{ img }"> <aside> <h3>{ title }</h3> <p :if="desc">{ desc }</h3> <slot/> </aside> </div> <div class="art-gallery"> <media-object :for="item in items" :bind="item"/> </div ``` I really don't like the opinionated, magical/weird syntax (like vue's :@v-for-OnClick="fn()"), I prefer how close and true to vanilla html/js react is, rather than stuff like this.
  • tipiirai 3y ago
    Yes. Nue is indeed HTML-based and takes inspiration from Vue. It is designed for UX developers who prefer to use HTML/CSS and minimal JavaScript to communicate with the business model layer, that the JS developers are building. That is: separation of concerns. I can understand that this syntax is not a preference for JavaScript/TypeScript developers who opt to JSX and want to write everything (logic, layout, styling) in JavaScript.
  • kitd 3y ago
    <p :if="desc">{ desc }</h3> That </h3> should be a </p>, I think.
    • tipiirai 3y ago
      Thanks. Fixed
  • orangepanda 3y ago
    My problem with these :ifs and v-ifs and {#ifs} is I cant place a breakpoint and step through _my_ code with a debugger.
  • niutech 3y ago
    React is far from vanilla HTML. It uses JSX with attributes e.g. `className` or `htmlFor` instead of HTML's `class` or `for`. And JSX requires compiling to HTML rather than being HTML from the beginning.
    • 3y ago
• caesil 3y ago
  >Nue CSS >Bring back the power of cascaded styling Welp, I'm out.
  • tipiirai 3y ago
    Yes. Nue is probably not a good pick for people who really like things like React and Tailwind. It's more like going backwards in time when standard HTML, CSS, and vanilla JavaScript was a thing.
    • timeon 3y ago
      Tailwind is maybe good for people that do not want to learn CSS but creates bloat for user to download.
      • tonyoconnell 3y ago
        You can use DaisyUI to clean things up
      • sensanaty 3y ago
        How exactly do you use Tailwind without knowing how to use regular CSS first? Pretty much everyone I known uses Tailwind BECAUSE dealing with CSS is a fucking nightmare, even in component-based frameworks.
        • progx 3y ago
          I know CSS and have to look always into the Tailwind documentation to find the corresponding settings. As long as you use tailwind 0815 settings everything is ok, but not easier as css (if you know css).
      • ceesharp 3y ago
        You do know that unused styles get removed and Tailwind gets converted to plain CSS?
    • PennRobotics 3y ago
• xyst 3y ago
  https://xkcd.com/927/ https://xkcd.com/927/
  • tipiirai 3y ago
    Nue does not try to be a new starndard. It tries to bring web developers closer to web standards: HTML, CSS, DOM, and plain JavaScript. New developers today start with React, learn hooks, adopt Tailwind, and writes TypeScript and distance themselves from the basics.
    • Aeolun 3y ago
      > distance themselves from the basics It’s almost as if there’s a reason for this. Classic HTML is pretty good for building static websites, but it sucks for building interactive applications.
• beefman 3y ago
  Kudos for the emphasis on code size – this is something I always liked about Riot. But the comparison faq currently returns a 404 https://nuejs.org/compare/faq/ https://nuejs.org/compare/faq/
  • tipiirai 3y ago
    Thanks! I fixed the links. Here is the correct one: https://nuejs.org/compare/faq.html https://nuejs.org/compare/faq.html
    • beefman 3y ago
      Do you have a RealWorld implementation? https://codebase.show/projects/realworld https://codebase.show/projects/realworld https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 https://medium.com/dailyjs/a-realworld-comparison-of-front-e...
• rk06 3y ago
  I get why you want to replace vue/react/next/nuxt, but why vite? Are you really planning to create a new build tool?
  • tipiirai 3y ago
    Not a build tool, but rather a web application builder with support for multi-page applications (aka. websites) and single-page applications. Vite is (mostly) a SPA application builder so that's why it is mentioned.
    • rk06 3y ago
      Vite can be used for MPA for eg: Astro uses it. While you may not need it, everyone else may have different needs
      • tipiirai 3y ago
        Exactly. Nue is an _alternative_
• wruza 3y ago
  ListBox/PopupButton … The React version is 2500 lines of JavaScript Is this idiomatic? I refused to use React for years, but if this is normal-ish, it basically cements the decision. An implementation of a ListBox in VGA 0xA0000 framebuffer could be only a little bigger (if even bigger). GtkTreeView, which draws a complete tree/table with columns, resizing, dynamic rows and all the interactions, was 10kloc, afair (now 14). GtkCombobox.c is 5kloc, almost half of that is comments or doxygen.
  • Loeffelmann 3y ago
    The listbox does a lot like searching, multiselect, is completely accessible and includes a lot of types. It's a really unfair comparison.
    • wruza 3y ago
      Do you mean my comparison to gtk, or on-site comparison to nue?
    • xigoi 3y ago
      Even with all those features, 2500 lines sounds like way too much.
      • lolinder 3y ago
        He's also included pieces of Headless UI's embedded framework, which they use to minimize the differences between the different implementations. It's definitely not representative of regular code in the frameworks being compared to.
• siduck 3y ago
  would be great to use bun with this!
  • tipiirai 3y ago
    Bun is really awesome! I'm using it to develop Nue. It runs the minimalistic code in instant. Everything is sooo fast and pleasant. Test suites finish as soon as I release the Enter key.
• siduck 3y ago
  what would be nue-css? i really like unocss currently as its syntax's pretty clean like <div border="1 solid red"> instead of tailwind's <div classname='border-1 border-solid borde-red /> also <div bg-red> too, it supports value-less attributes and one can use a single class name as tag name too, like <bg-red> something </bg-red>
  • tipiirai 3y ago
    Nue CSS is like SASS, but more minimal and more in line with the current standards. Think CSS variables instead of template variables. It's pretty vocal about semantic CSS and separation of concerns once it's public. The main thing is to give a strong alternative to the current css-in-js movement. Haven't checked Uno CSS in detail, but looks like it's a close companion to Tailwind. Nue is a big step away from tight coupling.
• amilner42 3y ago
  Cool ideas, took a brief look but I’ll need to dig in when I’m at my computer. On a sidenote, I was startled by the tailwind mention. Am I out of the loop? Is it not just some css classes? Why is it being compared to React? I’ve used tailwind casually a few times and dont remember it increasing my build size very much at all.
  • tipiirai 3y ago
    Please check the original post. This is a launch of the first item (Nue JS) in a new, uccoming frontend development ecosystem. One part of the ecosystem is a project called "Nue CSS", which aims to bring developers back to more standards based CSS development and it emphasizes that separation of concerns is a good thing (and not a bad thing as TW states).
• slj 3y ago
  I will be using this for my next project. Thank you.
• eh8 3y ago
  It's really awesome to see this recent counter-revolution of developer tools emphasizing simplicity. Nue gives me the same optimistic, feel-good vibe that htmx and Alpine.js gave me when I first read about them. Best of luck, wishing the author all the best!
  • tipiirai 3y ago
    Thank you!! This means a lot actually and gives me motivation to implement everything on the roadmap.
• tipiirai 3y ago
  Hey fellow devs. I'm heading to Finnish forrest to practise disc golf. Will answer to all the critical questions later this evening. I'm so happy this launch went well and I'm super motivated to build a great, minimalistic frontend toolchain that is closer to web standards.
  • kunley 3y ago
    As a non-Suomi guy who ended up living in Finland part-time, I can relate so much. Enjoy the forest!
• theN00t 3y ago
  I was an avid user of Riot back in the days and loved the small library. I will take a look at this when I have the time :)
• josephernest 3y ago
  Very promising! Would it be possible to use your framework with any server of my choice (Python or Node or even PHP), and use Nue only for the frontend? In this case, since it's just JS + HTML + CSS, can we have an "Option #3" in https://nuejs.org/docs/nuejs/getting-started.html https://nuejs.org/docs/nuejs/getting-started.html with no command-line, no `npm install`, no `npm run start`, no use of `npm` at all? It would be nice to have a Hello world example with just a HTM file + import of Nue from your CDN (or from local). Is that possible? I'd like to totally avoid npm, etc, just write JS + HTML + CSS, and use my own server.
  • omnimus 3y ago
    Not possible without buildstep. Use something like alpinejs
  • niutech 3y ago
    +1 for a zero-build-step bundle. As an alternative you can use Petite Vue, which is even smaller.
    • synergy20 3y ago
      alpinejs is even better as petite was not actively developed, petite is there after it says alpinejs
      • niutech 3y ago
        Petite Vue is considered "done" in terms of features: https://discord.com/channels/325477692906536972/1050439284341096571/1054597576101474384 https://discord.com/channels/325477692906536972/105043928434...
  • tipiirai 3y ago
    Node or Bun is required. Not planning to support client-side compilation and running exec() on the browser. I have super vague plans to make a Zig-based compilation to work natively in Bun and runnable from other languages too. But later...
• deleted 3y ago
  [deleted]
• siduck 3y ago
  are there any plans for making the state management exportable? in react state's bound to the component, but in solid-js we can define it outside the component and export it, and components from other files can easily use it :D like export const [counter, setCounter] = createSignal(0) you can probably look at js proxies
• cornedor 3y ago
  The comparison on the homepage is not even close to fair. They compare a React component from a headless UI library that has a lot of (accessibility) features and full TypeScript typing to a basic version without any typing. > The amount of code required to build a basic listbox UI component That is not what is being compared. The speed graph shows the amount of HTML/CSS/JS on the project home page. Again not even close to a fair comparison, they have completely different content. I can create a sluggish library, with a homepage that is just a plain text link to a GitHub repo and that would rank way higher.
  • jampekka 3y ago
    Isn't basic version without any typing being shorter and clearer a fair comparison of JS against TS?
    • sprkv5 3y ago
      For a fair comparison they should have compared the React JS implementation with Nue.
    • lolinder 3y ago
      Not if it does a fraction of the work. The current comparison basically says "look what you can do if you don't have to worry about accessibility or supporting multiple use cases!"
• Kiro 3y ago
  I'm missing the classic example where you click a button to increment a value. In fact, I fail to find any example handling state at all. Any pointers?
  • deleted 3y ago
    [deleted]
  • niyaven 3y ago
    The closest I could find was a carousel[1], since clicking on a button will increment/decrement an index. I agree that the classic examples are missing. I would have like a simple counter and a TodoMVC. [1] https://nuejs.org/docs/nuejs/reactive-components.html https://nuejs.org/docs/nuejs/reactive-components.html
• MrJohz 3y ago
  I really like the idea of a framework designed from first principles around the idea of islands and progressive enhancement. That said, this feels like a lot of potential misleading marketing. Firstly, I don't think the comparisons with React/Vue are hugely helpful for Nue. React and Vue do a lot. You're right that most people probably don't need all of that stuff, but it is in the frameworks for a reason - those who need it really do need the complexity. Some better points of comparison in terms of compile-to-JS frameworks might be Svelte and SolidJS, both of which have some similar goals to this, and specifically focus on producing small, fast code. Alternatively, if you want the "it's just Javascript" approach, Mithril is another great framework oriented around minimising complexity, albeit with a reactivity model more like React's. I also think the specific code comparisons scattered around the site are similarly unhelpful. For example, you typically use Typescript-based examples for other frameworks, and JS-based examples for your own. This is obviously going to make Nue look smaller, but typically people use Typescript for good reason, and understand the trade-off around code size. More egregiously, many of the comparisons seem very much apples-to-oranges comparisons. For example, the React listbox on the homepage is a part of Headless UI - it meant to be as unopinionated as possible and allow the user of the component to bring their own components, styles, etc. This makes it more complex but more powerful - a trade-off that isn't always worth making, but can be very useful for these sorts of components where 90% of the complexity is getting the UI interactions right. Your example is not headless, I don't think it's even styleable, and while it includes keyboard navigation, the lack of aria tags makes me doubt its accessibility. That doesn't mean it's bad - it looks like the sort of component I'd write as a custom component for a particular project - but it makes the comparison somewhat meaningless. I would imagine any component I wrote in most frameworks I use would be a similar order of magnitude in size. (In fairness, I've just seen you call both of these points out in your compare FAQ. I disagree with your answers though - a framework's choice to use Typescript internally does not affect the choices of users to write components in Typescript, so "embracing dynamic typing" feels meaningless in this context. Moreover, it's not apples-to-apples if the components themselves are designed with different purposes - a quick React listbox could look a lot simpler if it needed to.) More practically, I think it would be really helpful if you talked about rendering model more clearly. As a frontend developer, this is one of the first questions I have when looking at a new framework. Is reactivity sound, or am I going to have to spend a week trying to figure out why some variable isn't updating when I think it should be? It looks like the Svelte-style compile-to-DOM-mutations approach, is that right? I have some other more philosophical quibbles with some of the claims in the documentation and FAQ, but I don't think those are so important. But I do think they you could improve the sales pitch a lot by making the underlying technologies clearer, and by having more useful points of comparison. As an aside, do you have an entry on the Krausest framework benchmark yet? It may be worth submitting a PR there. Obviously pure framework speed isn't everything, but it's a useful point of comparison to see how one might approach the same problem in different frameworks, particularly a fairly intensive problem.
• kunley 3y ago
  Moi Tero! At a first glance I like it a lot. With regard to the "Why" section and the FAQ - kudos for the bold claims, that was needed. Typical frontend ecosystem went insane long time ago. Thanks for your effort to bring back the sanity.
  • tipiirai 3y ago
    This was my favourite complaint of the day. Thank you Kunley!
• coldblues 3y ago
  There's no VSCode extension. How am I supposed to use this??? :)
  • al_be_back 3y ago
    >> You can use whatever extension you wish on the component file, but .nue extension is recommended. You can also use .htm to have your editor (and GitHub) automatically color highlight the code and to distinguish them from static .html files [1] https://nuejs.org/docs/nuejs/component-basics.html https://nuejs.org/docs/nuejs/component-basics.html
  • deleted 3y ago
    [deleted]
• KRAKRISMOTT 3y ago
  Does your SSR support component level network and caching optimization (i.e. streaming in an island architecture configuration)? That is the current state of the art for JavaScript single page app server side rendering.
• aziis98 3y ago
  Awesome project, feels very refreshing even for me being a great fan of Vite and Astro. Just curious, how do you handle the client side reactivity? Does it use something like virtual dom with diffing or do you compile everything like Svelte (or even some other strategy)?
  • jadbox 3y ago
    I've been using Astro over the last couple weeks. After reading most of the docs, I don't really see how Nue is really better on any metric aside from a smaller base local development library. For actual client builds, most of my interactive Astro pages have no JavaScript at all (instead using seamless page transitions).
• jamesfisher 3y ago
  After reading the homepage and the docs homepage, I still don't know what it is. What's the key API difference that lets you write only 10% compared to React? What's the "hello world"?
  • deleted 3y ago
    [deleted]
• Aeolun 3y ago
  > The best results are gained when UX developers and JavaScript developers work in parallel without blocking each other. In my experience the best results are gained when they’re the same people. Splitting them up sounds like a recipe for disaster to me.
  • deleted 3y ago
    [deleted]
  • mixmastamyk 3y ago
    Are there enough people good at both? You could replace JS developer with Java or Python (which JS dev is closer to), to see the divide more clearly.
• gloosx 3y ago
  >It's like React/Vue core, but there are no hooks, effects, props, or other unusual abstractions on your way I have almost a decade of React experience and to my ear this sounds very weird (starting from React/Vue put together casually). For me – React is really 7 hooks that provide usual abstractions and nothing more. EDIT: I just looked through their listbox "code volume" comparison and it seems like a bad joke. Obviously meticulously type-scripting anything and exaggerating the code to the absolute will make it look BIGGER when compared to plain js file crafted to make it as thin as possible. I don't think it can stand a fair comparison though.
  • deleted 3y ago
    [deleted]
  • gloosx 3y ago
    For the author @tipiirai here. A fair and functional challenge: what will be Nue solution for making this beautiful triangle? https://codesandbox.io/s/pedantic-mclaren-nqpjl5?file=/src/App.js https://codesandbox.io/s/pedantic-mclaren-nqpjl5?file=/src/A... As you can see it is 20 lines of code and zero hooks for React. It also takes a finite time to compute a limit > 2^10 without code sandbox complaining. I wonder how much time Nue needs to render for limit=2^10? 2^100? Then we can compare.
    • tipiirai 3y ago
      Challenge accepted! Likely 5x less code and 2x faster. I'll keep you posted.
      • gloosx 3y ago
        Ha, took me two minutes to make that code sandbox. Can you tell me at least if it is possible in Nue to create something functional like this and how? Or is it just a bunch of macro with some weird imperatives inside usual XML syntax? I really want to see 4 lines of code doing the same thing 2x faster :D
• deleted 3y ago
  [deleted]
• Dave3of5 3y ago
  I think you want the getting started to be the first thing people see on your homepage. Like instead of that thing which is showing you size difference put a snippet to show how easy it is to make a hello world app then a link to click to take them to a TODO style app. I know some devs do care about bundle size but most f/e devs I've worked with don't really care about that. They care more about their Dev Experience so you should be showing them how it's the same or better with your new tool.
  • rco8786 3y ago
    Yes, thank you. Scrolled the whole thing looking for the Hello World only to be disappointed
  • tipiirai 3y ago
    Here's Todo MVC made with Nue js: https://nuejs.org/todomvc/ https://nuejs.org/todomvc/ Source code: https://github.com/nuejs/www/blob/master/todomvc/todo-compact.nue https://github.com/nuejs/www/blob/master/todomvc/todo-compac... More details to come
    • deleted 3y ago
      [deleted]
  • progx 3y ago
    That is true, the first thing i ask myself when i read "Frontend Troublesolver - Nue is a powerful React, Vue, Next.js, Vite, and Astro alternative. It might change the way you develop for the web forever." ... was, how? And then came a code size comparison, this example is ok, but display it later, show first a simple example in which way it change it, e.g. a small code snippet? How does Nue look?
    • hahn-kev 3y ago
      It looks like Svelte honestly. I'm really trying to figure out how it's all that much different
    • 3y ago
• mattlondon 3y ago
  Nice to see that the react approach of mixing html and JavaScript in one file is missing. Hurrah! Please now provide a way avoid the need for npm and we can really start to move away from the dumpster fire that is react + npm.
  • deleted 3y ago
    [deleted]
• deleted 3y ago
  [deleted]
• zarzavat 3y ago
  Thank for for sticking up for external stylesheets. When I was starting out with HTML, inline styles were considered to be a hack, and the goal of writing good HTML was to separate the data from the presentation as completely as possible. It seems that nowadays people place more emphasis on encapsulation rather than separation, they want their style to live with the component. Separation and encapsulation are in opposition: vertical vs horizontal architecture of code. Personally I prefer separation. While components are a good way to divide up functionality, when it comes to presentation users are perceiving the UI of your entire website, not the individual UIs of each component. Separating the style into a stylesheet gives you global control over presentation and makes you more aligned with how the user is perceiving things.
  • sonnhy 3y ago
    > Separating the style into a stylesheet gives you global control over presentation and makes you more aligned with how the user is perceiving things. Can you elaborate on this? Do you mean that the separation through external stylesheets creates a more cohesive UI for the user? The HTML has its say on layout part, so the presentation is not exclusively on the CSS. Also, the core part of defining the whole UI is usually delegated to some global CSS rules, usually known as the theme in CSS-in-JS libraries. I don't think having external stylesheet helps that much.
  • shrimpx 3y ago
    Separation also has drawbacks. You have to go to open a different file and search for things by ID or class name. It’s like aspect oriented programming.
    • niutech 3y ago
      In almost every IDE you can open two files in a split view and you can ctrl-click on an ID to go to the definition.
      • Kiro 3y ago
        That's not good enough. I want to look at a tag and immediately see how it's styled. No cascading or hidden/indirect styling. It should be all there, completely isolated from the rest. In fact, I should be able to copy/paste just the HTML (or component) into a completely different application and it should remain exactly the same.
• montroser 3y ago
  It's a little bit of a stretch to call this "reactive": > The component re-renders itself automatically after calling an event handler, but you need to call this manually if there is no clear interaction to be detected. It is a creative approach to shed reactivity and just re-render after calling an event handler, and in some applications it can even be preferable to manage your own updates. But generally this seems like it will be rough and not enough in practice. For very simple apps it might just work, but in rich interactive settings, it happens all the time that the whole point of interacting with one component is to affect the content in other components on the page. In those cases it can be a slog with this approach for the developer to have to manually keep track of which components need to be updated and traverse through and call update() in all the right places.
  • nine_k 3y ago
    A truly reactive Preact [1] is merely 3 kb of JS. OTOH the need for really simple bits of interactivity does occur in real life. If the htmx [2] approach does not cu it, a micro-library like this could. [1]: https://preactjs.com/ https://preactjs.com/ [2]: https://htmx.org/ https://htmx.org/
  • deleted 3y ago
    [deleted]
• iainmerrick 3y ago
  I don't like everything about this but the website is really good and clear. From the FAQ (https://nuejs.org/compare/faq.html https://nuejs.org/compare/faq.html): How is Nue 10 – 100× smaller? [...] No TypeScript: Nue embraces the dynamic typing in JavaScript I see the TypeScript backlash is in full swing! I personally think TypeScript is (mostly) great and is the only thing that makes JS development bearable. But it's always good to see alternatives.
  • deleted 3y ago
    [deleted]
  • JuanPosadas 3y ago
    Also removing Typescript doesn't actually make your final build smaller, in fact you need extra code to check your ducks before you quack them, else you have high risk of error.
  • bafe 3y ago
    Typescript is the only reason I (occasionally) do some front-end work. The backlash against static typing in an age where we can have very sophisticated static type systems with dynamic-like DX due to great type inference is really saddening. If we collectively embrace another generation of dynamic languages we will collectively set ourselves back another 10 years
• jwmoz 3y ago
  Another day another js framework.
  • quickthrower2 3y ago
    Feels like a welcome relief from a new LLM adjacent thing.
    • nsonha 3y ago
      no, the LLM is breaking new grounds everyday. FE frameworks are... doing templating in another syntax? Cool!!!
• sfc32 3y ago
  Another FE framework (sigh)
• quickthrower2 3y ago
  When do I reach for this instead of AlpineJS or HTMX? When the team is bigger?
  • niutech 3y ago
    HTMX is for AJAX-driven web apps, rather _hyperscript is closer to Nue. There is also Petite Vue which is similar to Nue and does not require a build step.
• idkwhoiam 3y ago
  It's an interesting project but the website is full of statements that range from strange to downright false. 1. The comparison to React's ListBox is unfair until you reach feature parity. 2. The "nue levels of speed" makes it look like Nue the tool beats the hell out of the competition but then in small text it says it's a comparison of the project home pages. Why would anyone care about the size of the project home page? 3. The whole section on Tailwind in the FAQ is just false.
  • deleted 3y ago
    [deleted]
• zooFox 3y ago
  Honest question from a back end developer. I have been using Java for a good decade now, and it solves all the business problems. Yes, we had an occasional Go/React threat (along JVM-based languages), but I have not seen it coming to a fruition. Java is mature, well supported and understood language that gets regular updates now. Some people don't like it, and that's okay. What makes JS frameworks so quick to change? Angular, AngularJS, Next, Vue, React, Nue to name the few... What's the urge to reinvent rather than evolve?
  • peoplefromibiza 3y ago
    > What's the urge to reinvent rather than evolve? young age of developers (average 25-34 years old.), who usually (not always of course) reinvent the wheel because they don't know the past and don't understand the tradeoffs. Also, it's a way to get attention in this economy of virtue signaling, nobody gives a sh*t if you write a new C++ library that sends rockets into space, it's C++, it's insecure, you should have used Rust.
  • deleted 3y ago
    [deleted]
  • drw85 3y ago
    It's mostly change for the sake of change. If you're not changing something, you're stuck. We went full circle a couple times already in the last 30 years, because when you keep turning with no sense of direction, you might end up where you came from.
  • deleted 3y ago
    [deleted]
  • gitgud 3y ago
    > What makes JS frameworks so quick to change? … What's the urge to reinvent rather than evolve? There’s a really low barrier to entry for creating and sharing JS packages. Basically, you can just create a free account on npm and run “npm publish” to make a library available globally for free. Updates are just as easy, and using packages is even easier. It’s this super low-friction of JS development that drives the ecosystem to constantly iterate. And it even allows solo developers - like ^ this one - to publish and share a new framework. I haven’t tried to publish packages for Java, Go, Python etc… but I would be very surprised if it’s as easy and unrestricted as npm…
• todotask 3y ago
  Curious if you are targeting at an extreme performance, your site still need to inline CSS on every page?
  • deleted 3y ago
    [deleted]
  • tipiirai 3y ago
    If you strive for extreme performance you must inline CSS to get the first viewport fully rendered after the first request has been made. The rest can come progressively.
• gigatexal 3y ago
  how do you plan to monetize?
  • deleted 3y ago
    [deleted]
• canadiantim 3y ago
  As someone who wants to use the minimal amount of JavaScript, are there graceful fallbacks for when JavaScript is disabled?
• Alifatisk 3y ago
  How does it perform compare to Qwikjs and Vue?
• Pete-Codes 3y ago
  Great name - can't tell if this a joke or not but I love it
• simonhamp 3y ago
  First of all, congrats for launching. It takes guts and a whole load of effort, I know that first-hand. And to make it to HN FP and deal with the ensuing onslaught of comments and feedback is no mean feat! I hope the next few days are insightful and fun and you can maintain a positive outlook about it all. I haven't looked in great depth yet at what you've made available so please take all of this with a pinch of salt, but I wanted to share my honest 5-minute scan-through braindump with you as if you were watching me do the review in person: - _Another_ front-end framework (le sigh) - tell me again how you're trying to fix burnout and fatigue 8] - Let's look at the source for the homepage: https://github.com/nuejs/www/blob/master/index.md https://github.com/nuejs/www/blob/master/index.md - Oh, this 'Nuemark' actually looks interesting! Is that available yet? No - Where's the word 'solver' here? It's not here, it's embedded in the CSS. OK :/ not sure if this is intending to be an example of how to do this properly... - That CSS looks... funky... like a Python developer from 2004 decided to come up with their own terse syntax - That's not going to play well with current tools. Plus, there MUST be a compilation step, so why choose to make the compiler do a load of work here every time? Saving a few keystrokes feels like very little benefit overall - The homepage claims that its own HTML, CSS and JS add up to under the "14K" limit (is that kB?) but according to my math (which has been known to be wrong at times) it comes in at 19kB - this is still great, but the content of the page is potentially misleading I am always open-minded about new tools and will do a thorough and fair review, but a part of the problem for me is the time I invest has to be worth it - like, if I switch, I'm going to use this tool A LOT As I say, this is just a braindump of a very quick review, so add salt to taste
  • tipiirai 3y ago
    I hear you. I'll try to convert you ¯\_(ツ)_/¯ in the upcoming months when I address your points with the new tools and code examples.
• ellis0n 3y ago
  Amazing! How can I deploy to Vercel, any instructions here? I want to use it for the home page of a new programming language ACPUL.
• CodeCompost 3y ago
  Couldn't you have come up with a better name? It's way too close to vue.js and will cause massive confusion.
  • franky47 3y ago
    I think we can go deeper. Free ideas for grabs: cue.js: WebAudioAPI framework based on a React render tree hue.js: Colour authoring and manipulation sue.js: Framework for terms & conditions with JSX legalese components We may rue.js the day when another framework follows this pattern.
• pictur 3y ago
  There don't seem to be many silver bullets. This is good. I don't think it can be a good alternative in its current form, but it is a good start.
• sergiosgc 3y ago
  After trying out and reviewing the code of https://shoelace.style/ https://shoelace.style/ I began asking the question: Do we still need libraries like Vue? Haven't native web components reached the point where we can let go of the component "polyfills" we've been using? This crossover is bound to happen, like it happened with jQuery. The question is when.
  • tambourine_man 3y ago
    If history repeats itself, it will never be as nice, like it happened with jQuery.
    • jadbox 3y ago
      Or how browsers were supposed to replace Flash with built-in standards.. that never really materialized the dream in practice for web media creators.
      • tambourine_man 3y ago
        The runtime was mostly replaced. The authoring tool is what's missing, IMO. I don't know how well a truly responsive design can be accomplished with visual tools only, to be fair.
  • herpdyderp 3y ago
    If you don't have to support IE (I'm sure some poor souls on here still have to), my opinions are: > Do we still need libraries like Vue? No > Haven't native web components reached the point where we can let go of the component "polyfills" we've been using? Yes
  • Uehreka 3y ago
    I don’t think the crossover is bound to happen. With Web Components the browsers went all-in on ideas about components that made sense in the early 2010s, but then couldn’t evolve them because they had already standardized. In practice most component libraries don’t use Web Components under the hood (yes, I know Angular does if you tell it to, in practice I’ve never seen anyone use this) and aren’t polyfills. The main framework that worked that way (Polymer) has been out of use for years.
• ckluis 3y ago
  hey @tipiirai - I'd love to chat with about the project
• mst 3y ago
  Have you looked at https://mobx-keystone.js.org/ https://mobx-keystone.js.org/ by any chance? I've been quite enjoying keystone + lit (or react if required) of late and at the very least it feels like solid prior art towards MVC stuff. Also https://mojojs.org/ https://mojojs.org/ for server side. (I'm not saying "use these" even if I quite enjoy using them myself, but they're my reference points for comparison here)
  • tipiirai 3y ago
    I'm looking at it right now: > mobx-keystone is a state container that combines the simplicity and ease of mutable data with the traceability of immutable data and the reactiveness and performance of observable data, all with a fully compatible TypeScript syntax. I'm too old to understand all this.
• btbuildem 3y ago
  > Prerequisites > Install Bun or Node Goodbye
• antoineMoPa 3y ago
  I wonder if this can get any traction, since it lacks the jsx/tsx syntax people love.
  • niutech 3y ago
    Not everybody loves JSX, I avoid it.
    • antoineMoPa 3y ago
      I thought the same before, but I realized JSX/TSX makes it much easier to build and refactor apps (especially when working with medium/large teams) since you can use usual JS constructs to build your dom elements and you don't have to learn a frameworks template semantics (loops, conditions, etc.). You also benefit from all the available js tooling (editor support for refactoring, linting, syntax highlighting, type checking, etc.). Lastly JSX eliminates the burden of switching between the framework's template syntax and regular JS/TS when refactoring code and moving logic around.
• lakomen 3y ago
  Obligatory xkcd link about there being 15 solutions to a problem and someone creating a 16th
• 65 3y ago
  I think you have a typo in your documentation here: https://nuejs.org/docs/nuejs/#html https://nuejs.org/docs/nuejs/#html > <p :if="desc">{ desc }</h3> should be <p :if="desc">{ desc }</p>
• ttfkam 3y ago
  I was honestly curious until I hit the listbox comparison. The implementations for competitors look purposefully verbose to make Nue look better. The Svelte one in particular could look substantially similar to Nue, but after adding multiple seemingly useless layers and type definitions on top to get the same effect. Once I saw that in the Svelte example, I couldn't help but wonder if the same applied to the others as well. It all seemed to me beyond simple marketing puffery and into uncharitable and misleading territory. And honestly: <select name="Cars" size="6" multiple="multiple"> <option>Mercedes <option>BMW <option>Jaguar <option>Lamborghini <option>Ferrari <option>Ford </select> Sometimes you need a custom skin all decked out to the nines, but real talk, most folks just need to use the plain old HTML, apply minimal CSS, and move on to the next task.
  • ttfkam 3y ago
    I'm realizing that someone is going to hop in and say, "But that's limited to just a line of text per option with no images or real formatting." And that's true. It's also true that's what most folks actually need in most cases. That said, another fast implementation using more markup is to have either a hidden radio button group (single selection) or bunch of hidden checkboxes (multiple selection) that are referenced by visible label tags for the rendered listbox. Doesn't break accessibility for screen readers and can even work without JS. Browsers can do so much out of the box without us constantly reinventing the listbox wheel.
  • dannyfritz07 3y ago
    The "React ListBox" is actually the code for Tailwind's headlessui. I honestly think the bloat in the React ListBox impl is an example to not use Tailwind's headlessui component and less an argument for why to use Nue.
  • deleted 3y ago
    [deleted]
• shantnutiwari 3y ago
  Some comments: 1. The page on server side rendering leads to a 404 https://nuejs.org/docs/nuejs/server-side-components.html https://nuejs.org/docs/nuejs/server-side-components.html 2. I hate JS projects that have a separate compile step-- preferring to just use the libraries directly (as a script import). Julia Evans also wrote about this some time ago. Im not sure if your library will work without a compile step? Can I just download a .js file and try it out without jumping thru npm install/build hoops?
  • deleted 3y ago
    [deleted]
• debarshri 3y ago
  Frameworks are winner takes it all in nature. I think react is kind of won the market at this point [1]. New frameworks have to wait for a disruption in the model of delivery. React, angular were insight because of SPA. When a new paradigm happens then a new framework will make sense I think. [1] https://medium.com/javascript-scene/top-javascript-frameworks-and-technology-2023-4e4a06d6be93 https://medium.com/javascript-scene/top-javascript-framework...
  • deleted 3y ago
    [deleted]
• ChrisChou 3y ago
  People always misunderstand what is make ReactJS special, if your framework not build UI with just JS/TS, you are not React alternative
• topoftheforts 3y ago
  This looks great! Nice work
• gmarvin 3y ago
  I loved the original Riot.js for the simplicity and readability of the code it let you write. Excited to see this focus on keeping things simple, small, and performant!
• SkyMarshal 3y ago
  Looks really interesting, especially the 3-way separation of concerns that include content writers as target users. I read some of the comments here, then read the linked “Why” page, and realized many comments are missing the point, fixating on less important points. I recommend you make the Why page the front page instead (merging the current front page graphics and video with it). Move your “Hello World” blurb to the blog instead. It doesn’t really say anything that Why and front pages don’t, and isn’t crucial front page content. Maybe also include some info on how it works under-the-hood. For example, given the small size I doubt it’s a virtual-dom based. Is it a compiler model like Svelte and Solidjs? Or something else?
• habosa 3y ago
  This looks really nice! I think Vue 2 is/was such an underrated framework. The reactivity stuff has a little too much magic (hard to debug) but the way of laying out single file components as just HTML, CSS, and a script is pretty magical.
• spyke112 3y ago
  Feels off to be putting a lot of presentation logic into new .nue files. Maybe I've just grown used to .tsx and Angular's LSP consuming html templates and giving me full intellisense, but I wouldn't trade that for a smaller bundle size. If I really wanted to optimize for bundle size, I'd probably just server side render tsx templates, or whatever built-in templating language my backend language has, eg. Razor for .NET. Nevertheless, I have to agree with the a lot of the other commenters, I would have loved a concrete example front and center, I have to chip into the chior of people dismissing the initial importance of bundle size. I'm also sure a big application written with this library will be able to balloon once you begin using dependencies not optimized for this library. Generally speaking it's my experience that a lot of frontend libraries unfortunately tend to crumple once the long tail has been reached.
  • tipiirai 3y ago
    > a lot of frontend libraries unfortunately tend to crumple once the long tail has been reached Example please. Which libraries are we talking about?
    • spyke112 3y ago
      I'll be honest, my postulate is based on 100% anecdata. But in my experience the least opinionated frameworks, tend to crumble the most. I've heard countless stories about React apps where you'll have to use loads of third party frameworks, where each one has the potential to stop being maintained. In the end I guess this boils down to risk management, some teams might prefer not having a single point of failure with the trade offs that the looser coupling comes with. In my own experience when encountering old Angular applications, there's been a straight forward migration path to the latest versions, that feature in it self is pure gold in my opinion.
• eviks 3y ago
  > Copywriters, marketers, and other non-technical people can use a human-friendly Nuemark syntax for content management. > *and* multi-page This isn't human-friendly, that would be no markup with some Bold button that converts a word to bold where a simple search for "and multi-page" isn't broken
• willio58 3y ago
  It's kind of funny at this point, I hear about Astro and I'm just about to try it out and then this comes along claiming huge speed increases. Web frameworks move so fast it's really worth just sitting out a few rounds of frameworks until you really need to make a move, or else you'll just be in refactor hell.
  • shepherdjerred 3y ago
    For what it's worth, Astro is excellent.
• evbogue 3y ago
  This reminds me a little of htmx, in addition to all of the other frameworks mentioned above. I'm still trying to figure out which JavaScript framework to settle in with for day to day development and I'll give this a spin -- perhaps it'll feel right.
• jstummbillig 3y ago
  Mostly what I take away from this is that marketing works on everyone.
• gsuuon 3y ago
  This looks like it could be interesting, but the code size comparisons seem really disingenuous. The level of engineering and features are not the same - one could easily write a react listbox component with far less code than the example. You also seem to be claiming all jsx is spaghetti, which is a super questionable claim. I'll chalk this up as a 'not for me', but my feedback would be to maybe improve the comparisons to be a bit more fair and to better substantiate the claim that nue's dx is superior.
  • tipiirai 3y ago
    Thanks. Will fix all that in the upcoming weeks. I'm claiming that mixing logic, content, layout, and styling is spaghetti.
    • gsuuon 3y ago
      I'd say it's more like a delicious lasagna, if anything. Good luck! Always nice to see different ways to do things, especially ones that take on very real front-end bloat. I used to check bundlephobia for every package. I'm playing around with LLM's in the browser now so that ship has sailed.
• a5hd 3y ago
  While this looks nice, their example listbox in nue vs react/vue seems misleading. https://nuejs.org/compare/component.html https://nuejs.org/compare/component.html Even just skimming through, the huge React version includes much more functionality, more accessible (aria attributes are only set on the React version, not on nue). But its always interesting to see these new projects and approaches pop up.
• JuanPosadas 3y ago
  Lots of good looking stuff here generally. The value proposition over Vue/React is obvious, but seems to be about the same as Svelte/SolidJS. Which leads us down to: > No TypeScript: Nue embraces the dynamic typing in JavaScript This is an instant nope for me for any serious projects. I'd expect any serious modern competitor to the status quo to be Typescript-first.
  • tipiirai 3y ago
    I assume you have chosen Vue as your go-to framework due to this reasoning? (React and Svelte are JavaScript)
    • JuanPosadas 3y ago
      I do Vue at work, Svelte and Solid JS at home.
• 2bornot2b 3y ago
  I like more single file component, where markup, logic and style is a single file like Svelte. So a component look as defined and styles can not collide. With svelte, it is possible to use "anonymous" classes. So in fact you do not use any classes, but svelte add auto-generate names. like... <div>{content}</div> <style>div { background: red;}</style>
• icemelt8 3y ago
  Trying to run it with bun, couldn't get hot reloading to work.
• deleted 3y ago
  [deleted]