How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Morning, so lets break this down, firstly I want to disclose that I am not always correct but I am trying to present an alternative way of working which I have used and enjoyed, anyone who hasn't tried the library, give it a whirl then come back to me so we can make it better. There are 11 issues to work on, also I have put my own time into this, I believe in this and I think its worth pursuing. I don't expect the points to be liked by everyone nor understood without the documentation and proofs as I say in the readme. I could use contributors who want to explore this.
Its very hard to get a library off the ground and I see a lot of negativity towards different ideas which makes me a bit sad.
I view this as adding bunch of third party code as a possible solution to a bad practice instead on working well.
A bunch is a strong word, re.css is a 0 dependency library which using nothing that your browser doesn't already ship, it weighs 71.9 kB because it ships both CJS and ESM so you can cut that figure in half, its really quite small, you don't have to use the library, its just a nice interface intuitive (I hope).
If you already mapped your CSS properly you already have the properties and values that points to elements and states; most of them can be handled with plain CSS and others could require js to add or remove a class.
re.css is already plain css, there is nothing un-vanilla about it css will soon be able to register @properties as the lines become increasingly blurred. I state explicitly in the readme that you probably should declare variables before any component loads, you should do this via stylesheets. Classes could be used as mixins and I really didn't say anything against using classes with variables attached. But equally you have more granular control styling variables directly which is nice, more control.
This last action does not modify the CSSOM and does not force an entire sequence of render-painting (when removing) or isolates the new element styling to render it fast (when adding) and re-painting the entire tree (don't mind how this plan to avoid that).
The CSSOM existed before the low level API's perhaps I am mislabeling it. To put it another way There is a css parsing and computing engine in any browser, for instance this would probably lead off to some c++ code to do such parsing and computing work, by making any changes such as adding a class, lets just say, you are doing work which causes a repaint.
But that is not what I had in mind for a theoretical performance improvement, adding a class in the DOM vs updating a css variable, I dont know which should be a little faster yet, I suspect its variables given that this is the single place you would edit. I know that I need to run perf tests before I can proove or disproove my point, and thats what I have been working on, adding E2E and perf.
For the CSSOM I wanted to add support for this developer.mozilla.org/en-US/docs/W...
Brining true immutability, custom typed syntaxes and other nice things that you cannot achieve any other way.
Houdini is going to be big and that is an advantage to using this technique, you already have your values ready to feed into a paint work-let for example.
Also transpiling scss to css on the fly for getting dynamic values into properties is a bad practice for performance and there's no reason for that, Sass have the potential for managing it easy on development time and you can manage a "dark theme" by simply transpiling two versions of your Sass with a single variable change, then checking a cookie with user preferences and dealing one stylesheet or another (or a tree of them inside a directory) for example.
As I said, "Also transpiling scss to css on the fly for getting dynamic values into properties is a bad practice for performance and there's no reason for that", umm yeah thats right, not mentioned anywhere in the post, I mentioned building up variables with mixins. --my-var: $my-var;. This isn't bad anything.
"dark theme" by simply transpiling two versions of your Sass with a single variable change, then checking a cookie with user preferences and dealing one stylesheet or another (or a tree of them inside a directory) for example.
Yeah a dark theme is a pretty contrived example yet understandable use case, it is not the only use case and sure you could build the file, Im not arguing with that. Here is a good use case I have a three.js model that needs to be styled with the same colours as the css in my design, I need to changing the lighting of the model and sync up the animations, The model is a watch, with lume hands, when it goes dark, the lume should light up. Now in this case getting the css properties controlling such things as animation timing and current color, and using them in the css and also within the canvas, thats trivial, updating the styling is also trivial.
The tests I did with react, preact, angular and plain js lead me to use well structured and scoped scss (transpiled in the deploy process) and loading it across the component (usually those frameworks do this by default, just pointing it in case of plain js).
This sounds like you tested my library? Anyways yes building scope into a template is great but its still going to be evaluated at run time so I think we are still equal apart from, I have less overhead, the document from re.css would be lighter.
Also and following for performance concers, taking advantage of HTML states (CSS Pseudos) instead on using JS for anything related with styling help a lot (accordions, modal windows, form inputs instant feedback, tabs...) All done using CSS only (Sass on dev time).
I don't follow :/ sorry, I really tried but I dont, just try the library and tell me how you would work with it.
I didn't catch the point where this re css can help to anything but I'm interested on knowing further details, could you please add more detailed information about what is intended for, with use cases and examples?
Ouch, okay, I feel it has plenty of uses and I think you might have some misconceptions about what Im saying perhaps because this post is light hearted and less technical. The readme is more detailed, the issues are more telling and the docs / style-guide are on their way! I hope you follow along and stay skeptical, I really need opinions like yours.
I would like to see if there's a way on getting the best performance or if this solves an issue I'm not noticing at this point (I'm sleepy at the sofa to be honest and it's quite possible 😅)
We were both tired, I promise, the library probably does something but Im not in a position to proove it yet.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
"I think you might have some misconceptions about what Im saying" yes, totally agree 😂
I didn't tried your lib yet, i was only trying to figure out why I should need it. I think I understand better ehat you are talking about specially referencing to Houdini, I'll take a look at it when possible (I'm hands on various projects so I've not much time left).
I'm working through performance as first need with my colleagues since some months ago and I'll try to check your source code and make some tests.
The tests we already did was using some libs like Material vs custom styling and inside custom styling we tried some different methodologies to achieve the best performance possible, meaning to deal as few weight as possible to the client and getting as few execution timings and resources wasting. With this in mind, Preact is better than React or Angular, also svelte has a nice way to work from my POV, hope it and it's community grows more for being able to present Svelte demo as valid
framework for a long term application on production (as it manages DOM instead on generating and comparing virtual DOMs the resources needed are way less).
By the other hand I couldn't find a better way to style the Apps than using CSS for all the possible use cases, this is what you said you don't follow, no problem, take a look at my profile and find some articles about "CSS only interactive components". I use :target pseudo for showing/closing modal windows, :checked for dealing with tabs and accordions etc instead on using JavaScript for that.
This permits quick user interactions as the CSS is pre-rendered, no re-rendering nor re-painting here.
At this point you must note that avoiding JS is the key for performance, CSS is loads faster to load and execute and it's API growth well those years, I hope it will grow more on the following for this reasons. Then of course you need some kind of strict pattern and architecture design into your stylesheets to avoid common issues (need for overrides, proper inheritance and so); a mix of BEM methodology with some modifications is what I found better to balance a clean development with a good performance (I'll write a post about in the following days).
I'm a little skeptical about adding libs because we managed to generate a production preact App which uses a custom css framework created by my own with preact components and custom styling that weights less than 400Kb in total; adding a lib which weights 75kb + is a huge percentile weight addition.
Anyway as I said I'll take a look for sure and try to figure out the use cases and thinking about this out of the box objectively (if you already tested it for specific use cases on which you know it helps, please tell me to reproduce it on my tests).
I'll read the readme and the info you linked tomorrow as late 😁
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Morning, so lets break this down, firstly I want to disclose that I am not always correct but I am trying to present an alternative way of working which I have used and enjoyed, anyone who hasn't tried the library, give it a whirl then come back to me so we can make it better. There are 11 issues to work on, also I have put my own time into this, I believe in this and I think its worth pursuing. I don't expect the points to be liked by everyone nor understood without the documentation and proofs as I say in the readme. I could use contributors who want to explore this.
Its very hard to get a library off the ground and I see a lot of negativity towards different ideas which makes me a bit sad.
A bunch is a strong word, re.css is a 0 dependency library which using nothing that your browser doesn't already ship, it weighs 71.9 kB because it ships both CJS and ESM so you can cut that figure in half, its really quite small, you don't have to use the library, its just a nice interface intuitive (I hope).
re.css is already plain css, there is nothing un-vanilla about it css will soon be able to register @properties as the lines become increasingly blurred. I state explicitly in the readme that you probably should declare variables before any component loads, you should do this via stylesheets. Classes could be used as mixins and I really didn't say anything against using classes with variables attached. But equally you have more granular control styling variables directly which is nice, more control.
The CSSOM existed before the low level API's perhaps I am mislabeling it. To put it another way There is a css parsing and computing engine in any browser, for instance this would probably lead off to some c++ code to do such parsing and computing work, by making any changes such as adding a class, lets just say, you are doing work which causes a repaint.
But that is not what I had in mind for a theoretical performance improvement, adding a class in the DOM vs updating a css variable, I dont know which should be a little faster yet, I suspect its variables given that this is the single place you would edit. I know that I need to run perf tests before I can proove or disproove my point, and thats what I have been working on, adding E2E and perf.
For the CSSOM I wanted to add support for this developer.mozilla.org/en-US/docs/W...
Brining true immutability, custom typed syntaxes and other nice things that you cannot achieve any other way.
Houdini is going to be big and that is an advantage to using this technique, you already have your values ready to feed into a paint work-let for example.
As I said, "Also transpiling scss to css on the fly for getting dynamic values into properties is a bad practice for performance and there's no reason for that", umm yeah thats right, not mentioned anywhere in the post, I mentioned building up variables with mixins.
--my-var: $my-var;. This isn't bad anything.Yeah a dark theme is a pretty contrived example yet understandable use case, it is not the only use case and sure you could build the file, Im not arguing with that. Here is a good use case I have a three.js model that needs to be styled with the same colours as the css in my design, I need to changing the lighting of the model and sync up the animations, The model is a watch, with lume hands, when it goes dark, the lume should light up. Now in this case getting the css properties controlling such things as animation timing and current color, and using them in the css and also within the canvas, thats trivial, updating the styling is also trivial.
This sounds like you tested my library? Anyways yes building scope into a template is great but its still going to be evaluated at run time so I think we are still equal apart from, I have less overhead, the document from re.css would be lighter.
I don't follow :/ sorry, I really tried but I dont, just try the library and tell me how you would work with it.
Ouch, okay, I feel it has plenty of uses and I think you might have some misconceptions about what Im saying perhaps because this post is light hearted and less technical. The readme is more detailed, the issues are more telling and the docs / style-guide are on their way! I hope you follow along and stay skeptical, I really need opinions like yours.
We were both tired, I promise, the library probably does something but Im not in a position to proove it yet.
Much appreciated
"I think you might have some misconceptions about what Im saying" yes, totally agree 😂
I didn't tried your lib yet, i was only trying to figure out why I should need it. I think I understand better ehat you are talking about specially referencing to Houdini, I'll take a look at it when possible (I'm hands on various projects so I've not much time left).
I'm working through performance as first need with my colleagues since some months ago and I'll try to check your source code and make some tests.
The tests we already did was using some libs like Material vs custom styling and inside custom styling we tried some different methodologies to achieve the best performance possible, meaning to deal as few weight as possible to the client and getting as few execution timings and resources wasting. With this in mind, Preact is better than React or Angular, also svelte has a nice way to work from my POV, hope it and it's community grows more for being able to present Svelte demo as valid
framework for a long term application on production (as it manages DOM instead on generating and comparing virtual DOMs the resources needed are way less).
By the other hand I couldn't find a better way to style the Apps than using CSS for all the possible use cases, this is what you said you don't follow, no problem, take a look at my profile and find some articles about "CSS only interactive components". I use
:targetpseudo for showing/closing modal windows,:checkedfor dealing with tabs and accordions etc instead on using JavaScript for that.This permits quick user interactions as the CSS is pre-rendered, no re-rendering nor re-painting here.
At this point you must note that avoiding JS is the key for performance, CSS is loads faster to load and execute and it's API growth well those years, I hope it will grow more on the following for this reasons. Then of course you need some kind of strict pattern and architecture design into your stylesheets to avoid common issues (need for overrides, proper inheritance and so); a mix of BEM methodology with some modifications is what I found better to balance a clean development with a good performance (I'll write a post about in the following days).
I'm a little skeptical about adding libs because we managed to generate a production preact App which uses a custom css framework created by my own with preact components and custom styling that weights less than 400Kb in total; adding a lib which weights 75kb + is a huge percentile weight addition.
Anyway as I said I'll take a look for sure and try to figure out the use cases and thinking about this out of the box objectively (if you already tested it for specific use cases on which you know it helps, please tell me to reproduce it on my tests).
I'll read the readme and the info you linked tomorrow as late 😁