Fidgets!

> Though I'm trying to figure out how to keep a key aspect of Fidget which is > simplicity and customizability. Widgets usually mean limited configuration > points. I believe Nim + Fidget gives some unique paths to getting the best of > both worlds. > > the list of widgets is pretty standard. y

Fidgets!

> I would say a complete set of widgets is what's most missing for a Nim gui > toolkit. (in other words, if you can put style and performance for later, > it's a benefit in my opinion) Agreed! I'm tweaking Fidget only on the OpenGL backend because I figure HTML5/Metal/etc backends can be made l

Hello Javascript!

I haven't tried it, but maybe you'll get a smaller output with this library.

Nim 1.6.6 released

Uploaded new Docker images to Docker Hub. Sorry about the delay.

Fidgets!

I would say a complete set of widgets is what's most missing for a Nim gui toolkit. the list of widgets is pretty standard. you can look at winforms, wxwidgets, or fox-toolkit, gtk, qt etc. For layout, I would argue that it's worth checking out what flutter did.

Fidgets!

I think seven years of sticking around here absolves me from your pettiness, thanks for trying though.

Why I left the Nim community

All I have to say is <3.

Hello Javascript!

The `Math.trunc` is removed in devel already.

Hello Javascript!

There's also another reason which might be beneficial to someone - C++ exceptions, but this is much more rare. And yet another one is stricter type checking by the C++ compiler.

Hello Javascript!

The (only) reason to use the C++ backend is to interop with an existing C++ library/framework/codebase.

Why I left the Nim community

So many replies, pardon me for cherry-picking. @archnim > I think that you shouldn't abandon the community. We are here for Nim. We are hobbyists, Nim is for most of us a pastime, if it becomes a chore why should we spend our limited energy after work and family on it. So the question becomes,

Fidgets!

Didn't you left?

Best practices for porting huge C projects to Nim

You just do it? Porting code from any language to another requires you know the source language and the target language. There is no "ez" button here... If you don't want to port, and the game engine is extensible via plugins, you could write Nim plugins and go that route. If that's not the case

Hello Javascript!

Nobody asked for my opinion, but here it is nonetheless :-) I really like coding frontend in Nim with Karax. It's light and simple, I can use whatever component structure I want, editor support is really good, and I get all the benefits on Nim: readability, types, flexible syntax.

Hello Javascript!

I wonder why anything — even an empty file — gets this added even with `-d:release`: /* Generated by the Nim Compiler v1.6.6 */ var framePtr = null; var excHandler = 0; var lastJSError = null; if (!Math.trunc) { Math.trunc = function(v) { v = +v;

Hello Javascript!

An issue I've wanted to fix was native support for `svg` in SPA mode, because SSR should work fine. Unfortunately after multiple attempts by a couple of people, I don't think it's possible. However it's not a blocker for me, I like using karax, especially with tailwind CSS. The tailwind "compil

Hello Javascript!

Any ideas to improve JS (without compiler changes) are welcomed at We got stuff like classes websockets dotenv

Hello Javascript!

While `-d:nodejs` enables the console — it disables DOM: import std/dom document.body.innerText = "Nim" # Uncaught TypeError: document_603981172[0].body is null Run

Hello Javascript!

Thank you. This question is off topic, regarding the current thread. But since we are talking about the compiler, is there any particular reason to use the cpp backend ? In my tests, cpp produces bigger and slower executables.

Hello Javascript!

It's not default because it's made specifically for native backends (C/C++/ObjC) and is used when you want your binary size to be as small as possible, sacrificing some performance in return. With `-d:release` and `-d:danger` `--opt:speed` is used, which maximizes speed. But for things like emb

Hello Javascript!

Hello world. concerning `--opt:size`, does it have any impact on performance ? Is it a good habit to use it ? If it is, then why isn't it a default option ?

Hello Javascript!

There's really not a problem with performance. I have multiple private game projects that compile to both SDL and JS canvas backends and they run at full speed. Other stuff I've written like parsers also run pretty well on JS.

Hello Javascript!

import std/jsconsole console.log "Helo, World" Run compiled with `nim js -d:release -d:nodejs jstest.nim` results in /* Generated by the Nim Compiler v1.6.6 */ var framePtr = null; var excHandler = 0; var lastJSError = null; console.log("He

Why I left the Nim community

I'd address that feedback to Dom - I'm not the one claiming I'm helping to run a PL community and develop a language (as second in charge), while actually doing way less than other contributors (for a while now) and still involving myself in every decision making process and gate-keeping others

Why I left the Nim community

You've literally been around less than a year - how can you claim that I see too much negative in Nim when my experience with the community and language is over 7x yours? I'm not even discussing language features or semantics here - and I have no problem writing multi-threaded code with Nim (<

Hello Javascript!

Honestly I can't give much advice on Nim's JS backend as I don't really use it myself, maybe others can share their experience. Regarding performance - you can measure how Nimforum works for you, since it uses Karax (SPA framework for Nim JS backend) on the frontend.

Hello Javascript!

Huge thanks, @Yardanico, you are both knowledgeable and kind! May I ask your personal opinion on using Nim for client-side DOM JS? I mostly do own performant vanilla with occasional small modules, e.g. Sortable, etc — and interested in expert opinions before diving in. Any caveats / gotchas that

Hello Javascript!

You can use cstring and wrapped console.log. Since that's just debug output size hardly matters, but it's a good practice to use cstring over string for js.

Hello Javascript!

For example, after compiling the JS code with `-d:danger` and running: closure-compiler --compilation_level ADVANCED_OPTIMIZATIONS --js tt.js --js_output_file ttopt.js Run I get this: var k=0;function l(g){var f=Array(g);for(var a=0;an;++n)m[n]="Hello, W

Hello Javascript!

This is normal, as Nim is a compiler, so it treats JS like a proper backend. You can try `-d:danger` for smaller code, `--opt:size` is a no-op for JS. For bigger optimizations check out , but it's really only useful if you can find externs for all th

Hello Javascript!

The following is `echo "Hello world"` in `js -d:release --opt:size`. Is there anything that can be done about it? /* Generated by the Nim Compiler v1.6.6 */ var framePtr = null; var excHandler = 0; var lastJSError = null; function toJSStr(s_33556807) {

Why I left the Nim community

A lot of this sounds like burn out. Sometimes its best to step away for a while, or minimize your time on a project when this happens. In a year you may feel differently.

Why I left the Nim community

Not "every" developer "will eventually run into exhaustion", and I doubt most people consider reasons you outlined as a major issue. For example, I'm having troubles understanding why do you think this trumps other reasons.

Why I left the Nim community

You see too much negative on Nim The most unsatisfacts on Nim for me is that it hardly to develop multi-threaded asyncio server side program, the async dispatcher is single-threaded or easier to muti-threaded on Linux not windows. here is what my way to deal with it, I use Golang with Nim to ac