Show HN: SingUI – compose modern front end with pure vanilla JavaScript
stackblitz.com
stackblitz.com
Sorry for mistaken "vanilla" for different meanings...
What I'm tring to do is making a "writable" solution with pure JavaScript, not needing to write a lot of `React.createElement` or something similar. I even got `attr` and `prop` proxied to the correct element when building, no need to extract them form arguments each time inside an element.
What's more, it's only less than 5kb without gzip.
So I read through the example, and I do get it, but I'm not a fan, but I also think you put a lot of thought into this in general.
If you want adoption, I think you need to focus on at least two things:
- Testing (part 1). Your library doesn't have tests, and was only pushed about 9 hours ago from the time of this comment. Developers don't have any way to trust that the library works the way they think it should.
- Testing (part 2). There is no obvious way to test code written with your library/framework. Developers won't be able to verify if their code is doing what they expect. I suspect you could have build return faked methods, but then how do you tell the build function that it should be in test mode?
2. Hyperapp actually does have some sort of compiling (at least parsing a string for a tag)
3. There're far more advanced usages that you may not aware of, so build function has no need to care about whether it's in test mode. More usage demos may come later.
4. I'm actually not a fan of writing redundant tests. IMO tests are more of a psychological comfort for users to see rather than a practical proof of robustness. Though it could gaurantee some sort of correctness, it won't cover how users want to use it. It's a waste of time to write a whole bunch of tests and run them every now and then.
5. I don't want to make this project "heavy", and I hate "heavy" projects.
In terms of hyperapp, that is as much compiling as `document.createElement("a")`, which is what your library does, too.
I'm not saying write redundant tests. Tests are more than just one person's psychological comfort. Another great example is if you are accepting PRs into a larger codebase, having tests means you know other people aren't breaking previously working parts of your app. Tests can also work as documentation, since a test describes how pieces of your app should work.
I'm confused why you think any of my suggestions imply that you should make your library heavy/larger/unmanageable.
In terms of "heavy", it's actually a problem with node's package management. Once I include test frameworks as dev dependencies, there's a high chance of installing my package will get the test framework together with it's whole bunch of dependencies installed as well - very unnecessary and time consuming.
Nothing should be stopping you from just making a test file, you don't _have_ to use a framework. NodeJS even comes bundled with https://nodejs.org/api/assert.html .
> Please enable 3rd party cookies or add an exception for stackblitz.io to resolve.
You know, I don't think I will.
The overall code composition is quite different if you take a closer look.