It is amazing what a great year this turned out to be. I launched this site around July. Since then a lot has changed. While the situation might have looked a little desperate back then, I feel we are on a sustainable track now. And there is still a lot to come.
If you've been wondering about the radio silence, a lot of it has to do with the React Indie Bundle. We got a couple of smart heads together and decided to launch something that would work well as an entry point to React. In order to support the effort, I launched a little campaign of my own. I thought it would be fun to summarize some of my efforts, so here we go.
I don't present a lot. There simply isn't a lot of demand for presentations locally so it makes sense for me to focus my efforts on coding and writing. That said, I'll do my best if I get asked to talk about some topic.
Earlier this year I was invited to talk about the state of frontend in 2015. Even though that was a couple of months ago, a lot of the points still stand. The slides work best in Chrome.
It's more of an overview. This was an interesting year in front-end and I can only imagine what 2016 is going to be like.
I know this presentation didn't contribute to the bundle directly. It just felt like something fun to mention.
I was invited to talk about my book a week ago. Even though the recording of my presentation is in Finnish, you might still enjoy the slides.
It's more about the business side of things, but having that sort of understanding doesn't hurt. Especially if you want to write a book of your own.
Webinars are tough. In addition to potential technical woes, it can feel strange to talk to an audience you don't see. Regardless, I gave a little introduction to React in a recent one we did to discuss React.
The slides get to the point. In short, there is not that much to learn in React itself. It's more about learning how to deal with the ecosystem as a whole. I feel we're still in a discovery mode as new, better solutions to complement React come along.
This is in contrast to approaches enabled by popular frameworks. The framework approach itself is very powerful. Rather than having to splice things together, you just follow the conventions. The potential problems begin as you need to go beyond the initial design of the framework.
Keeping up with the framework's development can sometimes be a daunting proposition as you need to drag all of the project forward. A library oriented approach allows you to modernize your project one dependency at a time. This seems more sustainable to me over longer term.
I am sure both approaches are valid depending on the situation. And sometimes the approaches overlap. It may even make sense to construct a "framework" of your own out of libraries you like and then standardize on that. In the end it's about the constraints you want.
Given I'm a little stronger on the writing side of things, I put some conscious effort to that. Writing some guest posts felt like a good way to generate some interest towards the bundle while being useful to the community as a whole. I've listed some of my efforts below.
CodersClan is a little service meant for getting small coding tasks done. It fits somewhere between Fiverr and those larger freelancing sites. I decided to give them a taste of Webpack. This is what Webpack - Bundling for Fun and Profit achieves.
If you have read my book or understand the basics of Webpack, there's nothing new here. It is an entry level post after all.
I wrote an entire tutorial for MaxCDN, a popular CDN provider. Building a CDN Reporting Application with Webpack and React shows you how to build a little reporting application to understand how your CDN is performing.
Again, this is a 101 level post that's meant for beginners. Beyond that the API mocking idea might be worthwhile.
The cool thing about front-end development that you don't need an actual endpoint to work against. You can just generate the data that looks about right. When the time is right, you will plug in the real back-end. And this will just work assuming there is no impedance mismatch somewhere.
How to Structure a React Project? written for ReactJS News gained some nice visibility through Hacker News. This was surprising given I usually get ignored there. But I'm not complaining.
I think the post hit some nerve. Even though the Reddit commentary wasn't entirely supporting as some readers felt there wasn't enough substance, I believe the core idea of the post is valid.
There simply isn't one right way to structure your React project. It's a matter of judgment. Even though conventions can be cool, I think you should evolve the structure of your project as it evolves. It's about making things understandable, not about following some rules. Rules can be great, but it's better to make them yourself based on the situation.
Over longer term the community might begin to gravitate towards certain structures. That's fine, though, as it tells something about maturity. As we begin to understand better what we are doing, structure emerges. I believe this is one of the pain points for people coming from more structured environments.
I hope you enjoy the material. Now that the bundle is nearing its end, I can get back to normal business. That said, there might be something interesting on the horizon. I'll get back to that when the time is right, though.