This is a cross-post from my blog.
... to your browser like a concave lense will spread light rays. Keep this sentence in your mind and come back here after the post.
Yes... feel free to leave this post before even reading it, because this is the main pattern in nowadays tech arguments. Everything nowadays must be build with one of the top leading UI frameworks / libraries. There is a lot of hype around the major ones and it's clear why: Generating money with complexity. There are courses, videos, tutorials, workshops, conferences, podcasts, youtube channels and so on. People earn money to explain the concepts behind because there are some times so many that not every employee can follow up. It's okay for me that this industry exists, but I'm not okay with blindly following or advertising one golden approach which will lead to complexity in the wrong field. What I'm seeing a lot on the web platform is that people first choose the tool and afterwards adapting the problem they are facing to fit it.
I'm a person that is really into performance optimization and tries to get the most out of something. The funny thing is, that I ingored that deep motivation in me and was really surprised by the result at the end. I wanted to create something simple with just a few easy understandable concepts. The framework should be shipped with batteries, so that developers only need one dependency. It should be directly usable in modern browsers to allow prototyping in sandboxes. And the most important point was to just use the platform and keep a potential bundler build process as simple as possible.
I told you that I have a heart for performance on the web, so I set myself a goal to reach this in 1 KiB.
SPOILER: I missed the goal, but it's not far away.
Sometimes it's good to have an unrealistic goal because it forces you to think different and walk other ways. And isn't that exactly what I wanted to reach in the first place: Explorer new ideas to face a set of problems instead of blindly follow the mainstream.
Here are some key facts about concave
- Declarative - Components are powered by a ES6 template tag function to easily define templates
- Reactive - Components will be updated & re-rendered automatically by state changes
- Batteries included - State management & router are builtin without any dependencies
- Minimal - < 1.5 KiB minimized & gzipped dependency free ESM module
Let's start with a boring Hello World:
If you want a pure browser experience try out this CodeSandbox which uses just the native ES module.
pipe function in FP.
There are the following predefined factory functions which will return ready to use pipeline functions:
createStore>> creates a store pipeline function
createRouter>> creates a router pipeline function
createRenderer>> creates a renderer pipeline function
createComponent>> creates a component pipeline function
They will be composed with
createPipeline which returns a pipeline of functions. You can also compose pipelines with
createPipeline if you want. This could be interesting if you want to compose different parts of your application.
runPipeline you start your pipeline and the first action (state) will flow through the functions.
Through all of these composed functions, actions will be passed to control your application.
state action - when a component receive this action, it will check if it need to update itself and will trigger a render action on the pipeline if neccessary.
This simple concept results in:
- Unidirectional action flow >> time traveling & easy debugging
- Pure components >> predictive rendering results
- Single source of truth store >> only a state reducer can modify the state
Concave uses a really naive rendering approach internally. If a component uses a property that is stored in the state and this prop changes, then your whole component will be replaced by the new one. This sounds like a terrible idea doesn't it? The truth is for every example I build so far this was no problem, but I'm not a fool: This rendering approach will not scale well for real big applications with a lot of data exchange. This is okay because it's not build for that case. It's build for really fast boot up and small footprints on your asset budgets. Keep in mind that you don't have to think about why, why not, when and when not your UI will update. It's always the same behavior - naive, simple and working.
Valid use cases to try out concave:
- small to medium sized SPAs
- static SPAs (e.g. portfolios, blogs, side projects)
- Progressive Web Applications (PWAs)
- bootstraping a bigger sized web application
- small teams that can figure out their own architecture
Don't use concave:
- SPAs with a lot of reactive data
- applications with a lot of animations (re-rendering will trigger them eventually)
This post was a quick intro to concave. If you are interested in more details checkout the GitHub repository of concave where your find more information about internals.
I just started to build a portfolio of mine with concave, so feel free to check it out. I will fill more data soon, to have an idea of performance with concave.
For updates, follow-up posts or sarcastic Tweets follow me on Twitter!
Thanks for all who read the whole post till the end! It's my first post on dev.to so I will appreciate any feedback or comments :)