I've a client who has approached me for building an e-commerce website for his business.
His business is only medium-sized. So, the website won't be expecting huge traffic (at max, 100 concurrent users at a time).
I just wanted to know how production ready are Nim's web modules and web frameworks like Prologue, HappyX, Nexus, Mummy etc. for this?
I'm thinking of using Next.js/React for the front-end as Karax doesn't support (from what I've read) a component-based system (or does it)?
The frameworks and the language are fine but you'll have to write a lot of code yourself as the ecosystem is not as rich as it is for Python or Ruby or Go.
Karax allows component-based code organization but doesn't enforce it or offer a single right way to do it. I'm using Karkas for layouting, Kraut for routing, and Sauer for the code structuring. My shared state is just a module that's imported by all components that need it and my components are just procs that return VNodes. Works pretty good so far.
Prologue crashes in multithreaded mode. HappyX is a fullstack framework and has a lot of features and HTTP backends, so your mileage may vary. I can tell you that it will be limited by Nim's async ecosystem, which has many problems. Nexus I don't know.
I would recommend you use Mummy because it's already being used in production and doesn't have async Nim problems. It's also going to be simpler.
Stick with React for your frontend and use TypeScript with it. You'll move faster with all the tools available to you. Nim's JS output is massive and slow, and it doesn't have any good tools for debugging.
If you're planning on using Next.is, you may as well do that if you're not expecting to have to scale a bunch. Next is a fullstack framework, so it'll handle backend for you if you want.
Unfortunately, Nim's web ecosystem is pretty poor, and the only things in it that I recommend in good conscience are Mummy and Gildenstern, both non-async threaded webservers.
Oh, I didn't know that Nim's async system has problems...
On the Wordpress front, I'm not that familiar with the ecosystem except for managing some content for some WP sites and also doing some config on servers for hosting the same. I'm primarily from a JavaScript background. I could go for the MERN stack as I'm familiar with it.
I really wanted to try Nim in production having been really enamored with the language (I know, some people say its unwise).
Nim's JS output is massive and slow, ...
Nope, it's fine.
and it doesn't have any good tools for debugging.
Fair I guess.
Firstly, it depends on how adventurous your customer is. There will always be a problem with Nim, whether it's Async causing problems or Prologue falling over as soon as you look at it at an angle. If your customer is willing to go along with this, you can use Nim. If not, don't do it. This saves you and your customer stress.
Wordpress, Woocommerce: Ugh, please don't. Yes, with Wordpress and WooCommerce you can quickly create a site, but don't underestimate the maintenance required. You must always keep an eye on Wordpress, as it has many security vulnerabilities. WooCommerce is always slower and not nice to use.
You could go for Shopware if it's going to be a pure shop or you could consider equipping an existing website with just a shopping basket. With NodeJS, Typescript etc. you can go a long way and have a large selection of ready-made libraries and frameworks.
This is the size of my karax SPA compiled with -d:release before and after minifying with esbuild.
❯ du -h src/app.js site/app.js
516K src/app.js
264K site/app.js
Is this concerning? Seems reasonable to me but I'm not familiar with bundle sizes that come from typical JS frameworks.
does it compress further with "gzip -9 -k app.js"?
I guess it just depends on your use case and target audience. JS frameworks like to brag about their small sizes for mobile, limited bandwidth users, initial load time, or whatever the issues are, though i see some have removed those sizes from their home pages. Maybe they are getting fatter. :) Whether any of that matters is another matter. :) If you're building an application for users with decent internet and not so much for underdeveloped or far-flung infrastructure, than it may not be any concern to you at all.
I'm mainly just curious about why it's "so large", what the performance is like compared to other frameworks, and what the official line on these perceived/possible issues is.
solid.js 7kb minified and gzipped vuejs says it's 16-27kb
The following commands:
nim js -d:release src/app.nim -o:app.js
npx esbuild --minify --bundle app.js --outfile=app.bundle.js
gzip -9 -k app.bundle.js
Result in:
208K app.bundle.js
44K app.bundle.js.gz
516K app.js
For reference this is for the nimpkgs
Just curious: do those apps have (large) user file uploads?
That is a problem using the Jester+Httpbeast with many requests. In the early days, I used the nginx upload_pass to receive the files in a tmp-folder and then combine them. However, it didn't make sense to store and manage all the files and backups on the webserver. So, everything is moved to external object stores (e.g. S3).
I haven't tested file management with mummy.
I don't know about performance, but this issue with bundle size has been brought up before, and I'm curious what your position on this criticism/point actually is.
My position is that the produced code size is just fine. Sometimes you can optimize it by using JS's native dict datatype as opposed to Nim's which produces generic specializations. Maybe Nim tends to produce a 70KB file whereas Fad-of-the-month only produces 22KB. You know who actually notices this difference in reality? Absolutely nobody.
Is it because the browser will cache the js, so you don't see the size as a practical issue for a web application/SPA? Something else?
The caching helps but it does not matter: https://www.keycdn.com/support/the-growth-of-web-page-size#web-page-sizes-are-quickly-increasing