I maintain @survivejs myself. To keep it manageable, I schedule it through Buffer. TweetDeck is invaluable for staying in touch with people as Twitter's normal client just doesn't cut it.

The content comes from many sources and I try to keep my eyes open for trends. This is something I have to do anyway so why not to share. My strategy is simple in that I try to keep the quality of the shared content high while not sharing too often.

There is likely room for more automation like auto-following and all that, but I haven't bothered to dig into those tactics. There are enough balls to juggle after all.

Thanks man! 👍

I think I've managed to find a good balance. I discuss the approach at the new webpack book freely available online.

Basically I maintain a high level webpack.config.js that combines smaller parts of configuration using webpack-merge, a little utility of mine. There are a couple of interesting advantages to this:

• You codify your webpack knowledge to functions. No need to remember it all once you have figured out good ways to do what you want.
• Given it's all functions, this means you can publish your configuration parts to npm.
• Because you can publish them to npm, this means you can share them across multiple projects. Less maintenance fatigue. You could also push loader dependencies and all that to a package to improve further.

The con is that given it's all functions, there's an extra layer of abstraction between you and the pure configuration. Poor abstractions can often make it harder to understand what's going on. And extra code is always code that can have bugs in it.

This all goes back to the idea that the only way to solve boilerplate is simply to have less of it around. There will always be some boilerplate code around, but you can manage it to some extent.

I am currently suffering from boilerplate across my React component projects so the approach will become very handy once I get around to refactoring them. That will ease my maintenance efforts a lot.

It goes all the way to 2013 when I wrote a tiny JavaScript guide under the name. I saw JavaScript as a jungle back then and the idea was to provide something to help survive it. Hence the name.

I haven't dug into WebAssembly or asm.js yet. There is a huge amount of potential, though. We wouldn't have to target JavaScript if we want to develop for the web. Instead you could transform to WebAssembly directly from your source language. I can see this could be a huge thing performance-wise and probably a great thing for language developers too.

I think JavaScript will remain relevant for quite a while. WebAssembly just might open new opportunities to developers. It might also bring more people to the platform and keep the scene vibrant.

I would need to experiment more to give a more specific answer. But overall I see WebAssembly as a good step given they have gotten major browser vendors on board. We have seen efforts like Dart earlier, but they failed due to the lack of support.

It's not enough if only one vendor is behind a technology. You need the biggest ones. Even SVG was stalled for years because a single vendor was missing. If they can avoid that with WebAssembly, it can work.

The web has one huge challenge - legacy. I feel that's going be the case with HTTP/2 as well. It will definitely take time for it to reach enough support so we can start truly leveraging it. For now we are in a mixed state as you still need to consider older browsers not supporting it.

It is true some of the current best practices will become quite the opposite if/when HTTP/2 attains certain threshold. Given it's a streaming protocol, it will change the way to think about loading assets. It's possible bundling becomes far less important then, or at least the techniques will change, when this happens. For now we are stuck with bundling.

No Standard Module Loading Mechanism Yet

Even though we received standard module definition for JavaScript in ES6, we still don't have a standard mechanism for loading modules through the browser. For HTTP/2 to become mainstream, this is something that we will absolutely need. SystemJS could fill this niche, but we'll see how it goes.

Web Development - Always WIP

I expect it might take at least a couple of years till we reach a good, stable situation. Though knowing web development, perhaps there never is stability. Some part of web development is always under construction like those sites in the 90s.

It takes tons of time for sure. The effort has gotten to an interesting stage for me as it's less about pushing and more about pulling. I don't often have to think about what to do as there are clear tasks and goals ahead of me. So it's about listening to the community and following the pull.

Here's a rough outline of what a typical day might look like. No two days are ever the same, but this should give you some idea:

1. I wake up pretty early, around 7:00, add +2 during Winter
2. I check out gitter and email for particular tasks. I also check my newsfeed, Slack, Twitter, make notes, and push interesting bits to OmniFocus. They'll go to various Twitter feeds from there.
3. I decide on some daily goal (minimum) to set focus. I maintain task lists at OmniFocus so I have a better idea of what I should be doing. I keep all my tasks there (GTD style) as otherwise I might forget something important.
4. I work towards the goal till lunch. I do my best work at the morning so I try to tackle something needing lots of capacity here. It doesn't work if you leave hard work later.
5. I grab quick lunch, might even cook something.
6. Work continues till dinner. Better leave easier tasks here. I take a little break every now and then to socialize a bit through channels (gitter etc. again).
7. Work continues until I get to sleep. If there's not a lot of energy left, it's better to do something else instead of getting frustrated. If you try to work tired, you just make more work for yourself and that's something I want to avoid.

To break the routine, I prefer to take a cycle ride or go trekking to the forest every once in a while. Especially as the weather gets better during the Summer, it's too good to waste. When it gets to the Fall, I might go and pick up some mushrooms for lunch. Chanterelles are easy.

There probably are parts of the day that could be more efficient. I could batch certain social media bits to a certain part of the day for instance. Sometimes breaking the habit is good as well. I do that by participating in various events and working in another place for example.

Coffee or tea?​

Tea.

Books or movies?

Movies.

Early bird or night owl?

More of an early bird, though I can be a night owl if absolutely needed. The next day will be horrible, though.

Ketchup or mustard?

Mustard, preferably dijon.

Board games or video games?

Video games.

Cowboys or aliens?

Why not both?

Star Wars or Star Trek?

Star Trek of course.

Detailed or abstract?

Something in between. There's an important link between the two so it falls over from one to other at certain point.

Call or text?

Call.

Asking questions or answering questions?

Answering questions. If I have a problem, I'm too shy to ask and rather research the answer myself.

I feel a lot of complexity lies in understanding the ecosystem and being aware of what exists. That is something I wanted to tackle with this effort. I wanted to bring separate threads together into something coherent. Interestingly the effort has taught a lot to me as well. Often community is smarter than me. :)

You can definitely pick it all up from various online resources, but there's always the trouble of hunting them down and making them work for you. And this material gets old quite fast! It's bit of a challenge for an author to try to keep up with the progress. That's something I've wanted to do with this effort. I see it as a long term commitment.

You Can Choose What to Learn

It's good to understand that you don't necessarily need to learn webpack to get started with React. You can just pick up some setup and go. It's an amazing tool, though, and eventually you may want to understand it in greater detail. I am in the process of splitting up the book to highlight this fact and make it easier to learn the nooks and crannies of it. It's good to be aware of its capabilities.

In the near future you can get started straight with React without having to delve through webpack specifics. Or if you don't care about React, you can dig into webpack and understand it in greater detail.

How to Approach

There is no one right way to pick up technology. I feel it depends on how you like to learn. Some people want to go through books on their own time, for some it's enough to study examples. Or you can follow some nice video tutorials to see how things are done. All approaches have their merits and you'll need to find something fitting your learning style.

Sometimes material will just "click" with you and it will make it easier to learn. As an author the challenge for me is to allow this to happen.

Yeah, I agree the book could use more pictures. Often it's an oversight on my part as I've failed to understand some part might use those. Open issues and I'll get them sorted out eventually.

I have some ideas on where to improve (VDOM for instance) but I'm too close to the material to see some obvious spots for illustration.

I'm currently splitting up the first book (still work left with that :( ) to make room for more content. That will be a good chance to improve this department as well.

Dark room in the basement or bright room with large windows?

It depends on the season. During the Winter it definitely feels like a basement as it's so dark all the time even though there's a large window behind me. The Summer can be quite bright so you get entirely different vibe.

There's some kind of a productivity difference too. Winters are mentally harder due to the darkness.

Fancy table and chair combination or some old pieces gathered from friends?

The furniture is quite old. Wooden table (custom corner for extra working space), comfy chair. The chair might use an upgrade.

I bought an Easel laptop stand to help with ergonomics. It helps a ton to have your wrists in a slight angle. If you are on a budget, consider doing something ad hoc yourself. It's a little thing, but once you get used to it, it's hard to live without.

Are you coding on a crazy old machine, you wonder why it's still alive or is it a shiny new gem?

I use a Mid-2012 13" MBA. It's still a decent machine although I would like to update to something more modern once Apple gets new models out there. My biggest gripes with the current machine are the tiny HD and poor graphics performance. I could also use a retina display.

What tools to you use?​

I tend to spend a lot of time in Sublime and vim. I use a split display setup. I have eight iTerms open always split to left/right. I autojump around to set the context right. Editor is always on one half or both.

The setup is simple but I like it as it allows me to use my limited bash-fu and terminal commands while having a good editor available if I need it. I handle git operations through terminal for instance. I tried the Sublime plugin but never could get used to it.

Chrome is my workhorse when it comes to browsers. It has solid development tooling included and it keeps on improving solidly. Perhaps it might be cool to try something alternative like Vivaldi, though.

I have thought about videos. Given the text material tends to live quite a bit still, it would add to maintenance overhead. So most likely I won't be doing videos anytime soon, at least on a larger scale.

It could be worthwhile to experiment with individual videos and dig into specific topics to get experience and feedback. As I'm not a native speaker, it's not going to be as easy as I would like. But just like with books, you have to start from somewhere.

That said, I have certain short term plans that build on top of the material. There is still a lot of work to do and the concept can only get better. Videos are definitely a part of a longer term vision.

I think CSS Modules are onto something. CSS has one huge problem - globals. We have all these CSS guidelines and solutions that have been developed to work around this problem. If you simply remove the problem and default to local scoping per component instead, you have managed to change web development fundamentally. CSS Modules achieve just this.

You can still have global styling, and it can be quite sensible even. But defaulting to local scoping solves the fundamental issue of CSS. In addition, given there isn't a lot of special syntax to learn, you can translate your old skills to the new setup quite easily. This is something other solutions tend to miss as they bring their own abstractions and conventions.

I believe CSS Modules have a bright future ahead of them. The idea is simply too good to ignore. Maybe it's not the silver bullet, but it definitely looks just great for application development in particular.

I remember trying to use it in the early days. Long story short, it was really rough to set up.

Fortunately the situation seems to have improved. I hooked it up with a recent project and it just worked and we were able to access the routing state easily. In the end we didn't end up need it but it was very nice to see how the situation has improved in a few months.

It's an exciting direction for sure. I actually interviewed the author and see the technology promising. It's always the same. You need projects like Cycle to experiment with ideas so they can flow back to mainstream or become mainstream themselves.

Cycle resolves some of my gripes with React. Particularly this is one of those pet peeves of mine and it simply disappears in Cycle. It also brings new problems. How do you deal with cross-cutting concerns like drag and drop? How do you debug Cycle applications through a browser (I mean breakpoints for one)?

FRP Will Grow in Popularity

You can also see the trend in technologies like Angular 2 (Rx!). As a technology becomes more popular, perhaps it will be wrapped into an easier to consume format (I mean API, docs, support). It would not surprise me a lot if we saw even more FRP influence in the near future.

A lot of these ideas go way back. It just seems they need their time to mature before larger amounts of people can begin to adopt them. You can see the same with React. The ecosystem has received a lot of influence from ClojureScript, Om, and all that. React in turn has shaped Angular 2 and other following technologies. And maybe those feed back and force React to improve.

Not yet. I'll need to make a decision very soon about when to cover it, though. It's either Redux or MobX. Going with MobX next would bring the complexity of the book down somewhat.

The book example translates beautifully to MobX. We wrote a little demo if you want to check that out. There's also an interview of the author at the blog.

Thanks for asking.

The effort has forced me to learn a lot about technologies I would have most likely otherwise skipped or picked up later. That's a benefit I didn't anticipate when I started doing this. A lot has happened just during the past year alone and it has been fun to be on the ride.

I Use Webpack and React

I rely heavily on webpack and React these days. In fact, the site is powered by them through Antwar, a little static site generator. I want to publish a solid public version of that somewhere in the near future, but the principles are simple and the source might be worth studying. Think it as the webpack of static site generators.

I used Redux with React on a recent project. It's one of those technologies worth understanding. There's not that much to learn. I see it more as a guideline rather than a library. But that's a good thing as you can shape your application on top of that. I am aware it's not the perfect fit for every project, but it's highly useful if you want an explicit data flow for your application.

Looking Forward

Looking forward MobX is very promising. It does certain things the opposite way than Redux (mutability is ok, references are fine) and it happens to fit Kanban well as evidenced by a demo implementation we did. There's a tradeoff to be made as it's not as explicit as Redux, but that can be a good thing depending on what you are doing.

Conclusion

I think we'll see more development on the scene as ideas from the existing solutions (Redux, MobX, Relay, all that) begin to converge. Perhaps we'll have something completely different in a year or two that makes the current solutions look antique. That happened a couple of times already so I don't see why it couldn't happen again.

It's both a good and frustrating time to be a front-end developer. It's good in sense that it has never been better. But the amount of innovation can be quite exhausting if you try to keep up all the time. I suppose they call it bleeding edge for a reason.

The whole effort was born out of frustration. It started well over year ago when I commented at Christian Alfoni's blog. He wrote a nice post about webpack and I had a few improvements in mind. We realized it would make sense to write a tiny cookbook for webpack/React and go from there.

After a while I proposed the idea to a publisher but they turned us down. As Christian got busy, I decided to start pushing the effort further regardless and here we are. I wrote the full story at Agile Finland blog if you want to dig into the details.

The journey has been far from easy. But the best journeys rarely are. The most amazing thing so far has been how much I can learn from my readers. The process has been full of iteration. The first version of my first book is completely different from the second one (released recently).

I expect the third edition will improve further. I'm currently in the process of splitting it up so that we get two more focused books. So I try to go with the flow and keep on improving both the offering and myself.

It's about Continuous Improvement

I feel this process of iteration and continuous improvement is one of those things that makes SurviveJS unique. The process is open and a significant part of the content is freely available through web. This kind of open/closed model is conducive to collaboration with my readers. The problem is that I'm blind to my own mistakes so it takes feedback to set me right.

When it comes to topics like React and JavaScript, you can never expect things remain the same. In some ways the ecosystem has solidified already, but there are still certain things that are in flux. My challenge is to keep up with this rapid change.

About Teaching Style

To answer your original question about teaching style, it is good to understand that I have a programming background, not a teaching one. I want to understand the individual parts of a system and how they connect together. I like to split things up and chunk them so they make sense. You can see this in my writing and the way I structure.

Especially early on I was too terse on my explanations. This is something I've been improving on as I've received feedback and a bit of coaching from my editor (thanks Jesús!). When it comes to writing, I want to hit somewhere between terse and explanatory enough.

Perhaps the hardest part about writing is to accept the fact that you cannot please everyone. Some will find your work too easy, some will find it too hard. But I'm not worried about this. I'm very happy to know there are people that have found the effort useful. That's what keeps me going.