- cross-posted to:
- programming@programming.dev
- cross-posted to:
- programming@programming.dev
I’m creating a JavaScript UI framework for my own projects. It’s a learning journey and I’d like to share my progress.
I’ve written some blog posts about my progress so far:
- Functional Web Components - https://positive-intentions.com/blog/dim-functional-webcomponents
- Functional Todo App - https://positive-intentions.com/blog/dim-todo-list
- Async State Management - https://positive-intentions.com/blog/async-state-management
- Bottom-up Browser Storage - https://positive-intentions.com/blog/bottom-up-storage
Note: The UI framework is far from finished. I want to share progress to see if there are any outstanding issues I’m overlooking.
Ugh, please no. Please don’t paint UI-elements via JS, if you’re not forced to. It makes for a poor userexperience for most users, not to mention accessibility.
I spent a lot of time early in my career working on some UI component libraries that I ultimately deemed a failure. However, I learned a lot from that. I’ve found that as I’ve settled into a more senior dev role, it’s become harder for me to experiment.
What I’m trying to say is that best case, you come up with something cool, and worst case, you learn from your mistakes and apply what you learned to the next project!
Yeah, sure. But in case of a framework, people without that experience start using it wrong.
Yep. You should already know all the available tools at your disposal before embarking on creating something new. Then you’ll also know best practices and if it makes sense creating something new and how to approach it.
Thanks for input. I think it could still work without js-painting given that it’s using the customElement.define().
I’m aiming for something that looks and behaves like react, but without the overhead of the react tooling for transpiling.