There are many tutorials for simple React scaffolds. But, in real life and in a real project you need a few extra bits and bogs. Building those bits and bogs for the browser is a lot of pain that the simple tutorials don’t prepare people for.
Presenting here a strong React starter project that’s used in our latest real life frontend projects. It adds pretty Bootstrap templates and modals, works with the backend API, and is deployed to Netlify with zero effort.
In the box:
React and Webpack
A Swagger-generated API library, to consume backend services. You can of course generate your own API’s frontend library on editor.swagger.io (or using swagger-codegen).
Bootstrap including jQuery and support for custom templates
Build command that can be used to deploy the project on Netlify (or Amazon S3), for simple CI/CD
Development server with hot reload
ESLint with ES6 settings and built-in support for VSCode
To get started, head on over to the Github project and grab the code for free.
“The willingness to keep trying new things — different methods, uncomfortable tasks — when you are already an expert at something is what separates good from great. Focusing on your strengths is required for peak performance, but improving your weaknesses has the potential for the greatest gains. This is true for athletes, executives, and entire companies.
Non-technical founders ask this question on almost all our TechEye events. How can they hire developers to build a product, if they don’t know what to put in the job specs in the first place?
The answer is that you don’t choose tech. You choose the developer who chooses tech.
If there was a single tech that’s better than all the others in every possible way, surely everyone used that one.
This is not the case: developers have heated discussions about their tech. Go to Hacker News and observe debates. They get as heated as debates on god, vegetarianism or guessing which superhero would win in a fight.
Choosing tech is therefore a two step process.
Find developers who can build the product, who you trust and can work together with. That determines 90% of the technology choices, because no developer is really good at multiple frameworks.
Try to find another developer for that same thing, and make sure that your main dev is happy working together with them. If you find it easy to assemble a good team, only then should you proceed.
The best option for you is to avoid originality in any form. If you choose Django/Python/Rails or anything that a lot of people use, then you’ll always have options. Having options matters life or death in situations where a dev team leaves you stranded.
Other than having options and being able to build a product, don’t worry about tech at all.
Whichever tech you end up using, if you can build a team and a product with it, that’s the right tech for you. An average startup rewrites their entire code base every 1-2 years while scaling up. You’ll do well if you can build a business in the meanwhile.
There are two good reasons to work on an idea almost no matter what:
If you can learn something that you can use for the rest of your life. Be careful with this definition. A fancy new programming framework doesn’t qualify. Learning to write code does. Trying sales for the first time does.
If you can work with people you admire. Even if the idea goes to zero, you can take good relationships into the next project. And the one after, until kingdom come.
Last time we were in New York, we had cocktails in a speakeasy that turned out to be Nikola Tesla’s old basement.
It’s both a coffee place and a speakeasy actually, somewhere between Chelsea and Koreatown. The cafe works as expected, serving proper hipster coffee, and then has a secret moving wall in the back. Enter the wall and queue the cocktails, but the best feature in there is the menu. With Nikola Tesla’s drawings, patents and works, it looks awesome. Long story short, yours truly got inspired, and a few weeks later:
I’ve also finally set up Behance and Dribbble accounts to share all my new shit there. Let’s connect there, folks!
My home-wework at Aldwych has a line of tall desks along the main window. I have to get there early because the best spots all go by 9.25am, but then I can place my laptop in the window, have a coffee and work away, as I watch busy town being busy outside. It’s a great day.
I’m a big fan of standing desks lately, and started to frequent the co-working offices that offer those. I have to work in different areas almost every day, but standing desks are commonplace enough nowadays, so there are some in pretty much every co-working office. These spots are the easiest to get as well, because who wants to stand all day anyway?
Other than in Aldwych of course, because window seats are window seats on an airplane and they are window seats at work too.
I do standing desks in the mornings, have lunch, and then back in the lounge or a normal desk for the afternoon. Tuesdays I’d start the day with a mile swim, and then get to the office by 9am. Those days are my favorite days now.
Not sure whether standing all day is any healthier than sitting all day by the way, so don’t consider any of the above as health advice. With my messed up back I manage to hunch over any surface anyway.
Amazon and Serverless is pushing hard to convince this new generation of devs, that servers and databases are some kind of an unnecessary wizard move.
I mean I think this is a good thing, because managed services are great. Maintenance is usually the easiest to outsource, whilst anything business logic related requires so much in-depth knowledge of the problem, that writing specs often means writing 80% of the service already. Software development time is scarce resource these days, so it should only be deployed on things with the highest impact – managing a Kubernetes cluster is rarely the one.
For my generation of devs, embracing Serverless can be challenging because with it a massive part of our knowledge is becoming obsolete. The goal is not just not having to SSH into a box, the goal is not to be able to SSH into a box at all – so what difference does it make that you know your way around in there? So the world is moving on, managed services are the future, and it’s not even because of the massive scale it enables, but because fuck maintenance, fuck operations, and fuck spending development time on setup.
Compare this all to electricity’s early days, when people ran their own generators. Ask any “sparky”: as soon as a stabile wall plug becomes available, you better start using it.
Now, who’s limited? Whenever you say “We will not do this”, then you lose. If you say “I’m going to do it when I feel like it, and when I don’t feel like it, I’m not going to do it”, then you’ve got choice and you’ve got some basis on which to be in control.
— Bandler & Grinder in REFRAMING: Neuro Linguistic Programming And The Transformation Of Meaning