The JS ecosystem is a mess - I'm sure many of us will agree regarding that sentiment.
I'd like to gather thoughts about Nim's current FE web libraries and if we think we should expand upon them further...
Most people, who have built a website in the past half-decade are familiar with react and angular. Not to lump all FE web libraries into one category - but these libraries tend to rely on an implementation of a Virtual DOM and then an algorithm to diff between the virtual DOM and the actual DOM. The reason this is done in the first place, is to help eliminate inconsistencies between app state and ui state.
More recently, a few libraries have emerged - https://github.com/WebReflection/hyperHTML and https://github.com/Polymer/lit-html
These libraries are focused on the web component specs, which if you're not familiar with, are a different beast all together - https://www.webcomponents.org/specs
React and web components are not 1:1 - for instance, web components don't offer a solution to application state management or even local component state - in fact they don't define components, they define custom HTML elements. Still - you can build upon these specs to define your own custom elements, and then add glue to a state management library like redux or mobx or what have you...
I guess the question being asked here is -
Is Karax sufficient? Would it be better if it was extended to support template literals so that you could take advantage of some of the performance benefits purported by hyperHTML / lit-html?
Does anyone care?
I recently came to Nim because of the amazing JS backend. My 2c:
The JS backend is really powerful, but it needs a bit of modernization to continue to attract more people to the Nim ecosystem.
I've been frustrated a time or two about lack of ES6 module support. It would be delightful to be able to use features like Web Components (and dozens of others) without having to write JS shims or Nim macros.
Karax is really fun, and very inviting. The Nim Forum software is a solid example of a fully functional app in Karax. However, there doesn't seem to be a way to just clone it and run. There are incompatibilities with the latest Nim release and the forum code, the Nim version specified in the nimble config doesn't exist. IMHO the forum software should be kept up to date with the latest nim releases, because it's the largest codebase representative of how to do Nim on both frontend and backend.
Finally, WASM should be prioritized as a target. So many possibilities for apps with Nim backend, nim/js frontend glue, and nim/wasm frontend. Nim should catch this wave while it's still cresting!
Ramblings from a nim-n00b.
Is Karax sufficient? Would it be better if it was extended to support template literals so that you could take advantage of some of the performance benefits purported by hyperHTML / lit-html?
So here are my thoughts: I am perfectly happy with Karax. It's not perfect and there are certainly many edges that need to be sharpened, but it's a great framework. Because of this I am a bit sceptical about starting from scratch, I would much rather we all poured our effort into Karax.
I actually learned React at Facebook and used it there before working with Karax, and I was amazed by how well Karax worked. For someone who I don't consider to be a web dev, Araq has done a terrific job.
I think we need to do a better job of advertising Karax because working with it really does feel pretty revolutionary. I can see for example the Rust community gearing up for an SPA with the advent of packages like typed-html, I think we're already there and people just don't know about it because we lack the big sponsorship and shiny websites. Perhaps I give too much importance to those though, maybe @bketelsen can give his thoughts about this as well (awesome to have you here btw!), I'm guessing he's got some great insight into how Golang's marketing worked :)
I do agree 100% that the NimForum should be easy to compile and run. I did my very best to ensure this would be the case, unfortunately things have moved rather quickly recently in Nim land and this caused multiple conscious changes that broke backwards compatibility. I don't really have much time these days to be fixing such things (to be honest, I'd rather spend time doing something else, like implementing Nimble features) so things remain broken. Hopefully someone will step in or I will eventually fix it though :)
I'm happy to put my money where my mouth is and clone karax+dependencies at master and work through PR's to get everything up to current. I will have questions, but I'm sure there will be plenty of people willing to answer.
I agree that Karax deserves far more attention. I'll put some thought into how to make that happen.
What's a FE lib?
Did you, just as I did, thought this might be about Finite Elements? :)
After I've read the whole thread, I'm guessing it means Front End.
In the process of learning more Nim I whipped this up last night:
https://github.com/bketelsen/blog
Served on netlify at:
https://loving-albattani-9f17d6.netlify.com/
I had one major issue... none of the yaml or markdown parsers worked with nim's JS backend. So my yaml frontmatter is parsed as key/value pairs (probably poorly too) and I parse the markdown in javascript. WOW the .importc pragma is amazing for doing things like that. just wow.
Any constructive criticism or advice on the code so far would be welcomed, I'd much rather start with good habits than bad!
Awesome start :O
I had one major issue... none of the yaml or markdown parsers worked with nim's JS backend. So my yaml frontmatter is parsed as key/value pairs (probably poorly too) and I parse the markdown in javascript.
What you could do is extend the markdown packages to either:
This is how the stdlib json module works for example :)
WOW the .importc pragma is amazing for doing things like that. just wow.
:D
The Nim Forum software is a solid example of a fully functional app in Karax.
I wouldn't call it "a solid example of a fully functional app" until threads can be archived (ex. archive.org, archive.today) or scraped by standard search engines (ex. ddg).
It is, sadly, an example of how modern in-browser apps can be a step backwards in utility, accessibility, flexibility, etc.
I don't enjoy being a contrarian - it's a duty...