1. Should I use a framework instead of what I'm doing now
In the video, you addressed the issue of testing a file which includes both DOM manipulation and logic code. This makes sense. Immediately, I wondered if I should be using some lightweight framework that enforces file separation. Do you think I should?
I was intruiged by Neutrino, which to me is less of a framework and more of a config preset. What do you recommend? The goal here is to learn best practices and make sure I have a solid foundation to build from. At work, we are using Node and React, but no one is building projects with both backend and front-end elements. That will be my job, eventually and that's whay I'm trying to get experience with backend. I know enough React to be dangerous already.
2. What to test, and where.
Should HTML be tested totally separate from JS logic? Are there situations when I would need to test them together? Do you have any recommended repos for me to look at to see how this should be setup?
3. What methods/resources do you recommend for learning best practices/patterns.
I really admire your knowledge of best practices and patterns. How did you learn this? There are so many opinions and on top of that so many moving parts (webpack, babel, react, node), each with their own patterns and practices. How can I get a solid starting place with so much stuff happening at the same time in one project?
4. Choosing where to start
I've heard it over and over again that the best approach to getting better at coding is to learn one language/framework/whatever really well, and then move on to other languages/frameworks/whatever. I have done the exact opposite for the past 4 years. I was doing prototyping work so I would jump from Arduino (C) to Raspberry Pi (python/node) to Node/React and just learn enough to get the prototype working. Now I'm suffering from a lack of foundational knowledge in how to work effectively. I can get stuff to work but it's painful and ugly.
If my goal is to become a solid developer (and work remotely if possible), do you think it's best to start in Node/JS the way I'm doing now? And how do I pick what I learn and what I ignore for now. There are too many options and it's hard for a beginner to know the (dis)advantages of each one. I need something that is well-documented, has a good community, and is also good enough for production.
For example, these are questions circling in my head:
- should I learn to build web apps without React first? If so, how far do I need to go?
- should I stop hating webpack and just get used to using it with everything?
- what are the different kinds of testing and when am I supposed to use them?
- Should I learn SQL or NoSQL first? Which SQL, postgres? MySQL? Oracle??
- what makes a "good" API?
- When do I need Express if I'm making a React App?
- when will I need to learn Redux? Is that even the right thing to learn?
- if I want to learn something else that's been around longer (Django, Rails, whatever) is that going to change what kind of jobs I can work on?
- etc, etc, etc.
5. Long-term learning track?
After this project is over, I'd love to get your advice on how you and I might build a plan for my learning. I really like the way you explain stuff, plus you're very efficient with you time. Is that something you would be interested in doing long-term? It could include reading, homework, practice assignments, whatever you think is best.
I've done plenty of tutorials, but I find that the information 'sticks' much better if I have an actual project to build. I would like to come up with a way to learn-by-doing, similar to what we're working on now.
If the project grows I would slice it as I go, and look for reusable modules and logic I can abstract away. It's much easier to abstract away logic when it's needed than the other way around.
One of the core devs of react has a great youtube vid on this, explaining why react api is so tiny. They have a fierce "application process" before they introduce any new abstraction / api point in react.
Angular for example have a huge api, with many things to learn.
React has ... what .. just a few methods?
Think about what is react basically ...
render method, 6 component life cycle methods, the context wrapper (which is barely used anyway), state and setState, props, and that's about it.
I follow this line of thinking.
For testing, writing code in classes makes testing very easy and readable.
The same effect can be achieved with isolated functions, tho IMO testing a class is MUCH easier, maintainable, and intuitive to reason about.
About neutrino -> I wouldn't jump into bed with a auto-magic-config solution before you understand yourself what's going on. After you config a few projects and you feel a bit comfortable, it would be a good idea to see what others are doing.Using an external solution from day 1 is dangerous because in the first time it won't suit your needs, you'll be in deep shit :O
In the beginning I've also UT'd all my logic in react, as in all the functions that are not dom related.
Now I barely do that anymore. Just go with E2E, even tho many people, and actually most of the community prefers UTs over E2E.
The major benefit I see for UTs is if you write them BEFORE the code itself, a la TDD style. For example let's say you rely on an external API to get you some data, and it comes back very messy with deep objects array and what not.
So you write a function to format that data in a way that makes sense for your app.
for that I would write the UT before the code, and then I would run the test in watch mode as I write the function.
This will give me instant feedback if I'm on the right track with my function, and it's much faster than having to switch to my browser and refresh the app each time (manual testing).
So I only write UTs if it will save me development time.
For "safety", it's usually E2E for me.
Indeed it's hard to keep track, with a new shiny framework coming out every other week, and 20 different new shiny modules for each framework coming out every single day.
For me, I was always mainly into app development, and less into algorithms and low level optimizations.
My language of choice was always JS, so I searched online a bit and found this:
https://www.udemy.com/understand-javascript/
4.7 (12,967 ratings)
64,371 students enrolled
So it looked pretty solid to me, and at the time it was only 10$ on udemy.
That's a pretty good course for the internals of JS.
also u can get it for 19$ here:
http://learnwebdev.net/
I also signed here a while ago:
https://frontendmasters.com/
gobbled down on 1.5 speed most of the vids that interested me, and unsubscribed.
Then I got introduced to data-binding through angular, and after seeing how trendy it was and the community that sprung up around it, I subscribed to the leading newsletter:
http://www.ng-newsletter.com/
After a while react was starting to get traction, so I read some articles and posts comparing the two, and decided react is the way to go, so went through some react tutorials and subscribed to the react newsletter:
http://reactjsnewsletter.com/
right now the react newsletter is my main source of periodical education.
I'm also subscribed to react digest which sometimes have some gems in it:
https://reactdigest.net/
other than that, when I approach something new, I lookup some popular tutorials / posts / articles
Also I search from time to time boilerplate / starter-kit projects to see different architecture approaches.
One important note:
I used to have a "frenzy" about improving and going through as much training and education as I can in the shortest time possible so I could be "on top of the game". THIS DOES NOT WORK AND ONLY LEADS TO MISERY. Don't go there brother ;)
Continue developing and dedicate some time here and there for improvement.
Best practices and deep knowledge would drip in as time goes by.
The most important thing for you to learn as a dev is how to learn faster. With that being said, It's better to kick ass in 1-3 things than to be good(ish) in 10.
Especially for remote work. If a client hires you to build an app, he would prefer a world-class app using 1-2 languages, then an okay app using 10.
I'm going with JS because it seems like its' taking over the world (insert evil laugh here) ;)
Almost anything you'll want to accomplish today, someone has written a JS wrapper for that. The demand for JS devs only goes higher in an exponential rate, and the community is AMAZING.
I don't know about other languages, but JS Qs on SO get answered sometimes under a minute. Including react and angular ones.
As for framework WITHIN JS ...
for backend I just use express for everything. It's just a tiny wrapper on top of node, the API is minimal, it's fast and gets the job done.
I had one pure API project in my life that we used AWS Lambdas for, because we needed insane scalability (thousands of complicated requests and DB updates every second)
We used nodeJS for that as well, tho the architecture is different because you don't really have a server, just a bunch of function containers that get called as needed.
But I would say for 99% of apps, nodeJS + express is enough.
Authentication is super simple, and tests are so easy in node it's laughable.
Front end ...
After reading a LOT about react and redux, including a lot from the authors, it really seems like FB hit a home run. All the arguments make a lot of sense to me, and their philosophy really resonates with me.
Their DX is their top concern:
Even the documentation is good (compare with angular which is ... ehm ... fucking BAD)
There's react native, react for ubuntu, exponent, react for desktop, native base, this list goes on and on ...
I don't see react going anywhere anytime soon, but even if react itself would go away, I predict the next big thing will share many philosophies and approaches.
Besides, react is a real tiny wrapper on top of JS, so other then the tiny react API, u r really learning to develop JS anywayz.
your specific Qd:
should I learn to build web apps without React first? If so, how far do I need to go?
I would start with react first, and in a month go with a simple pureJS project.
should I stop hating webpack and just get used to using it with everything?
Webpack is a bitch to get started with, but this is actually a great tutorial from the creators themselves!
https://webpack.js.org/guides/hmr-react/
Actually their new site for webpack 2 has some good guides.
Definitely switch to webpack, it's da future!
what are the different kinds of testing and when am I supposed to use them?
There's API testing, UT, E2E, load testing, performance, integration, the list goes on and on ...
Here's a simple way to approach it:
Whenever you see yourself repeatedly testing something manually, write a test and automate it.
Should I learn SQL or NoSQL first? Which SQL, postgres? MySQL? Oracle??
I've been using mongoDB for quite a while now, and it's pretty easy to learn. DB is really not that important until you have a project that requires scale. When you will hit that point in your career, you will be much wiser about these questions :)
what makes a "good" API?
That really depends on the purpose of that API. if you r building a small prototype for a startup, a good API is one you can write fast and cheaply. If you are building an API for google, time of development and cost is irrelevant, only performance matters. It's all about balance and the specific project.
When do I need Express if I'm making a React App?
Usually it's when you need to store information, and usually the first thing that's needed is keeping track of users in one way or another.
when will I need to learn Redux? Is that even the right thing to learn?
if I want to learn something else that's been around longer (Django, Rails, whatever) is that going to change what kind of jobs I can work on?
I would love to do that long term.
I much rather see someone progress over time, then solving a one time issue.
Best way to learn is to get a job in the field, ideally in a team where there are strong developers for you to learn from, and incorporate core reviews as part of their workflow.
You will actually GET PAID to get your code reviewed by top devs AND go over their code on a regular basis.
Wouldn't that be beautiful??
So I suggest you look for that, and with time you'll see your code gets less and less comments, and at a certain point you'll feel ready to spin apps on your own.
You can also jump right into being a remote worker, you'll just progress slower and probably make less money.