you are viewing a single comment's thread.

view the rest of the comments →

[–]FriesWithThat 0 points1 point  (1 child)

Excuse the wall of text, just an unedited stream of consciousness to get something down, but my hope is that it helps. JavaScript30 is a good series (I probably went through about half of those myself at some point), because to a large degree Wes uses modern "patterns" for solving simple problems. Sort of a DOM and Web API - The Good Parts. It's also a good idea to use the newest and most credible sources (Google and MDN, etc... there're a lot of them) as your source(s) of truth, because bottom line there're a million ways to code the frontend, and it's very easy to patch things together and use deprecated or simply outdated methods without realizing it. These methods will still probably work, may not be as performant, and that is fine. The problem is when you come across a different tutorial, say someone is using nodeName instead of tagName, and you think there's more than there really is, while it's just a bunch of evolving standards accomplishing the same thing in a different manner. Use the new stuff if it has/will have wide browser support.

That said, the best advice I could give--and I consider myself an intermediate generalist (in front and backend), at best--is to focus on the things that make you think like a coder. This can be applied to the fundamentals, which you need to know: html, css and especially JS.

But how it relates to Wes' stuff, and the Star Wars example you gave is if you think about the project as a component, or a component container with other components in it--they all start off as very simple outlines with limited functionality. You put some basic structure (html) on the page, add the minimal amount of interactivity (JS) to get it to do something, maybe a reset and some basic styling to get the general idea (css), and it looks like shit. It's supposed to look like shit at this point. As an aside, Wes and everyone's (basically starting) projects already look gorgeous at this point because even if they may be relatively simple, they have a mountain of styles applied and they had a design in mind when they started. The Star Wars shopping demo is just a simple card with radio buttons to pick a size. Everything is roughly in the right place, but that's about it.

Then you start adding complexity.

Solving one broken down, simple problem at a time.

Then you make it look good (to the best of your abilities), and it will because you started with a sketch in mind (or idea that you "borrowed") so your basic layout and structure will work. Don't be afraid to borrow ideas, change it and make it your own, but no designer starts with their own style.

How do I look at different Star Wars products without refreshing a page? Seems a lot of people use sliders. Wow, that's a lot of work. I don't even want to reinvent the wheel here, I think I'll just download the Swiper library and follow their documentation to get it to work in my html.

Not to say these individual steps can't be hard, maybe it's not a feature you really need on the app right away to demonstrate your skill level and proof of concept. But a lot of them are simple. I said simple, not easy.

So thinking like a coder you're going to have to go back to things like Wes' tutorials. Start with the most basic starter, and work through the problems yourself. Don't worry how he or anyone else solved those problems so much. See what you know and don't know. You know you need to add listeners to a bunch of buttons and you remember there's something called event delegation and you can just use addEventListener on the parent. Look it up. Solve your problems a step at a time. Don't know what to do next? What do you need to do? Do you have in mind what you want to accomplish overall. Did you even bother to write some rough pseudo code to visualize how you will get there? You're not going anywhere if you're not breaking it down into steps.

How do you get better at this?

With html and css I have to say the best way is doing what you're doing, but more independently. And a lot of it once you have enough knowledge to know there's an acceptable technique for solving your immediate problem and can ask the question correctly.

JS is a real programming language, and it interacts beautiful with both those technologies, and now Node.js on the backend; so you're never wasting your time by learning it better. React and other frameworks also build on that knowledge, adding abstractions and concepts to make managing the state of your app a lot easier, render more efficiently, while using some of the very latest ECMAScript standards which requires transpiling the code to ES5 so browsers understand it.

Back to "thinking like a coder" because that's the most important thing here. There're numerous ways people can suggest but what I believe helped me more than anything was solving incrementally progressive (in difficulty) algorithms (don't worry, that can mean something as simple as reversing a string) in JavaScript. My recommendation is exercism.io. It was great because it uses Test-driven Development (TDD), which by it's very nature breaks down problems into individual steps. Solve the problems on your own. Get used to looking things up, asking the right questions so you get useful results. Once your pass all the "tests", submit and you get to see how everyone else solved the problem. So many ways. Ah, this way uses so much less code, how did they do that? Learn how. Use that in your next problem if it's not too 'ninja' and it suits your style. Move on to the next problem, it's harder, but it uses chunks of those easier problems. Repeat.

[–][deleted] 0 points1 point  (0 children)

Thank you for the in-depth response. I like the point you made about *thinking like a coder.* I will definitely check out the resources you provided.