Hola a todos, voy a hablar de aquí, porque el cuarto también es tan grande.
Gracias a todos por venir hoy, somos organizadores de Barcelona G.S.
Normalmente, si lo saben, tenemos eventos en Plasca Catalunya, en el Centro de la Bailaría.
Pero hoy decidimos experimentar un poco y tener una discusión de primer, no G.S.
Y el segundo es de diferentes formatos, no hablan como una conversación,
pero una discusión informal y una experiencia de compartir entre las personas y la industria.
Gracias por venir y por qué estoy hablando antes de la hostia,
porque soy el único de los paneles que es de ICNIC y quiero hablar un poco de lo que es ICNIC.
ICNIC es un encubator de startup, es un lugar muy grande para desarrollar y compartir experiencias entre ellos.
Obviamente, para solucionar problemas juntos.
Si eres parte del startup, si estás pensando en crear un startup,
sientes gratis para contactarnos, eso sería genial.
Pero también, el principal problema de cada startup es la ciencia.
Y yo sé que cada compañía normalmente es más alto, pero en ICNIC estamos mirando a muchos desarrolladores de full stack.
Entonces, si estás pensando en justicia o hablando de oportunidades de nuevo,
sientes gratis para contactarme después del evento.
Ahora estoy terminando y pasando a la hostia real. Gracias.
Bienvenido a todos.
Vamos a empezar ahora. Un par de cosas antes de empezar con la discusión de nuestro panel.
First of all, we have there the information, the website called slide do.
Basically, you can go there under the code and you are able to enter the questions there.
So there will be a list of questions voting there and then we will pick questions from there.
So if you have a question, just go there, ask it and we will try to answer it.
Yeah, so we decided to make the panel discussion because the topic is really hot.
How to style applications, there are a lot of ways how to do that.
And we gather actually like one of the best developers in the city.
I think like people are really experienced and yeah, let me introduce.
First is Eric and you can do it.
Hi, first of all, thank you for having me.
My name is Eric Gleisen. I work at Nurellek.
I'm working on the platform UI team.
We built libraries software for other apps to be consumed by the company.
So we have like, I don't know, 10, 15 apps and we built like platform-wide libraries components.
It has to work cross app and yeah, I'm a senior frangent engineer living Barcelona.
That's it.
What about your technologies tech?
Regarding CSS or in general?
In general.
Ok, in general.
Wow, that's a big question.
Well, we use all the latest more or less.
Every app in Nurellek can choose whatever they want.
So they can go from TypeScript to just vanilla.js.
We also provide tooling.
We have a special library that is automatically configuring Webpack for you with tests, with
just, with everything you can think of, linting, what else, end-to-end tests, everything.
We use Babel, Webpack, SAS, sometimes we use style components.
We use just like a set.
What else am I missing?
So for styling, for the platform team, unfortunately, we cannot go with something like CSS and
JS yet.
I can explain later with the questions why, especially for us, that's not possible.
But for now, we're sticking with a more traditional approach, we are just Webpack.
In CSS, we use suit them convention to the components.
The usual auto-prefixing style lint for consistency.
Thank you.
The second speaker is Marina.
You can introduce.
Yeah.
Hello there.
I'm Marina Esa.
I work as UX, UI engineer at Olaluz.
And you will be wondering what the fact is, UX, UI engineer, like, that's like a mix or
what do I do, okay.
So actually, yeah, it's a mix of product design with frontend.
So I'm like, in the middle of both, I'm more, I've been, I have more experience as product
designer.
Badly, 2 years ago, I started working as a frontend developer and I saw that it was very
important to take those, both departments and put them somehow together because they
actually working on the same stuff, but in a different way.
So I work at Olaluz.
Do you know Olaluz?
With companies.
Okay.
It's a Spanish power company.
So like, en Deza, maybe you know, Iberdrola, it's like a power company, but we have different
kind of doing stuff.
Like, for example, we only work with green energy and our values are better, like, we
don't put the politicians to work on our company, like in Dezadu.
Olaluz, it's only works in Spain, but has very cool, it's a very cool company.
I'm very happy working on it.
And where else?
The Knowledge Stack.
The Knowledge Stack.
So actually, we're working with Backbone, but like, for example, me, when I work on frontend,
I don't touch JavaScript much because my experience is not very high, and I work in the HTML, CSS
part, like, I make that all the companies that we have in design, made with the sketch,
look the same as in the frontend.
What methodology for the styling you're using?
Yeah, because for me, it's like the most similar way of working as in the design with the sketch.
I will talk more about it.
So it looks like you both using BAM, or suit, it's kind of similar.
Can someone explain what is that for someone who doesn't familiar with that?
You or me?
Yes.
I don't know.
Both.
We can talk.
Can you explain BAM?
No.
Okay.
I don't actually know suit, so it will be very good to listen to you.
I guess BAM is kind of like working with components, like their blocks are separated, and they have
elements aside, and they even have modifiers.
And the good thing about BAM methodology is that you can separate blocks from different
parts of the website, and you can reuse them afterwards.
They are not dependent on each other, so they are very reusable, kind of.
Like, for example, symbols in the sketch.
So I guess both methodologies, in the end, what it aims for is just to have very low
specificity, because if you start using nested selector, you just end up in a nightmare
of maintenance.
Suit is just like a slightly different convention that you follow.
We like it a bit more, because, for example, in suit, you capitalize the first letter, and
it maps just more.
We use React, by the way, throughout the whole company, and it just maps a bit better to
the convention with how React works, I think.
But, yeah, in the end, they are the same.
They try to keep the specificity low.
They kind of, you have to manually follow convention to encapsulate your component, make sure that
you're not styling other components by accident, so that's kind of the approach, yeah.
Perfect.
Okay.
And the next one is Ilya.
Hey, long time no speak.
So I'm Ilya.
I'm a CTO at Kamalun, a startup in ethnic, and we are helping people to customize different
things.
And by different things, I mean, like, starting from buttons, chapas en castellano, to stickers,
to calendars, to a lot of a lot of a lot of different products.
And it could sound boring, but in reality, it's really full of interesting tasks, because
from my previous experience, when I was working on SAS, we were kind of selling air, you know,
because when you're selling products, you're selling airs.
And here, switching to, like, real products in real life, you're facing a lot of problems
when you're facing real life in reality.
So, and being CTO, I'm also sometimes do a little bit of coding, but my real challenge
is to be sure that my team is happy, and their experience is great, and their speed is high.
So that's why I sometimes, like, do a lot of, spend a lot of time researching different
technologies, playing with them on my free time, and trying to find the best one.
So today I'm going, yeah, I'm already stealing all your questions.
So about stack, currently in Kamalun, where I have a mixture of things, obviously, it's
like one great stack of 2013, Angular and CoffeeScript, and we are migrating to great
cool stack of 2017.
Let's react to a pack, and all this hype, and also GraphQL.
But in terms of CSS, still kind of no breakthrough was for the last, last, last years.
And today I'm going to talk a little bit about CSS modules, and why they are a different
approach to solve, to fix CSS, as people are saying.
And yeah.
And just about that, I think, CSS modules.
Okay, perfect.
So, Giorgio, is the next one?
Yeah.
And last.
Yeah.
Last one.
Not the least.
Not the least, yeah.
Yeah, I'm Giorgio.
I'm a software developer, I should say mostly frontend developer, actually.
I've done cool stack in the past, but last two years I've only worked on frontend.
I work for a company called Travelpur, I don't know if any of you heard of it.
We are a platform to look business travel.
We are from Barcelona, and we've been open since almost three years now.
The stack has been more or less the same in these three years.
Python in the back end, react in the frontend, although we had a lot of changes for what
comes with styling.
We started with normal CSS, we went to CSS modules, and now we're using style components,
which is basically another way of saying CSS and JS, and we can tell you more why.
Yeah, that would be interesting why and how you were making the decisions and the transition
from playing all CSS to something more evolved, and right now you're using a top-edge technology,
so it would be nice to hear from you the feedback that goes.
So, when I joined the company two years ago, more or less, we were only using CSS, and
we were not too good at it, I would say, there was not much discipline, so the classes were
more or less, hey, this is a name of class that makes sense, it's not working, we were
not doing BAM or anything like that, so it was not easy.
What we decided to do is to switch to CSS modules, because CSS modules, so maybe you
can explain a little bit better what it is, but basically you have a single file with
all your CSS and all your classes, you import it in your JavaScript, more or less, and that
is going to rename the classes for you so that they are unique, so you don't have a class
collision, and it was okay, it was working, but then style components came out, and actually
we found out it is working even better, because it's taking this to the next level, at least
for us, the CSS is inside the component, and when you're doing React, everything is component,
so the fact that you have a sort of HTML, even though it's no HTML, of what your component
is going to look like, and the style, and they are all together, plus you don't have name
clashing, plus you can run all the JavaScript code that you want, you can use JavaScript
method, and for example, we have a list of colors, and if we want a lighter, we just
use the lighter function that we wrote in JavaScript, that would be trickier to do with
CSS, so for us, it's more like more flexibility.
Okay, but doesn't it goes with the well-known JS fatigue, so it grows the JS stack then,
and then you need to know everything starting from building, with the webpack and everything?
I'm a bit ambivalent on the JS fatigue topic, because for me it's like, oh, there are a
lot of people that are making new and amazing things every day, this is terrible.
So I have to say, I think 99% of the new JavaScript libraries and tools that come out every day,
I have no idea about them, so we just research what it's good for us, and we use it.
Yes, it's a bit more difficult to start a project that is using style components rather
than just CSS, because most of people know CSS, but not a lot of know how to use JavaScript,
how to use React, how to use them together.
For us, it works, because we are building one application, and it's a powerful application,
so it makes sense to invest that time.
If we were probably an agency that makes one website every week, a different one, I don't
know, we probably wouldn't do that.
Okay.
Can you compare that to CSS modules, are they still alive after the style components came
up?
Interesting, because for me, CSS modules, and I have a couple of comments, what's the
idea of CSS modules?
If we talk about CSS, and we ask, okay, what problems do you have when you work with CSS,
everyone will be like normally mentioning global scope, because it's the main problem that
you have global styles, and from any file, you can never write or break any other file,
and the classic joke, when two CSS rules come into a bar, a stool, and a totally different
bar falls off.
And the idea of BAM, and all other methodologies, in general, was to make developers disciplined
enough to write styles that way, that they are kind of isolated, and they are not shared
across...
They are shared, but they are kind of isolated because of the naming that they're using.
And CSS modules, the idea of CSS modules was okay.
We already have...
It's kind of solved, but people are really bad in doing mundane tasks and doing not, like,
not inventing stuff, so...
And they are generally bad in discipline.
So let's make machines to do the work.
The idea of CSS modules was okay.
You are writing normal CSS with normal names, so, for example, class logo or class avatar
or whatever, and then, through post-CSS processor or webpack processor, it's this class name
converts into something totally non-readable, but unique.
And then, from your JS side or whatever side of rendering, you're just, like, entering...
Automatically referencing this class, and you're getting, like, unique class names, but totally
readable and separate the files.
And the only comments to Giorgio, he also told that he...
I believe you inserted the whole CSS, and it's, like, one CSS module, and then you were
using them.
You said that we, like, kind of importing all our CSS as one file into CSS module, and
then we were reusing it.
Yes?
No, really, no.
We were separate.
Ah, you were separate.
Okay, yeah.
Maybe I'm missing a...
I was importing in the component.
So the CSS of the component...
Yeah, exactly.
So, yeah, the idea was the same as soon as React came up, and the component started to
the world.
CSS modules was also, like, a great idea, because you could collocate the, for example,
React file, the JS file, together with a CSS file in the same folder.
And then you just go into import that CSS into React and reuse it.
So it was kind of cool.
And then webpack or CSS was totally converting everything to unique style names, which also
was great.
But the problem, and JS Fatigue, is not only because of the new libraries coming out.
The problem is that if you want to use, for example, now, even CSS modules and, obviously,
CSS and JS, you need to render on the client side.
And there are applications which are still using good old Ruben Rails or Django, whatever,
and they are totally server-side rendering, and they do not need to have React of, like,
any kind of client-side rendering.
And that's, like, a big problem, I believe, to start using CSS modules or CSS and JS,
and that you need to have a special application for that.
And which is good for them, because you don't need to have it.
Yeah.
I was going to say that, like, for example, we are not using React.
How could we apply...
It's only limited for React, right?
It's kind of limited, if we're talking about CSS modules.
Theoretically, like, when you have your styles and then they are going to pass through CSS,
just emits a JSON file.
So if you want, you can write a special render on your backend that can parse this JS file
and return you, like, normal class names and then these strange class names.
But as soon as I was, like, checking this morning, for example, for Ruben Rails, which is kind
of popular, there was no, like, really popular or bulletproof solution.
So everyone was kind of saying use the pack and render on the client side, which is kind
of strange.
So about the naming, isn't it difficult to maintain an application that has random names
with...
Oh, actually, maybe it doesn't have random names because you're actually calling it in
a proper way, but afterwards has these weird numbers, for example.
I mean, I never use it that way.
It's configurable and normally people configure it that way that you have, like, human readable
thing and then the six or eight symbols of hash.
And obviously, then, when you want to debug, you can just drop the last part with hash and
just, like, okay, this is my avatar component or this is my sum, I don't know what.
So it's still debuggable.
Also, you don't care about the name that was generated.
You have your CSS with your class that you defined and use that name, and you have something
that can be webpack or CSS that is going to do the conversion for you.
So you never really deal with this weird class name unless you debug in production or this
kind of stuff.
But, yeah, in the end, the only thing that you need to use these modules is a bundler
because as soon as you can import and export things, you can import CSS and the bundler
can take care of the hash.
So, even if you use BAM or if you use, like, a simpler stack, that's the only thing that
you need.
So React is not a requirement or some other framework.
It's good.
We are, like, moving more and more into the styles in the JavaScript.
Like, that's kind of like a trend.
What about designers?
How do they feel about styles being, like, moved there?
I'm a bit hater, kind of, sorry for that, like, I'm feeling like putting the inline styles
into the HTML feels so much like 2003, kind of.
And the reason is because in the design part, we are starting to develop design systems.
Have you heard about it?
Design systems?
No?
No.
Ok.
So maybe this is the reason because design works closer to the front end and closer to
the design.
Because there is this trend or this, actually, I think it's a very good idea that design
is not only how pretty your application is looking, but also a system behind of it where
you have all your elements, where you have all your blogs, and where it has actually a
coherence between all of them.
And since we are investing all this time in developing design systems, that they actually
have very, like, all the elements in the application, all the styles that can be used, and how the
phones are going to be, what is limited, what is not allowed to put into design.
In the front end, we are just, if we put the CSS into JavaScript, we are not following
that design system that the design team created before.
So that's the reason I like more Ben, because it actually follows the same system that has
been created before.
It's like a connection with the system, yeah, with the design system, and I don't know,
it follows a coherence in the whole application.
But this is like, if you actually want to mix design and front end, because if you really
don't want to do it, or your application doesn't need it, then maybe the performance in CSS
with JavaScript is better.
Yeah, just regarding the design systems, I think you can still do that with React and
style components, for example, because in the end, you will just use the component as
your API.
So instead of using the styles, you use the component props, so you can set, instead of
a primary class, you set a primary prop on the button, for example, and you get the same
result.
The only thing that I'm not sure about is, like, prototyping.
So what if you just want the visual in a website real quick, like a lot of style guys just
have, like, an easy way to copy paste, right, in the website, and just copy paste stuff around.
To prototype something quick, you need to have some kind of boilerplate with React where
you can drop in the component.
So it's a little bit more technical, maybe, for some designers, so that could be a downside.
But it's still possible, I think, with the design system.
Can I tell you how we do it, because we actually, sorry, last year, we've been working a lot
on creating a design system, and as Eric was saying, you can still do React, instead of
defining the class name as a separate component, you have a component as a separate component.
And we're using two tools at the moment, one is called Storybook, the other is called Style
Guidest.
Basically, they allow you to see the component in a vacuum, sort of.
So, for example, you have the button, and you can see the button with nothing around,
and you just see what is this button, how can it look like, can it look big, small, primary,
secondary, and all these things.
And then we have something called Playground, where you can just take this component and
sort of build a page.
So depending on how familiar the designer is with coding with JavaScript, they can either
use Sketch and just leave it to us, or they can try to mock up.
And what we saw is that many, well, our designers, they started to just try variations of what
we have in production just by changing the code.
In Playground.
Or even just spinning up the front-end application and try it there, or in the Style Guide.
But one thing that you said, and I think it was important, and I think many people think
that CSS modules, Style Components, are like the holy grail, that's the solution.
Yeah, I just have a small file, I'll import it, that's it, done.
But not really that, you still need a lot of disciplinary, they are helping a lot, but
you still need to think about, oh, my component has to be isolated, and it has to respect
some logic so that it plays well with everything else in the app.
And my colleague can use it, I will understand it a year from now.
All this type of stuff.
But you say that with CSS modules, you actually it works, I mean, you don't have to think
so much as, for example, in BAM, about the installation, right?
Yeah, but maybe it's also for you, but you import the CSS somewhere, so instead of thinking
about the class name, you have to think about the thing where you import it, too.
Okay.
So you import in a button, but how does this button, what properties it expects?
Yeah, exactly.
I think it's the same way as BAM teaches you, okay, we have a block, like CSS modules,
trying, like, not CSS modules itself, but the idea of react and the idea of components that
we are working kind of lately for the last, I don't remember how many.
Yeah, we are all doing components at different.
Yes, and they are kind of atomic, and you can compose them like LEGO blocks together.
And BAM, CSS modules, style components, kind of the same way of solving that, but just like
the different approaches.
But I have a question for you, like, is it like a high level, what's the entry point
for designers to start editing codes in style components?
Because I believe, like, okay, if it's CSS, it's kind of easier to find a person who can
change CSS, but if we talk about react and style components and stuff like that.
Okay.
Well, I'm a bit spoiled because my designers, they know how to work with AS, and I have
to say that it's easier because we speak the same language.
I had recently an issue where my designer gave me a design, and I could not implement
it because I couldn't find a way to do it in CSS, and in the web, it was not possible.
So I was talking with him, and we found some trade-off, but I didn't have to explain to
him, hey, I cannot do it because in HTML this doesn't work.
So he knew, and he actually came up with a solution, he told me, okay, let's do this
trade-off and it's going to work.
So I would say, I prefer to work with designers that know JavaScript, at least a little bit.
And the other thing, I've been met in designers, I'm kind of scared about JavaScript because
it has a bad name, because it was kind of bad for a lot of years.
Now it's better, but it was very bad.
But if you look at one of our components, for example, it's usually, it's a bit of HTML
that you understand, it's a bit of CSS, and you know that.
And there is more or less usually the same JavaScript in between.
Of course, I'm talking about a button or input text, if you start working with some
huge component, that's my job, that's why they hire me.
But if you just want to work on what you probably call atoms in your methodologies, in a couple
of days, it's easy for them to pick up.
What's hard for them usually is to understand that they have to update the snapshot when
they run the test ingest.
So that's the other thing.
That's the other part.
But working on the component, not really an issue.
Enrique, what's your experience with the styled components or anything else, and how it goes
in your company?
Are you planning to move towards them, and how it goes with the designers working with
your code?
How deep into the code you let them in and change, or you're doing everything by developers'
powers?
So, there are three questions in one.
Let me just give some context first, and then maybe you can repeat the question, the second
and third question.
So in Enrique, like I said, we build the platform, so we build software that's consumed by others.
We had many discussions before about, should we use CSS modules, should we use style components,
should we use any other CSS and JS solution.
In the end, we decided not to go for it, and the reason why is our components, despite
that they need to be consistent and conform to the style guide, to the design system.
Then, almost always, there will be a slight case that something needs to be tweaked, something
needs to be modified if it's changing a color or something like that.
So what happens?
They get a component, and, for example, they want to style the icon a little bit different.
So let's just take CSS module, and I don't think that's possible at the moment with CSS
modules.
Then we move to style components.
So in CSS modules, everything is really isolated, right, because it's hashed.
So if you have a wrapper component with an icon inside, and you want to style the icon
a different color when you hover the parent component, that's a bit tricky to do, because
they are hashed, or you cannot access, or you cannot make this kind of selector.
So I believe it's not possible, correct me if I'm wrong.
In style components, this is actually now possible to create, like, the reverse selector pattern,
which is quite nice.
The problem there is, okay, so in style component, it's possible, but so you can import the icon
inside your button, and then on, no, the opposite, you import the button inside your link, and
then when you use that value in your style component, CSS, and on Huffer, you change the
color.
Great.
So it is possible in style components, but that means if we are going to use that, all
our consumers that use our library, they need to use style components, because style components
work with functions, they get composed, so they need to adopt that.
And as we make, like, component libraries, charting libraries, we make this kind of things,
and for me, it's kind of a no go to say, okay, the only way you consume and do this kind
of things, which happen quite often, actually, is to use style components.
That's about it.
What were your other questions?
Sorry.
The second question was about designers.
How do you interact with designers, and do they modify the code or not?
No, our designers don't modify the code.
Our designers work with Sketch, with Brand AI, as kind of like a reposter, we deploy the
designs, and they use Framer for animations, sorry if I used the wrong name, and they use
what it was, what it was, I forgot the name now, well, they use another Sketch plugin,
I think it is, to create a design language.
So they actually build those components, and we can export them to Zeppelin and get the
styles and everything, but we build the components, we do all the technical part for them.
So they are not modifying, but they use, for example, InVision, I think it's called,
which is kind of a quick way to do the flow of some mock-ups, to do some prototyping,
so they use that for prototyping, and they use the design system for that, without using
the actual code or library.
And how do you synchronize between the code and the design, you know, like usually the
design changes came, and then it becomes outdated, because someone else changed something, and
it becomes outdated with the code, and actually a couple of versions of design.
So what's the way, are you using any kind of style guides?
Well, our design system is kind of a style guide, but the way to update, yeah, I mean,
they work ahead of us, and then when they finish work, we kind of update the libraries
in batches, but Neralik is quite a big company, so often it doesn't work so well, or things
get out of sync.
But yeah, that's software.
The design is your guideline, yeah.
The design is a source of truth.
Yeah.
Well, that's our idea solution, it's not always the case, unfortunately, but that should be
the case, yeah.
Yeah, that's how we do things.
So yeah, that's why we didn't choose to go with CSS modules or style components.
I do think, especially some CSS and JS solutions provide even some extra crazy optimizations,
for example, there's some of them, I don't think Style Component does it.
So let's say you have a style component that uses on one element, some selectors like
font size 18 and, I don't know, font weight bolt.
So this gets injected in the head under a hash, right?
And the thing is, this can be optimized, because if another component has a different select
or a different element that uses the exact same attributes, it doesn't make sense to
do another hash with exact same attributes.
They can leverage and cache these kind of hashes and use the same styles for two different
components.
So you can kind of dedupe your styles, which you can win quite a bit if you think about
how many times you use some different CSS attributes across different components, especially
on a large component, a large app, that can have some significant wins.
The other thing that I don't like so much about the CSS and JS solutions is, yeah, I
think the performance, because what happens, well, first of all, also, like, if you don't
have JavaScript enabled, nothing is shown, that's one thing, but also, kind of nowadays,
you probably also watch a lot of these talks from the Chrome Dev Submit about performance
and stuff, and they always talk about delivering everything super fast and not on your developer
machine with good Wi-Fi hardware.
So you need to test on a mobile device that is average, and the results there always come
back that a mobile device is actually even JS parsing is really hard.
So what happens if you use, for example, style modules, you load the JavaScript, it needs
to get parsed, and only then the CSS is injected into the head.
And yeah, you can server-side render your style components, but then you're duplicating,
you can, I think they have now ability to extract CSS out of it.
That's nice, but you're also duplicating the CSS, because now it's in your JavaScript
still, the source, and in the static CSS.
And then also the dynamic parts, because in style components you can do, like, instead
of just writing CSS, you can do props and then do some logic, right?
This cannot be extracted because it's dynamic, so then you have, like, super nice, I think.
So yeah, these were the things that we thought about when making decisions, and we came back
all the time to see, okay, it's now the time to adapt to style components or some CSS.
Not yet, not yet.
So yeah, and I'm myself quite a fan of performance, and that just hurts to me.
And also, yeah, you can do the server-side rendering, but then you have to do the server-side
rendering, which should not be an obligation, I think.
So that's my thoughts.
Did I miss a question?
No.
Okay.
I think guys have something to add for that.
Oh, wait, you say a lot of stuff.
I think, no, it's okay.
It was interesting, actually, but I think the thing is, you work for a new rally, and
we work for smaller companies, so we have different requirements.
So when we started two years ago, the problem was not having a fast application, it was having
an application, because we started from zero, right?
So for us, style component was the fastest thing, and we didn't have to create this library,
styling library, and share with all our offices around the world.
So if we had to, we probably would have gone with CSS, because it's the easiest.
You don't force anyone to use React or anything.
About performance, so far we don't have issues on performance, but yes, when we will get
to the point, there are all the solutions that you mentioned, to be honest, I don't know
how better.
I guess they are not as good as CSS, because the plain thing is always the best one.
But it's a trade-off.
Yeah.
Maybe I didn't mention it explicitly, but the reason why I said, also, like the extract
CSS is obviously caching, because if you inject styles in the head, this doesn't get
cached, and if you can extract the CSS, this can get cached by the browser, and you don't
have to.
So that's why I mentioned it, I just want to clarify it.
Yeah, also, another, sorry, another thing, I'll be following this kind of solution, so
another thing that I came across was a threat of the creators of style components, actually.
And regarding animations, also, there was like a, how do you say it, a reproduction
of the problem, and it creates some animation, and so in style components, you can do props
and you can do dynamic CSS based on the props that are coming.
But for animation, that is actually a bad thing, so actually the creator of style components
is just set, don't do that that way, the preferred way is doing inline styles, which actually
makes kind of sense.
So, if you use the kind of solution, there already start to have different paths, you
know, for animations, you have to do that, for other things, like state changes, you can
use the dynamic values, yeah, I was not so, so super thrilled about that, but yeah, I straight
us in the end, and like you said, my context is so different, if I just build an app that
nobody can choose, I can, I'm the only one that cares about it, I'll probably go with
something like style components.
But I also think that people tend to overuse what a library allows you to do, the example
with the animation, so you always, what we try to do is try to use the platform, the web
as much as possible, because there was this same issue when lesson, Sasa came out, like
the chain of hell, you ident the class, you don't have to do it, some of you can, but
you don't have to do it.
Then lastly, like in the end, it's also, we just have like a one-on-one here, no, just
to make like the complete picture, I think also, you have to consider also the JavaScript
is growing, because in the end of style components, I believe it's like 35 kilobytes or something
in that area, G-SIP, it always gets smaller, then a lot of people, or a lot of people,
if you want to have really all the functionality from Sasa and lesson stuff, you need to maybe
import Pallas.js to have some functions and extra stuff, so I mean, in the end it adds
up, if you think about like, your first 14 kilobytes need to provide the whole website,
I mean, it adds up, trade-offs, trade-offs, do you want to, no, I'm just like a lot of
topics here, what was covered.
The first thing, I really believe CSS and JS could be faster than the normal CSS, in
terms of performance.
Now I will open my case, yes, rendering performance, and like just, like if you want first meaningful
pay and stuff like that, it could be faster, and I will explain why.
The first thing, the difference between normal CSS, let's put it that way, and any CSS module,
so CSS and JS especially, is that you start parsing CSS, as soon as you start parsing
CSS, like automatically or anyway, like with any tools, you can know then when and what
is rendered, and how it's delivered, because now if you want to start about thinking, okay,
I have like 15 or 50 or 100 kilobytes of CSS on my site, now I want to make it fast,
how, and then it will be like a question, how you're going to split, because you don't
know what classes will go in where, how to do the things, you need to do that manually.
With not styled components, but other example, for example, emotion, it's another approach
to CSS and JS, and they are doing interesting things, because we also need to differentiate
between what is CSS and JS, sometimes it's static thing, that you are running JS on top
of your CSS, and you are getting the build, and sometimes it's something, what's running
on the runtime, and what's going, like injecting stuff in the head, and doing all these things.
So emotion is kind of hybrid approach, then have a Babel plugin that could analyze your
CSS, then deduplicate it, and also if you want it, they could extract it as a different
CSS file, so you have kind of the best approach of two worlds, so you can cache it as a result,
and you can deliver it as a different request, but what they can do even better, they can
then automatically extract for your critical CSS, is the first thing that you can align
with the first requests in HTML, or whatever, and have the first meaningful pain way faster.
And the idea is not like styled components is for the win, or emotion is for the win,
is that as soon as we start parsing CSS, we can then know more about what we are writing,
and then we can obviously optimize it more meaningful way for machines, because machines
are exactly for that, they don't.
And for animations, there are two things, the first one we can also differentiate between
static animations, it's just like spinners or stuff like this, and stuff that should reflect
the user input, as soon as you direct something dynamic, or like you're following the button,
and button should be like, in iPhone all the animations there, with springs and stuff
like this, which totally depends on the state.
And if you do animations based on state, I don't think there is another approach, except
like doing either in line style, so stuff like CSS and JS, because it's way, way easier
to do that there.
And I think it was all the topics.
Ok, so it was very interesting, all the performance, all the topics that we have been talking about
at the same time, I was thinking about CSS in JavaScript, and I was thinking, like, I'm
worried about the total installation of it, like, for example, when we work with BEM,
we use SAS, and then what we do all the time is like declaring variables, global variables,
and then we are using it for colors, for fonts, for even margins, spacing, and we are also
extending classes, like, for example, we work with the columns of bootstrap, so we are actually
extending classes, and, well, in BEM, you are all time extending classes from other elements,
so it makes your productivity quite faster, kind of, because you don't have to repeat
the same class, or the same variable.
So how do you work with that when you are totally insolated with CSS in JavaScript?
You are as isolated as you need to be, so, for example, we have a list of colors, which
is literally an object with all the colors.
We have global variables.
It's not global, we import the colors, and we use the colors that we need, and for classes,
we don't really use classes, but we use components, so, for example, we have a component that you
can use to search for airports, right, what the component does is importing the text input
component, so it's like, it's rendering a text input component, with all the styles plus
some logic to get the airports.
Okay, so it's not totally insolated?
It's not totally insolated.
Yeah, it can import a sport element, okay.
Yeah, exactly.
It's as isolated as a local level, so, but if you want, in CSS modules, as an example,
it also provides a kind of extension of syntaxes, so you can use the, like, you can use a new
world called Composers, so you can compose these classes, and CSS modules will do that
for you, and also you can do import stuff through, like, either normal SAS, or, like, through
the CSS modules itself, so they're kind of importing CSS in your local component and
reusing it, exactly.
But the cool thing on top of that, as soon as I said that CSS is parsed, that then you
can have the tooling on top of these with, like, for example, Flow and TypeScript, so
if you have a huge list of constants or whatever, like, configuration, you can type it, and then
when you import it, and you're doing a type or whatever, your IDE will tell you, like,
your editor will tell you, hey, there is no such color, in reality, because, yeah, it's
already...
You're also unit tested, yeah.
I think eventually libraries like React will probably take advantage of it, so they will...
Well, which is more or less like Polymer does.
It gives you some utility method to use the underlying thing, so I don't think it's gonna,
in the short time, gonna kill, react, Angular, all this kind of stuff.
The libraries are going to use it.
We have another question.
How does CSS and JS affect browser caching mechanism for JS and CSS, if it does?
More or less.
I'm not an expert in this, but you don't allow the CSS file, you don't allow the JavaScript
file, and it's gonna get cache by the browser.
If you don't export, it's normally insert stuff into your head, as soon as it's parsed,
and then there is no cache.
Yeah, so...
No, it's only cache for JS parts.
So, maybe you have kind of advice how to do better based on your experience, or how
are you doing right now, that part of...
No.
I will do a classic disclaimer.
It totally depends on your project, and you need to measure first, but in reality, yeah,
that's...
Exacto, exacto.
But normally, yeah, in CSS modules, it's really easy, just adding one webpack plugin to extract
all stuff from CSS into like a separate file, and deliver it as classic as a way, as a way
we were already used to.
So, but yeah, you need to measure first everything, until you do any kind of optimizations.
We have touched, like, a bit the topic about animations, it's not there.
Can you discuss a bit about animations in 2018, or no, 2017, how are you doing them?
Are you using CSS, or using JavaScript, or jQuery?
So, yeah.
Me first, okay, animations, yeah, actually quite straightforward, I think, for simple
transitions and stuff like that, we use just CSS transitions, more complex animations,
we use inline styles, with currently, in our project that we're working on right now,
we use ReactMotion, which works quite nice, because often it's not only animating, like
doing the style changes, with animations, you need to keep DOM elements in React around,
even though you try to remove them, you need to keep them around for the animation, and
then you remove them from the DOM, things like that, and a library like that helps a lot.
So that's my answer.
We only use CSS animation, actually, like, in the project that I've been working on, we
don't have really, like, very big animations, or they are very simple, so, only in CSS
works for us.
I already answered, yeah, I like CSS for super simple transitions, and as soon as you have
like something state-related, you either say, no, no, no, it's too complex, I'm not going
to do that, or that, yeah, but, yeah, in reality, you are using something, anything based on
your component, in your style, either in line styles, CSS and JS, or, yeah, I believe,
nothing more.
Yeah, in general, try to use CSS as much as possible, because that's the optimal one.
It's definitely better than your for loop that you write, to animate, or whatever you use,
so, CSS, and, as it calls, CSS, transition, or something like that, it is the library
that Reactgroup creates.
Yeah, CSS transition.
Yeah, which is basically removing classes, and then you style the animation with classes.
What about standardizing the way of your writing, the code, so, everyone is using code reviews,
but aside of that, are you using any kind of linters, or something that enforce the way
you write the code, for styles?
Automation, for styles, obviously, auto prefixer, you don't want to do that manually.
Style lint, which I think is a must, and now, I don't know how long ago, but they even
allow you to fix, automatically, your properties, kind of like what you can do with East lint,
and prettier and stuff like that, so, yeah, automate as much as you can, I would say.
Whatever you're using, it's a plugin for Atom, and I don't know the name of it, I don't remember
it.
It actually just makes you, it obligates you to start putting the CSS classes from the
inside to the outside part, so, maybe, like, the padding goes first.
I started working on it, like, when I started in Oralud, it was a month ago, and it just
tells you all time, like, you are doing a throne, and you tell you, like, where has
to be first, you know, but it just works, like, I think the code goes first, if you extend
any class in CSS, it always goes first, with and hate goes in the last time, and, I don't
know, it just, actually, it's just for having cleaner code.
I'm a huge fan of all automatic tools that can fix code for you, because it's perfect.
It's normally real pain to introduce it into the team, a lot of things to fix, especially
if the tool is not allowing you to fix them automatically, but thanks lately, like, to
style lint fix, especially prettier, for example, you can just save the file, and it will, like,
be the benevolent dictator, and it's the only way we are writing this.
It helps a lot, especially on pull requests, because people are starting to concentrate
on, like, big picture, and not, like, eh, it should be a single comma, not a double comma,
or something like that, and, yeah, that's why I believe that as much tooling as you can
put on top, and then, right, run them on CI, or pre-commit hook, on Git, or whatever,
it could help you a lot, and especially if we are talking then about types, and typing
CSS, also a cool, cool thing.
We use Pretier, which is probably the best tool we have, great.
We put in continuous integration, so if your code doesn't follow Pretier, you're not gonna
merge.
We don't really have any style lint, yes, lint rule, or anything like that, because what
we found out using CSS and JS is that if you're writing more than 10 lines of CSS, you probably
need to split it.
So the CSS is so small that it's easy, it's easy to understand, it's easy to figure out
if there is something wrong, so.
Okay.
From my side, that's all.
Maybe you have questions to each other.
I see.
We have a lot of questions there, no?
Yeah.
Well, mostly, we answered them out, like, mostly covered.
Mm-hmm.
I think, I think, like, from a maintainability side, what I see with BAM, what is kind of
a downside is that, like, you can still have, like, the dependencies between your components
and your style, because you can import your styling component, and they're somehow linked
if you remove the component that goes away.
Yeah, I think, definitely, with the CSS and JS solutions, you have more options to detect,
especially unused codes, that you still have reference in your code, but it's actually
not used, because you can, like, let's say, install components if one of those reps, react
elements is not used, actually IDE is putting it in gray, right, unused element, things
like that.
That's actually something I really like from the CSS and JS solutions, and, yeah, maintainability
is also a big part, because, like, writing a small app is maybe easy, but if you write
a big library, a big platform, at some point, it gets bigger and bigger and bigger.
So, now it requires discipline, understanding everything, but tools, the more you can animate
that, the better, of course.
I'm talking about maintainability, lately I was really hyped about the new thing, it's
called Functional CSS, it's, initially I think, and when I was showing it to other developers,
the reaction was the same as when the React came out, like, what's putting HTML in JavaScript,
I thought we already passed through it, no of that, but the mantra was, like, give it 15
minutes.
So, the idea of Functional CSS is, like, that you don't need CSS, is that you have classes
kind of for everything already, and then you just compose it, like, passing classes to
your components or whatever, is that if you know, for example, bootstrap, there is, like,
the good example is margins, so if you have, like, margin, bottom, it will be, like, mb-3
or something like that.
And now, imagine that you have all possible combinations already prepared for you, if you
want, like, rounds, rounded corners, it will be, like, something, RC2, and 2 is, like, 2 pixels,
RC5 will be, like, rounded corners, 5 pixels, and you can, like, have elements and rules
for all of that.
And then, what you are going to do, just, like, okay, I have a component, I have my design,
now I just need, okay, I need some margin here, I need some padding, I need different
colors, you're just, like, adding classes to your divs, and just that, you're not writing
CSS itself, you're not writing even CSS or whatever.
It's initial reaction, obviously, like, what the hell, what are we doing, and why do we
need it.
The cool thing is that, as soon as you have everything prepared, you have already agreed
that you configured by these functional CSS, you have your typography there, you have all
the paddings and margins standardized, there is no way to shoot yourself in the foot.
You could not write now, okay, now margin will be, like, 4 pixels, and designers will
then come and say, like, why it's 4, it was, like, 5 or 10, I was, like, thinking differently,
ah, I forgot to measure, you cannot do that.
And the cool thing also is that you are not going to duplicate your CSS, because all classes
are already there.
So you're loading, like, 16 kilobytes of all possible variations, and then you're just
doing this.
And even better thing, as soon as we're talking about components, and separating everything,
you're writing all these huge lines of classes only once in your component, and then you're
reusing components, and that's, that's kind of beautiful.
So, yeah, I was kind of freely hyped when I got an understanding of this, and now I want
to play and play with it, with it more.
Yeah, it's totally different strategy, I'm saying, it's not CSS modules, it's, like,
it's a different thing.
I'm just, like, saying that it's a new guy on town, that could be interesting to see.
The thing that I, I only checked out Techion, it's the name, I didn't check others out.
The thing I didn't like about that, again, the story, if you consume your code with others,
and they need to, not access the root element, but an element inside your component, what
are you going to reference that element, that ACML element by, that's going to be tricky,
because the only classes there are margin, or display, or...
But it's not saying that you couldn't, like, it's totally blocked for you to write CSS,
or anything like that.
Yeah, you can add, like, any other classes on top, and reuse it, or whatever.
But there you come kind of in the battle, like, you start adding classes, so you have, like,
this really functional, low, or non-specific, functional CSS, and then you mix it with more
specific, and you can kind of get in the way, but other than that, also, I'm always a big
fan of keeping your classes semantic, this is, like, the total opposite.
I actually, I never tried it, so I would like to try how it is.
But I see one issue there, if you have semantic CSS, and there is going to be a redesign,
or someone adds another breakpoint to, like, a mobile breakpoint, some of these added instead
of...
Then you have to not only change your CSS, but also your HTML, or your JavaScript, like,
you have to completely change everything, because everything is so low in specificity, that
the order of your classes actually matter.
So that was for me, but I would like to try it out, because I think the simplicity is really
nice, the restriction, and you don't have to think about it, it's really, what you see
is what you get, but, yeah, these are my doubts that I had.
I would like to ask about functional CSS, because how does it work with media queries?
You have all of your media queries already prepared, so it's, like, the same as a bootstrap,
you have, like, LG, or MD, and stuff like this, so you're just, like, writing, okay,
what's the size of the grid, should this element use for, and then it will be like...
You declare, or that...
Yeah, they already declared the only thing that you need.
If you want to configure it, just, like, okay, what my media, what my breakpoints are, and
stuff like this.
So, all other stuff already prepared for you by, like, there are a couple of libraries,
but the biggest one is Tachions, and Tailwind CSS is kind of the new one, but it's also
really popular.
And in terms of Semantic, it's interesting, it's not my great idea, just like the author
of Tachions, because he was asked the same question, but what semantic means?
Because if we want to talk about, like, really, the idea of this semantic is that could be
consumed by machines.
So classes that can see, whether you write just, like, my header, logo, something, something,
it's not really consuming machines, it's for people.
But this functional thing is kind of more clear to idea of semantic than what classes people
are writing normally.
Because it's, like, really for machines, LG3, MB5, or something, something like that.
But I totally agree with you that, for example, for Tachions, you obviously need cheat sheet
to understand, okay, what's the help, what the hell is happening, because it's kind of
really hard to...
I don't think the problem is the machine, I think it's for me as a developer, instead
of going there and see, oh, deep class panel, it's a panel, I go deep class, and I have
five paddings, five paddings, which describes the panel.
So you can extract that to a component, et cetera.
The problem is that oftentimes, what we do, we are creating a component that needs a little
styling inside, and we don't create a component for just your Ion CSS, we just create a constant
with style components, et cetera.
Maybe it can work with functional, I don't know.
Yeah, you can work the same way with functional, you just add in classes, but the cool thing
about separating panel and this strange way of writing classes is that when you just imagine
you have only HTML, you don't see CSS, and you don't see the browser, you're just reading,
okay, header, something, something, then avatar, migrate avatar, whatever, you don't see the
representation until you open the browser, or until you open CSS.
If you have this line of classes, you already can imagine, okay, this is BG blue, so it's
going to be background blue, then the margins could be like this, so you already can start
imagining things before it's even rendered.
So that's why maybe it's even easier to start composing from user perspective.
Persona, I just prefer to have a style, a style, get it, like that.
And what about states?
States is you're either adding classes or removing classes, the same way.
So you're also adding inside the classes?
No, it's because you have, imagine, you have classes, and then you have a huge list of them,
but if something button now disabled, you're just like adding class disabled, and it's done.
Which is one thing I don't like about CSS modules, you have a lot of logic to add and remove classes
and talk about them, that's one thing I don't like.
You actually have to do that with JavaScript to add and remove classes, okay.
Yeah, regarding semantics, I think for semantics, for me, I always think of the case of Mira
queries, you can put like the exact media queries, or you can just have saying what it should be,
this should be the footer, and you do the media queries inside the footer.
So you can make, you can put a completely different style sheet, and it looks totally different,
but all the semantics are the same, it's still the footer, right?
So that's what I mean with semantics.
And when it's consumed by machine, I think more of like metadata and things like that.
What about media queries in style components?
How do you solve the problem with mobile browsers?
You just create media queries like you would do in CSS, basically.
Like you can still define media queries value in the CSS you define.
What we are doing now is some of our components receive properties that are raised, basically,
or objects that are mapping, like, I don't know.
We have a spacer component, but it's basically adding space where you need it.
It can be a space six, for example, or it can be a space six on large,
space seven on everything that is tablet or smaller.
And then you just redefine it with media queries CSS.
But in the end, like, all the CSS's get rendered,
well, like, the whole thing with all the media queries get injected into the head,
or it depends on the device?
No, everything is in the browser, like all the media queries.
I guess you could do some detection of, well, actually, one component that does that,
instead of relying on media queries is checking the viewport with,
deciding if it should render or not.
It depends what you need to do.
It might sound slow, but so far we didn't have any issue.
Okay, if nobody else have questions here,
because, like, all the questions that we had mostly were covered.
Yeah, maybe you can suggest anything trending right now,
like, on the internet, and what we should take a look on so people can learn.
One thing that caught my eye, a thing that was released last week,
is a statically typed CSS library that came out called Stylable,
which looks pretty interesting.
It claims to replace everything, as always, in the front-end world.
But what I specifically like about this one is that they used pseudo-selectors
in a way that is still compliant to the specs,
and it was, yeah, it was quite creative,
and they used those pseudo-selectors to reference the elements in the component.
Check it out, Stylable.
Looks pretty cool.
I think we have covered so many stuff.
I also take functional CSS,
and it was the first time I felt like,
what the fuck is this, like, sounds so crazy to do it in this way,
but you actually explained it very well, and it makes sense.
I don't know anything else that we haven't covered before.
My advice, and my advice,
would be just to try the new way of doing things,
because, yeah, is it could be functional if you're doing CSS
and just looks like into, like, other approaches,
or if you're using BAM, just try to use it into CSS models or whatever,
because just, like, even playing on your pet project,
or maybe a production code, depends on you,
could bring a new ways, a new vision to your ways of writing the code always.
Quite boring, actually.
I don't really like the new cool thing.
I like the thing that makes me sleep at night,
because especially your duty doesn't go off.
So, one, two tools that I really love,
that are prettier, which is amazing,
and create React app, super easy to set up a project and everything.
Yeah, I agree with Ilya.
Like, keep looking at what's going on, what's happening,
there are a lot of new ideas.
One thing is that if a new idea is better,
you don't necessarily have to switch,
because you also have to pay the price for the switching.
Yeah, and well, in the end,
like you said, it's good to try everything,
but you have to realize everything has straight up,
like, BAMSOOT has straight up CSS models,
straight up, and style components,
and it depends on the project in the end
and what your use case, so always keep that in mind,
and not jump on the next back thing,
because it's very hipster to this.
Exactly, keep that in mind.
Angular 1 decided to change the API.
It's a totally different project now.