(upbeat music) (clapping) - Okay, hello everybody, my name's Glen, thank you, John, for the intro.
Thanks Mark for setting up and kind of establishing half of my argument for me and also actually using some of my examples which I'll now have to skip. My name's Glen, that's me on Twitter.
I am freelancer, most of the time I make screencasts as well as John mentioned, but for the last couple years, doing something like that, doing freelance stuff, trying to make videos, trying to research, trying to come up with new ways.
It's been a good way to do other things as well and I've been lucky enough to be involved in a series of open source projects.
Mark already introduced CSS modules which something him and I worked on, in fact, if you're coming to CampJS this weekend, I know quite a few people are, I think it was two years ago at that camp where him and I were both trying to convince each other that our idea was better and then we realised that if we compromised and called it CSS modules and gave it a cool logo, people would use it.
But what I'm really pleased about is that we've been able to take contributions from 130 people, and we've been able to develop, extend our initial two person core team to add Phil in London, which is why so much been happening recently on the project so, it's been really good, Max is in Vienna, and I'm here in Melbourne, and together we make this, this library.
But, there's actually more it, and I think, with some stuff that Lea was talking about yesterday, the why you would add new libraries, what you're trying to accomplish by adding a library to the ecosystem. It is worth discussing, so, it's gonna start with design goals for the project and then kinda go community or ecosystem goals for my, the reason I want to contribute to this stuff. So, design goals, and I got kind of a list of things that I think are important and they're transferrable to other libraries as well, it's not just about my stuff. But I think the first thing that a library, the first job of a library, is to establish and kind of codify some best practises, something that works well at scale, works well for some particular task.
They're talking functional units.
Design reviews, designers, design systems, all happen in terms of functional units and so changing our workflow to use a more component oriented method, methodology is really just following these boundaries that we're already there.
Previously, you would have have CSS, you know, headline, headline, text, that's just in a big CSS file, you have a bit of markup, that's just been in a big HTML file.
The only thing that ties those two things together is the fact that they have the same name, but they just live in a global space.
And as benefit, you get to generate these hash class names that will never collide, and therefore you have solved a huge problem of CSS maintainability but with taking only a really minor, incremental step of practise. Style components is the next step.
This is a website, a docs page; docs are actually really good since version two. It's well worth checking out right now, it's quite mature. Version three isn't gonna change too much, it's just gonna be faster.
Styled.h1 will, React component will render a h1 with whichever CSS you give it.
And what that lets you do is, it lets you make better use of you component building blocks.
One of Mark's last examples was quite similar to this. These kinds of names, these kinds of APIs aren't direct HTML names, but they're a lot better than working with what the HTML that requires, that gets generated by them. The HTML is more familiar to most people but I would say that the example on the left, the React components are more semantic because they're words, they're terms that are meaningful to you and your business and your team and the project and the goals of your project, rather than the set of HTML elements permitted by HTML. You could also intertwine the naming so that buttons or links can be renders as buttons or buttons could be rendered as links depending on their purpose, but really just the idea is that you've stripped away anything that's not relevant to the actual UI you're describing.
So that's the first goal, is to codify the best practises, decide on the things that you're trying to capture and the things that you're trying to expose, and the things that you're trying to make easy, so for me, it's encapsulation of the component, the semantic naming, and colocating all the styles.
So rewarding small components because if you're components nice and small, it fits in a one file real easily. It doesn't work so well if your components are huge, but you can break your component up into smaller components too.
Who writes SAS in the audience? Yes, that's good, quite a few people.
Alright there's a trick question, who actually writes SAS, not SESS? SAS without, the one, two, three, four, so four and I think there was probably about 20, 25 people. This is, to me, a really good example.
SAS's first syntax was on the right, has no semicolons, (inaudible) but once it had introduced SESS, which is a super set of CSS, it took off in popularity and now it's the dominant form of SAS.
What SESS lets you, is it lets you take a CSS file and lets you change it's extension to SESS, and it works, and then you can incrementally change it.
You can start adding nesting, you can start adding variables, you can start adding x and y and z. To me that's an incredibly powerful concept. It says to people who are are already comfortable with CSS, here is one step; this is not like, you don't have to take your files and convert them and then move everything across and then suddenly you get some benefit, it is, take what you're doing now and then incrementally improve it.
Now we don't support of SESS but we do support nesting and the ampersand symbol.
Takes a lot of work to support even that much, but, for me, that was one of the most important parts of the offering. It also means that you can copy, paste your CSS across, which if you're going to experiment with this and you've got an afternoon to spike it out, you'll get a lot further being able to do that than having to go to the left-hand side.
And then hopefully, you'll see the benefits and you continue on with it.
But I talk about this as saying, bring people along because this is an explicit decision to make it easier for people who are already doing CSS to use this thing. And the value I see in that, apart from just being nice to those people, is it expands the number of people who can get value from your idea. We can get use out of it, and see the benefits that you're trying to offer straight away.
You put less barriers to entry.
So the next goal was to follow the path of least resistance. Now this is kind of indirect opposition to the previous one because this is valid styled components code if you have a button in two colours, you know option A, option B, then you can add in an extra class like you would in SAS or anything.
And then, use the &.primary to change something about the display of the second one.
In styled components, while the one on the left does work, the one on the right is what we recommend.
It lets you use what's native to React, which is the presence of these properties, like primary. Just use them as a boolean property that you add, and then you can use this interpellation which is the dollar sign, squiggly bracket, and then this function and this CSS block, which looks a little bit kinda new, it's certainly new, and looks a little bit wild but is a better way of expressing that kind of conditional logic.
The advantage of that is that that mechanism that interpellation is exactly the same way that you do everything else in styled components, so you have one mechanism by to inject variables: you can do this for mix-ins or functions, or anything. Always use this interpellation character to change something about the CSS.
And so here instead of styled.h1s and styled.divs and spans, you have styled.views, styled.texts, and again, using, was it yoga, the, the flex box you can use, flex box terms like justify content and line items, and on a native device, those are simulated flex box things. They've gone that far to make it as familiar as possible, which made my job a lot easier.
Now you can write styled components and generate stuff that runs on a phone.
Of course the important part of this, is that this code, this particular component has nothing that ties it to native at all, it just depends on a wrapper and a title, and in this case, that wrapper and that title are native components.
But it's quite easy to see a situation where you could have wrappers and titles that rendered the web, wrappers and titles that render to something else. Sharing these higher level components by pushing more things into encapsulated styled components means that your code potentially is more transferrable.
Mark already introduced ReactXP, I wish it was called ReactME, (laughing) the millennial edition was the best version of Windows. And also React Sketch app which is really, really cool. Styled components now supports React Sketch app through React Primitives.
This is all really cool, but I can skip over it and save some time.
So that's the idea following the platform, so don't trying to match something that's halfway between what's familiar and what's ideal for the platform. That's kind of like, so it starts, it's my attempt to hit that in the middle, and you know, you might think I missed one way or the other, and there's other libraries that aim at a different point, but that's something that I had in mind.
The next thing, and this is something I just put in yesterday because I actually really wanted to talk about it, but I don't really know what I'm gonna say. Everybody likes Webpack and Babel, right, but there is a certain problem.
Thankfully there's been a shift, and about 12 months ago there was a project out of the Facebook team. It's the first time that Facebook have released an open source project that they don't personally use on some production app.
It's the only thing they committed to supporting just for the community for React.
And that's Create React app, which is a zero configuration React Webpack config, everything, it basically will let you build an entire React app that can be production ready without having to even open Webpack.
You can eject and configure and stuff but you don't have to; this is just my favourite thing in the world, and actually it's a big influence on styled components because previously I was doing CSS modules, but with Create React App, there's no way to introduce CSS modules, well there wasn't in the initial version, without ejecting and changing config.
Not that it's bad at the moment, it's just there's a whole thing and this isn't gonna be a standardised effort from Oleg from JSS who's sort of leading it, and hopefully all CSS and JSS things will be able to use the same thing, but that's what we have to talk about yet.
So, the last, I think this is the last thing I was gonna talk about, which is the design goal five, which is don't make things worse.
I don't have a tonne of time to talk about it, but there's this graph that really, I think, gets it across quite well.
As long as you're serving HTML, your end result will be good, and you can use as much tooling as you want behind the scenes.
All the CSS-in-JS libraries, all the fancy stuff in the world, if you serve HTML, you won't have gotten backwards, and that to me, is the baseline. There are three very good projects that I would recommend any of these.
Gatsby is a static site generator, which is well supported, the creator of Gatsby works full time on Gatsby because of community contributions which is great for an open source project to be able to do that. Next JS is fairly new, it's kinda more of a framework, it does server rendering.
Some things are a little bit trickier but it does work with styled components, does work with a lot of React stuff. It's definitely worth checking out.
React Snapshot is a similar thing except it's, without running a server, it simply boots up the app, takes a snapshot after it's rendered, and then serves that as a static snapshot.
So it'll crawl your entire app and generate a static file for every view on the page.
It gives you all of the prerendering benefits of server rendering but with no config changes. But that's still in process and I'll be talking more about that this weekend. I want to take my last five minutes and talk about why I was kind of motivated to do this, because yes, the easy answer is I wanted all these things in one library, and so I built a library that had all those things. But there's something else at play here, and it goes much broader into the community, into the industry. Lea said this yesterday, she said, "It should be easier. "These tools are marking things harder ..." Which is totally right; when every tool add an undue burden of complexity and configuration, when every tool opens a pandoras box of new things you could be doing but you don't know which one is responsible, they make it harder for developers to choose and to learn, and to be confident in what they're doing.
And if you make something accessible to novices, it becomes easier for everybody, and I mean like, you make something easier for anyone, it becomes easier for everyone, is something I've been trying to push towards with everything I'm doing.
She also put this great slide up, saying, showing the spectrum of web development, and as professional web developers, we kind of inhabit the left-hand end.
You might have simple build step, but the main thing there is performance is really sensitive.
For a web app, the performance isn't as sensitive as shipping new features, generally people have logged into your app and so therefore, if the app takes a couple of seconds to load, you're not gonna lose any customers, they're already signed up. It's only if the product does what they want, then they'll probably stick around.
Now, both of those are totally fine, and they're really reasonable solutions to a problem, they're both fit for purpose, but the problem I see is that sharing assets between, the sharing knowledge between them, the sharing staff between them, you might have people who are stuck doing your landing page, stuck doing HTML and CSS, who really wanna come over and learn React, but you're only doing React on the backend, on the web app.
You lose this ability for people to make a gentle increase in their skills, and you lose this ability for their knowledge that might be more design background to influence the web app, and so my goal with a lot of this stuff, is to encourage people to look for opportunities to unify that development. So try to build everything with the same set of tools, so that everybody can share knowledge and share assets. Static and interactive components built the same, so if the different components suddenly has to become interactive, it's not a huge step backwards. Share all the optimizations like using say an image CDN, or at least revision stamping of assets between all of your, between all of your products, and always ship real HTML and CSS, never take the easy way out if you can avoid it, and then you can share everything! In effect, something I'm gonna quote from Mark, this is from the text version of the talk he just gave, which was a great blog.
So, I don't know what the unified UI language is gonna look like, I'm betting on the React community at the moment, that it's gonna be a lot of the great work that they're doing is gonna continue.
Those are the things I think are important to this mythical UI language, and that's all I've got.
Thank you very much.
(applause) (upbeat music)