It's just discouraging. This whole thing feels like a farce. I watch colleagues investing time in this and I feel sorry for them.
It's just discouraging. This whole thing feels like a farce. I watch colleagues investing time in this and I feel sorry for them.
I'm pretty sure it will remove the dread.
[0] https://medium.com/the-node-js-collection/modern-javascript-...
https://reactjs.org/tutorial/tutorial.html
This allow you to start off with a great setup and skip the configuration so you can get started with just writing React. I highly suggest starting with official docs before writing these off. A lot of other tutorials are of varying quality but you can trust the official docs for sure until you learn more about the community and which resources are worth it (or just use this https://github.com/markerikson/react-redux-links). It can be overwhelming if you aren't actively following the front-end world but the reality is that you need very little node knowledge and can go a very long way without ever touching webpack + babel. Even then, once you get to the point, learning to configure those things won't take much time and to me, it's worth it for the developer experience.
If you really want to dabble in just writing React code, you can also try these browser IDEs if they float your boat.
However, official vue guide starts with simple examples and jsfiddle[0]
"Wait, I can't learn this until I understand that, but that requires some knowledge of that other thing which is best understood in the context of..." It's exhausting. I have written code professionally in a dozen languages or more on projects ranging in size and scope, but I have never felt so lost as when trying to learn the labryinth that is the JavaScript ecosystem.
I run into similar experience when trying to learn new JavaScript frameworks. Documentation for these frameworks is usually written as if you already are expert in another JavaScript framework. And then it is really hard to understand benefits of tooling they have. I could do simple apps or tutorials but trying to use any of these technologies in a real project is such a hassle that I end up using good ole jQuery. Sometimes, i feel like these frameworks and their extra tools have no real purpose but to help one pad their resume.
Only reason I keep diving into these frameworks is because I worry that if i don’t learn new technologies, I ll be outdated soon.
As a result, the domain of "backend" engineering has bled into the frontend and thus frontend engineering has gotten more complex.
If you purely want to learn React in a way that allows you to do some light modification of an existing architecture then something like create-react-app or some browser codepens will be the best way to get involved with the library.
Otherwise, if you want to understand React from a more fundamental sense, going away and doing some backend courses or learning some basic CS and/or FP architecture may serve you well in understanding the paradigms that inform React's design. As a bonus, these skills will never be useless.
As for JS tooling, it's not ideal and is definitely a lot to learn all at once. Your best bet is to abstract over as much as possible and learn only what you need to when you have to. Though, again, the skill of picking up and using new tools is a valuable one in this line of work.
1. https://www.youtube.com/watch?v=utJGnK9D_UQ
But the last time I needed something a little complicated I ended up using VueJS. If you don't want to do it the "right" way (ie, a whole build system and such) you can just toss the file onto the page with a script tag and get to work with your scripting wherever you feel good about doing that.
The "wrong" way, in this case, is not only the "right" way, but the only way. Any javascript framework, no matter how esoteric or abstract, has to wind up generating one or more javascript files to be called by script tags in an HTML document.
And any framework that recognizes this and just tells me up front where a prebuilt script is that I can just include and use is a plus in my book.
And I agree with your assertion that it's nice to be able to shove a pre-built script somewhere... but I've been working on toy react/redux apps and I feel like no, that would miss the point of the tooling and workflow that I want to learn.
Something like create-react-app that is supposed to help you learn react. Set it up and just look at node_modules. Just a shit ton of dependencies and you have no idea what any of them do. All this sort of scaffolding set up that you're supposed to ignore.
I just can't learn that way.
Yeah, good luck going through legal/license compliance audit in any serious company doing software.
The one sticking point was webpack 1; they had some dependencies with unlicensed dependencies. Fortunately, we were already leaning towards browserify anyway at the time. Webpack 2+ resolved those issues.
If that happens, and it probably won't, but if it does you will have a team capable of dealing with the issue by then.
Is it even possible? I once checked perhaps at the depth 5-6 and it reached maybe thousands of items. At some point though there were many repeated dependencies, sometimes on different versions of the same module.
ES6
Route based lazy loading
Some sort of typing (TypeScript or FlowType)
CSSModules
React with JSX
Redux
The reason it’s been so difficult is because we’ve had a sort of Wild West mentality where we want to throw everything at the wall and see what sticks. Hence the extreme configurability of Webpack. But this seems to be the preferred configuration. I speculate we’ll see a more turnkey build pipeline in the next year rise.
https://github.com/parcel-bundler/parcel
It's still missing a few things like dead-code elimination.
It's ok though because you got to keep up with the benjamins or become a useless dinosaur in this field.
There's an aggressive/paradoxical luddism in tech that I'll never understand, considering that it is the tech industry. How many great tools/frameworks have come out over the past decade and how limited would you be if you ignored it all?
If you are currently working and using no frameworks in your current job you better learn them before looking for your next gig. Because if you don't you are no longer relevant .. .speaking from current job hunting experience and 30 interviews yet no offers.
The second reason is that nobody (as far as I can tell) seems to be hiring to train anymore. They just want full capacity from everyone and there’s a lot of myth out there about how an unskilled contributor can be a huge detriment.
I mean yeah, that's done on the backend as well, but that's generally not what people mean with that term.
The number of projects is simply a sign of how popular the language / platform is (is becoming).
When you start to understand / recognize the different "types" of projects you'll see they all (generally speaking) fall into probably less than 10 total categories of projects.
Your goal is not to understand all of them well, but to understand them well enough to know which ones fit their use cases the best. When I think of these things in this way I can generally dismiss ~90% of the projects after I've read a handful of pages of their documentation to know whether they're on the right track or not.
Then, for the ones I've dismissed, if I start seeing those projects pop up more and more on forums like HN I might reassess, but other than that once you get over the steep edge of the learning curve it's no longer intimidating to see so many projects popping up in the ecosystem.
EDIT: Or just get your skills to a point where you're confident enough that you understand the fundamentals well enough that you can fit into any project no matter what front-end libraries / frameworks they're using.
"Pure JS" and "Mostly via jQuery" are actually at odds with each other in your description. jQuery itself is a huge library/framework and requires at least as much specific knowledge as any of the frameworks you list. The main difference for you is that you already know it, and so it seems simple/obvious/unencumbered/whatever. Understand that when people describe their framework of choice they are coming from exactly the same place you are. Their preferred setup seems simple, obvious, reasonable and everything else is bloated, complicated, and foreign in comparison.
Especially when you are at the start of your career, or if you have had a career made up of pretty much the same thing, it's easy to see the world outside your sphere as confusing, complex and unnecessary. The computing world changes quickly, though. People complain about the JS world, but it's not really as crazy as most people make out. In my career, I've been paid to work with no less than 15 programming languages (and probably more that I'm forgetting). Each of these programming languages come with multiple ridiculous frameworks. How many X Windows widget libraries have I used? Windows? Old Mac? OS X? Java has it's own! Web frontend frameworks? Then how many DB frameworks? How many communication frameworks? How many IPC libraries? Seriously, I'm just getting started.
Programming is programming and if you don't want to be constantly learning new things, then this job is not for you. I don't for a second think that's the case ;-) Every one of us gets "new framework fatigue". This isn't Pokemon. You don't have to learn them all. However, you should keep learning new things that interest you because each one of these things has valuable ideas in it. Each one uses a technique that you can use later in your career -- even if you aren't using that framework/library. Similarly each one of these frameworks and libraries has huge drawbacks. Really understanding those drawbacks makes you a much better programmer.
I've got a lot of friends that are still DB2 programmers. Others that are MFC programmers. There's a good chance that if you are under a certain age that you don't even know what I'm talking about. They have to hang on to their jobs with a death grip because they will never get another one. Move on. Learn new things -- you don't want to be like my friends.
P.S. I have used almost everything you've listed -- except jQuery. :-D
Have you looked at the standard Vue tutorial? It uses nothing but pasting code into a blank HTML page, a jsfiddle, or the tutorial page's JS console. It's extremely well-suited to someone who isn't already familiar with node/bundlers/etc. And it gives a surprisingly thorough introduction to Vue.
With so much base stuff baked into that base, it makes it difficult to add new components and really understand what's going on.
Still I'm glad my first step into Vue is through an electron app so I'm not dealing with figuring out browser comparability. Still it makes me sad we don't have very many cross-platform desktop app tools, that we have to use electron and package a 100MB web browser and VM as part of our app.
Slack, Discord, etc are all at least 90MB. That's kinda messed up.
Sometimes I think web devs specifically and devs in general forget just how much you have to know to get started even with something "easy" like Django. You gotta know HTML (it gets new features, too), CSS, SQL, Python, Javascript, and the tools necessary to each of them. You gotta learn all that while a framework abstracts it from you. And that's not even considering the choice before that. Why not Rails or something else? Frontend dev is pretty simple in comparison, you're just familiar with one and not the other.
Node is an interpreter that runs JS on the backend. If you understand what Python or Ruby do, then you understand it. You of course can use it on the backend, but the main reason frontend devs use it is to compile the most recent versions of JS down to stuff that works on browsers. You're free not to do that, but JS has evolved for the better over the last decade. Babel is the main tool people use to do this, and webpack uses something like Babel to "pack" your app/components for the frontend. In a lot of cases, if you are using webpack, you don't need grunt. But both of them are build systems, which all language ecosystems use.
Most of it is optional but quasi-necessary and fits a defined role and need. But don't miss the forest for the trees, don't let choice anxiety get to you. What you want to learn is the underlying model, which is a huge step up from what people were dong 10 years ago. If you don't want to get complicated, there are a few "no choice" options.
1) Use React or another view library without any fancy schmancy tools.
2) Use a small, full-stack framework like hyperapp or Elm. This is the entirety of the model you want to understand, and both are small and easy to learn (we're talking a day if not an hour).
3) Use a bigger, everything included framework like Vue. There's no guarantee it won't be passe like Ember or Angular in five years, but there's an existing community and documented way of doings things.
Pick one of them, any of them, but don't get in that dread of choice. The great thing is once you've learned any of them, the concepts are wide enough that you can pick up another framework really fast. As in I can look at any of these and understand what they are doing the same way you can look at a web MVC framework from 2005 and know the hows and whys of what they are doing in an hour.
The great thing about the churn is it's like Christmas every day. You don't have to pick up any of the new stuff coming out, but I'd rather have options and evolution rather than not. The alternative is stagnation.
It's really fun and empowering. I encourage you and others not to get discouraged. Oh, and don't feel sorry for your coworkers. They're learning new stuff. What's better?
None of this stuff is that much work. People are really overestimating how hard it is, and you realize it once you try it. It's just people aren't familiar.
https://mithril.js.org/simple-application.html
Here's another app in another framework. Hard to get easier. I've built GUI and terminal applications, this is easier than both.
import { h, app } from "hyperapp"
const state = {
count: 0
}
const actions = {
down: () => state => ({ count: state.count - 1 }),
up: () => state => ({ count: state.count + 1 })
}
const view = (state, actions) => (
<main>
<h1>{state.count}</h1>
<button onclick={actions.down}>-</button>
<button onclick={actions.up}>+</button>
</main>
)
const main = app(state, actions, view, document.body)We have paid attention. We're doing the best we can. Until we get HTTP/2 everywhere, ES6 modules and we fix the tire fire that is global CSS... this is what we have to do to make it work.
The web doesn’t look so bad now, does it?
Go to Udemy.com . Buy a couple of courses for $20 and spend a week following them.
After that week, you will be able to start programming in React.
Some people, when they pick a new technology, they choose to spend an afternoon reading half tutorial and then start coding straight away. By the time they finally "get it" and start to write decent code, they already put 5000 lines of spaghetti in production that some other developer will have to cope with in the future.
IMHO, too many developers overestimate their intelligence and write awful code because they didn't take the time to learn well the tools.
Not according to the creator of Redux. His advice is "Instead learn to think in React. Come back to Redux if you find a real need for it, or if you want to try something new. But approach it with caution, just like you do with any highly opinionated tool."
https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
> too many developers overestimate their intelligence and write awful code because they didn't take the time to learn well the tools
No argument there. You do have to go through the entire official tutorial, and I would also recommend the article "Thinking in React", that Dan Abramov referenced above. https://reactjs.org/docs/thinking-in-react.html
I'm not claiming your experience with awful code isn't real, I'm sure it is. But is it because React is difficult to learn? When I learned React I was already good at JavaScript. And I had already learned Angular. Angular took me over a month to start to feel comfortable, and I still felt like I was stumbling around in the dark. The Angular API is very big. With React I was writing code, and code that I still use, within days. And I felt comfortable that I mostly knew what I was doing. When my code got a little more complex, I took a few hours to read about and learn about Higher Order Components. And when I needed routing I taught myself React Router in one day, and began answering questions about it on StackOverflow shortly after. Did I take the time in each case to completely understand the API and is that different from what other devs are doing? Possibly. But the point is that the React API did not take me weeks to learn. It's a simple API and there just isn't much there to learn. The React lifecycle for example has less than a dozen methods. It's super simple. Maybe other devs do struggle with getting such a simple API internalized, or maybe they just didn't go through the entire tutorial carefully enough. With React Router I am constantly answering questions that have answers right in the documentation. So maybe what you are seeing is lazy programmers, not a difficult API. In any case, in the interest of not going around in circles here with a difference of opinion, my most important point was comparing the simplicity of learning a UI library (React) vs. a very complex framework like Angular. React was WAY more simple to learn in comparison. And it should be. It does far less. Fair?
In any case, once something no longer fits your needs, you can change it out with something else, which is difficult if you use something like Angular or React or Vue.
One reason to use web components would be it allows for a much more lightweight abstraction over DOM.
You can still compare idea of React and idea of web components, ignoring everything else, and come to some conclusions.