Container queries is the big one for me, since responsive design in its current form effectively clashes with the component-scoped CSS model.

I also wish we could get a greater focus on local scoping. For example, while we now have variables, they all exist in a shared global scope.

Apart from that, I'm finding that the more I properly leverage the component model, the less I rely on preprocessors. For anything that's left over, I actually think CSS-in-JS is preferable to preprocessors, so I'd be interested to see how browser vendors can better enable this approach.

Definitely, although I don't have much experience in this area.

This is a really interesting question, and I'm definitely not going to do it justice in this forum. I definitely feel myself becoming focused on higher level problems over time. I find that staying relatively close to the code helps keep my feet on the ground, and so far I'm planning to maintain this balance. Whether this trajectory leads me towards more leadership roles or even going off on my own, we'll have to wait and see.

After working with React, I'm completely sold on the idea of embedding a markup language inside of a programming language rather than the opposite. Trying to turn HTML into a programming language, writing code inside of attribute strings, feels like a step back to me.

Cats—they fit much more easily into a life spent in front of screens 😄

Thank you! 😄

It doesn't do cross-platform styling well (React Native, React Sketchapp) compared to CSS-in-JS.

It also forces all of your CSS to be static, which I think is often a good thing, but it occasionally gets in the way when trying to build low-level reusable components—having to generate the CSS for all potential consumer states ahead of time is less than ideal.

For a lot of projects, though, these are very minor points, especially since this is also true of all traditional CSS approaches.

Definitely. I've experienced it myself relatively recently, especially when CSS Modules gained in popularity to the point that I didn't have the free time to stay on top of all the activity on GitHub. That, coupled with my very busy work schedule, and having young kids at home, meant that I was stretching myself too thin, and the open source guilt was really dragging me down.

Switching off for a while and making more space in my life was the only way out of it for me. It took me a while, but I've learned to ensure there's always enough slack time in my schedule. I try to do as much as I can during work hours so that I can tune everything out afterwards. I love open source, but doing it in my spare time wasn't working for me anymore, so I've instead focused on getting more open source activity happening during work hours, which has worked wonders for me.

I know about it, but I've never used it personally. I think it's a really, really interesting idea, but I find the interface a bit too awkward for my tastes.

The initial concept was built on top of the idea of locally scoped classes in Webpack's css-loader, which was an experimental feature at the time. You had to manually opt in to local scoping via a special syntax — :local(.foobar) — which we quickly adopted throughout our entire codebase. Almost every selector had this syntax, so I had the idea of creating a PostCSS plugin to automate it (github.com/markdalgleish/postcss-local-scope was the original repo, but this now redirects to an official CSS Modules repo).

The initial journey was really exciting. As soon as we converted our project to use local scoping by default (it wasn't officially called CSS Modules yet), we knew we were onto something really big. It had all the hallmarks of being the next big thing because it struck the perfect balance between code quality and mainstream accessibility. Tobias Koppers from webpack reached out to me, and I was able to convince Glen Maddern (of styled-components fame) that this approach was the future of CSS. To see it take off so quickly was incredibly exciting for me.

I'm not really involved with CSS Modules anymore—it's taken on a bit of a life of its own, with new people jumping in to keep the momentum going. That said, I always imagined that CSS Modules would remain very stable. At the end of the day, it's a module system, and you don't really want it to be changing too rapidly, if at all.

Mentoring is very important, but I think it's best coupled to an open source workflow that forces you out of your bubble. You can learn very effectively by looking at other projects online and then creating your own. With package managers like npm, you can easily create and publish tiny utilities, whether they're standalone libraries or plugins, and share them with the world, get feedback and iterate. In some sense, this is just an open, asynchronous form of mentoring, and one that works surprisingly well.

I've got two young kids—Eva, who's 4, and Owen, who actually just turned 2 on Friday. They take up the majority of my free time at this point, but they're the most rewarding part of my life, by a long shot 😄

I just shared it on Twitter so you can see 😄 twitter.com/markdalgleish/status/8997497900486983… - I've got a 15" MacBook Pro (Mid 2015) hooked into an external monitor on either side, with an external wired keyboard and Magic Mouse.

My work desk is an electric standing desk, which I really, really love. I find it a much more natural position for working—it makes me feel more awake and energetic, which helps when I'm deep into the code.

The apps I have open most of the time are Atom, iTerm, Chrome, Slack and Radiant Player (for Google Play Music). In terms of music, I always have the obligatory headphones at the ready, since I'm in an open plan office but I also like to actually get stuff done...

Already answered this one :) hashnode.com/ama/with-mark-dalgleish-cj6feo72s00l…

To me, they're the perfect sign of why React (or at least, the React model) is here to stay, and why there's still so much we can do with it. Love the work you're doing in this space 👏👏👏

Melbourne has a really great tech scene, and it's been growing even stronger for a long time now. So many meetups and conferences, a good variety of large companies, small startups and co-working spaces to choose from. We also have quite a number of active open source contributors, so it feels like we're right there on the bleeding edge too.

For me, what Melbourne has to offer is a really great lifestyle balance. It's a fantastic city to live in with really vibrant culture, and I love raising a family here, so being able to also maintain a fulfilling career here makes it an extremely attractive place to work.

We certainly do, and it's working really well for us so far. It does a great job of making typography a first class part of our design system, ensuring that all text sits correctly on baseline, and even warning you when you nest multiple Text components incorrectly.

I was a big user of Angular before React came along. I really enjoyed it at the time, but managing the syncing of scope objects between directives was always a massive pain point. React's component model was such a welcome change for me, in this regard.

In terms of what I'd recommend for beginners, I'm not sure. When I was new to programming, I actually struggled when frameworks were too large, with too many concepts to learn. If I had to teach someone front-end dev for the first time, I'd probably stick with React which has a much simpler mental model in comparison.

Personally, I consider this a good problem to have.

I started working in the front end space long before we experienced anything close to fatigue, and believe me, it's much better now. We have an incredible amount of innovation going on, with so many large problems still yet to solve. To top it off, we're building on top of an open platform that continues to evolve beneath us.

I would be more fatigued if this was churn purely for the sake of it, but it's completely the opposite. I'm able to build products I could only dream of a decade ago, and so much of that is due to the tooling improvements we often take for granted.

10 years is a really long time in this space. To be honest, I wouldn't be at all surprised if we're basically not writing JavaScript in 10 years, particularly with things like WebAssembly coming along—but who knows.

I'm hoping we see augmented reality take off within that timeframe, with AR glasses (or something similar) going mainstream. The tech isn't there yet, but it's getting closer every day. Freeing ourselves from the confines of flat, relatively small rectangular screens sounds like a really exciting future for UI, and it would have a huge effect on how we think about the web and on-demand interfaces.

To be honest, I'm really not qualified to comment on this topic, and my opinion may change over time as I spend more time thinking about this, but I'll at least share my gut reaction to it.

To me it seems like a defensive play by Facebook and it doesn't worry me, personally. If I could choose, I'd probably prefer they use a more traditional open source license, but they're of course free to license their software however they like. I still happily use React and don't plan to change any time soon.

Not sure where that puts me in terms of "for or against" 😄

In terms of design on the web, I find the majority of it centres around typography. If you can make a page look good with black text on a white background, you're most of the way to being a strong web designer.

Read books, look at typographical hierarchy libraries, read their source code, experiment. Most importantly, keep your eyes open! You're looking at web typography on a daily basis, so pay attention to it. Whenever you see typography that you like, try to deconstruct it. What do you like about it? Why does it work? How could you break it, and why? Feed this back into your experimentation. Do this for long enough and you'll find your design skills naturally improving.

CSS Modules are really most at home when using a module bundler like Webpack, and using JavaScript to generate your markup (whether that's in Node or the browser). You can get it to work in other environments, but it might take a bit more work.

In terms of architecture, while you can technically organise your styles however you like, CSS Modules is definitely designed for use within a component system, so a component-focused library like React is a perfect fit.

The other aspect to consider is team size and experience. Even as someone who's been working with CSS professionally, I really enjoy the constraints that CSS Modules forces on me. My appreciation for this reaches a whole new level when I'm working on a team of mixed front-end experience, where team members come and go, and we can't expect that everyone is a CSS architecture expert. CSS Modules has a really great effect of lifting the baseline level of quality within your project, ensuring that your styles can actually be refactored by severely limiting the amount of coupling between components.

I just kinda stumbled into it, actually!

I went along to my first MelbJS way back in 2011, I think it was. At that time it was being run by Anette Bergo from Thoughtworks, but she moved to Europe not long after that and needed to hand over the reigns. A few of us stepped up, including myself, but I ended up taking on most of the responsibilities. I created a new website, set us up on Lanyrd, started organising speakers. It really just snowballed from there, and I'm still going today.

I really love organising these events, helping to build a great little community, and JavaScript is such a rapidly evolving space that there's never a shortage of things to talk about.

You can see every one of our events on Lanyrd now, which goes all the way back to July 2012! http://lanyrd.com/series/melbjs

In terms of performance, CSS Modules is a really great balancing of concerns. Of course you get all the benefits of locally-scoped CSS, but when compiled for the browser, CSS Modules performs exactly the same as regular CSS since there's literally no runtime. It just generates a static CSS file, and your markup then references it like you normally would.

For my needs, I find this particularly useful in a large organisation where we need to settle on a common way of building UI components that can be shared between teams. Being able to generate components with co-located styles without incurring a performance or bundle size cost makes it a much safer bet across an entire company.

If you want to use React Native to share your styles cross platform, I'd go with a CSS-in-JS solution instead.

At the other end of the spectrum, I probably wouldn't go with CSS Modules if I was working on an older tech stack without a proper front end build system, which would make it hard to integrate.