Nim is uniquely positioned for making a specific killer app: a reactive full stack framework.
The web world is converging on fine grained reactivity (React for not so fine grained reactivity, SolidJS and Svelte for proper fine grained reactivity), and we're seeing similar patterns come up in other languages (Leptos in Rust is a great example). But each of these have shortcomings that Nim can address nicely:
In Nim, we could:
There are real, ready frameworks in Nim that let you do this.
IIRC This forum is written is Jester and Karax. Jester acts as the backend whilst Karax acts as the frontend. But a better framework would be happyx
I haven't tried Jester+Karax or HappyX but they both seem really nice. Anyway, this idea has already been realized and implemented.
On topic: Checkout HappyX
As an aside out of curiosity, how do you hope people receive your message when you present yourself as "throwaway567843"?
I'm familiar with Jester and Karax - I built a few internal tools at $DAY_JOB using Jester. Karax never really clicked for me sadly, but the DOM manipulation sublibrary it has is nice. But honestly I've been trying to move stuff over to mummy (https://github.com/guzba/mummy) which I think is currently the best webserver in Nim.
I haven't directly used HappyX though I've been following it, and while I think it is doing some great stuff and I'd love to see it evolve, I think it is trying to "catch up" to other web frameworks, but do it in Nim, instead of being the 10x improvement that will get people to switch from their existing tools to Nim.
The reason I made this post is because I just spent some time over the last few days getting to know Leptos in Rust, and I felt like I could see the vision for how it could become a next generation web framework. But the more I thought about it, the more I felt that Nim is in a better position to get us there, rather than Rust. Hence this post.
I think the existing Nim story on the backend is serviceable, but the frontend story is limited to Karax (which I know was made by Araq) but doesn't have signals or the nice server function abstractions that Leptos has.
Pardon the rambling
Totally fair question about the throwaway account: I'm hoping that the discussion focuses on the idea presented and the merits therein. People could comment in agreement/disagreement, or let me know about something I've potentially missed.
This post isn't a request for anyone to do anything.
Javascript based frameworks have relatively weak typing systems, as even Typescript will allow you to do unsound things with types
Not true. TS allows you to abandon safety of types, and use unsafe practices, but it's your choice, not TS problem.
that hide all of the transport layer complexity
I actually did such framework in Nim https://www.youtube.com/watch?v=vjj0mZOh5h4
Javascript based frameworks are poor choices to run server side, as they are relatively less efficient (though certainly good enough these days even for server side stuff)
Not true at all. JS on the server is excellent choice for 99% of web apps, as most of them are IO bound, not CPU bound. And things like node.js which is basically a very efficient IO router, is excellent choice for that task.
And - there are bigger issues.
Web Dev (and also App Dev) is kinda in decline, there are much less money in the space than it were before. And the whole programming also in decline. It's like wired telephony, or Nokia before its fall.
The golden age of modern day programming is gone. In the following years there will be more and more layoffs from all the companies around the world.
Programmers will be replaced like old day peasants. Now a single farmer with tractor - does the job of 100 peasants. Same will happen with programmers and AI.
Kill app or no kill app, it doesn't matter anymore.
I'm not sure the projection was really needed, seems like following this mass-layoff no-code logic into future is a real stretch that is based on one absurd assumption; "Hallucination is just a bug to be squashed not a fundamental multi-computational(Wolfram term) ambiguity"
There's absolutely room for a AI first OS, but 50 bucks says it'll be Unix based, 100 bucks says it'll be largely hand coded and will still have a command terminal that is not in natural language.
If you want to really extrapolate; Nvidia chips are already partly designed by "AI", at some point hardware instruction sets are going to become unintelligible(see irreducible) to their functionality... This will have pros in efficiency but still retain the cons.
Unix, and C have legs for hundreds of years to come from their inherent simplicity, if you cannot see this, then sure your job as a mere scribe will be replaced by more actual architectural writers that care about composing orders of operations not just slapping async on every function and letting the AI chip make some graph out of this.
Unix, and C have legs for hundreds of years to come
Good luck :). I'm sure that "composing orders of operations" and similar highly intellectual tasks, won't be solved by AI any time soon :).
Thanks for taking the time to reply, and I hope HappyX is able to keep growing!
Here are some examples of the unsoundness in Typescript I was talking about:
I agree Typescript is a huge improvement over vanilla JS, but it is still very easy to accidentally shoot yourself in the foot.
Could you comment a bit more on the issues Nim has on the server? I agree async can be a bit painful to work with (especially around stack traces), but I've found using mummy and subprocesses has been nice to work with. Additionally, the gcsafety that the compiler checks is a fantastic help. And I think Nim does isolation quite well with Araq's https://github.com/nim-lang/threading, but I'd be curious to hear your experiences.
I agree with your overall point and I posted something similar in this forum a while back. I too am using multi-threaded web servers with nim after trying many of the older async frameworks and servers. Mummy is pretty nice, but considers streaming large file uploads out-of-scope. It has multipart support, but it also loads the whole upload into ram. I'm currently using Guildenstern (and sqliteral by the same author) for my current web project and that dev is currently beavering away(? :smiley:) at implementing streaming multipart form-data. I think Guildenstern could be a good base for such a proposed framework. It has a Websocket server too, which might come in handy for such a project.
https://github.com/olliNiinivaara/GuildenStern
p.s. i like using Nim Source Code Filters for my NSX and "templating language". I have js, html, and nim all in the same file. It's pretty cool.