Bootstrap solves a different problem than jquery. Most developers hate designing (OK most developers I know...) and use bootstrap just to get something halfway decent looking and focus on javascript rather than design/css/quirks.
The rest of Bootstrap is just css however.
Pick any Javascript forum on the internet, even HN comments, if you'd like. The common comment is "Just use React".
The interesting thing is they are not lying: You'll get a job which will last until the new library de jour arrives.
Maybe this is how the job market answers the high demand. I personally have no idea.
I can confirm this.
I work in a large corporate environment and we're rebuilding a legacy application in Angular 1.4. They have no plans of migrating and even talk of moving to 1.5 or even 2.0 I've been told migrating to either 2-3 years away.
The problem I've come to have with this as I get older is... I realize that I have a limited amount of time to learn new things. I still love doing it, but if possible, I'd rather spend that effort on learning portable, enduring, and broadly applicable things than ephemeral arcana involved in learning to do essentially the same thing a different/"modern" way. New learning should be for new capabilities, a better quality of insight, and real advantages.
All that said, I told her to pay attention in the Udacity backbone class. General framework knowledge should let her generalize using JS.
What did you say here? I've been thinking a lot about this lately -- In my opinion, a websites are a part of an 'app': the client.
* If you use FE JS to implement any of your sites functionality then you have an app.
* If you only use FE JS for just presentation logic then you have a website.
Or Vue.
Indeed, I think the best way to learn a coding is motivation. And the best motivation is making something you cherish. To me, it was a music web app I'm still working on. I had tried to learn JS many times in the past and had never succeeded. React allowed me to structure my code (the wrong way at first, I had everything in react components not just view logic, but gave me structure none the less) and think about my UI in an object manner. Moreover, this way, I ran into problems, looked for solutions and learned this way. As opposed to learning solutions and finding problems they solve.
Little by little I got to see why I might need react-router and redux. Redux made my life so much easier (no need to pass state in a hierarchical way anymore, any component can read and modify state of other components regardless of relative tree position, and in a safe explicit way).
After a year of having learned frontend this way, I consider myself a js coder. I made a fairly simple website the other day (just django + jquery) I'm kinda proud of. This web app was the first and only web project I had ever done, and this jquery website was done in a couple days.
My third ever project (I'm working on it as I'm writing this) is a cfd solver in js using web workers and SIMD for the solver and react/redux/d3 for the frontend. I've tried to learn to code so many time to be able to spin up projects like this (in this case, to review and practice my cfd, not build airplanes), and I was never able to because I never had the motivation to finish learning about ifs and loops of whatever language whenever I started reading a book about it.
The hardest thing about learning js through react is that a js beginner wants to user JSX. I came from HTML (a whiiiile ago), so it made (and still makes) sense for me to use JSX (and it made zero sense to me not to use it). The problem of course, is that I had to introduce myself with babel and browserify (because even the latest Safari doesn't understand JSX). But once that's set up, you've already understood about npm and compilation. So you pretty much already know how to use ES# or SASS if you want to use it. And minifying is just a few lines of code and SO answers away.
I guess this has become the story of "how I learned to code", but I wanted to share how starting with a "it's too complex for a beginner" project and jumping straight into react/redux and skipping over vanilla could be beneficial if one has the motivation to finish the project but not the attention span to go through vanilla beforehand. Because one will have to learn vanilla to succeed at anything anyway, but by making stuff you really care about at the same time in this case.
Btw, I think what got me to say "fuck it, I'll jump straight into react and build shit, fuck all these tutorials" was that I read a while ago a quote about the tumblr guy saying something along the lines of "the only way to learn to code is to make a project you care about" and my older brother telling me "learn django, you'll be able to make websites and you'll have learned some python at the same time" (he's an experienced coder knowing I was not).
Might as well call it "vanilla chromescript" if you're going that route. Outright rejecting everything that was built for a good reason is worse than covering up bad skills with a bunch of libraries. At least the libraries actually work
For instance, ever since picking up TypeScript my projects have been much easier to maintain. I'm sure the same would apply with a templating framework, depending on your needs...
You only realize most of the benefits though when working on a large/complex project, or on a team where you're not responsible for most of the codebase, or other scenarios where it's hard to keep the entire project "in your head" at once. If you're just using JS to add autocomplete, pagination, other simple things to a page, then TypeScript may just be unnecessary effort.
Basically, how often do you end up with a bug because of improper types. Or how much time do you spend looking up what type you need to use somewhere. TypeScript is worth it when the time spent on those issues is greater than the time spent learning TypeScript (which isn't very much).
Vanilla js would require the engineer to set patterns and make assumptions, something that junior devs might do incorrectly. You will reinvent the wheel and probably do it inefficiently unless you are a seasoned vet. Not only that but others who are not familiar with whatever homebrew stuff you have cooked up will not be able to just dive in and start putting pieces together without a fair amount of reading. It's not impossible, but hard with a large dev team.
This is why frameworks exist, no? Don't get me wrong I hate the framework bloat and pace of frontend engineering but these frameworks do serve a very legitimate purpose. But this definitely goes against the JS hate trends as of late.
But everyone here is a fairly experienced dev. Working with junior devs is difficult, especially frontend devs who usually lack comp sci fundamentals.
Frameworks provide structure to what would normally be an absolute spaghetti mess, even at the cost of overhead. I would rather have bloated but maintainable code. It's hard to even unit test vanilla js properly. Those who rail against the current framework world forget how bad the vanilla world was...spaghetti code, no real design patterns, terrible class design, no standard lib...the list goes on :(
It's frustrating that the counterpoint to the "framework everything" crowd is the "never framework" pattern. Both are bad for different reasons right? I would never want 10+ devs working on the same project without some kind of framework, either homebrew or open source. But also running react for your tiny little dev blog is equally bad.
I've been designing software for over 15 years and here's some tips that works well for JS and probably other languages too:
1) Avoid code couplings, if you keep couplings at a minimal, you only have to test the code once and it will never break. 2) Modular code: All dependencies should be contained! Dependencies should be branched, not entangled/complexed 3) Independent functions: Functions should not have any dependencies from the outside scope, not even other functions if possible. Use lexical modules and sub-functions. 4) Event listeners: Have independent "micro services" that listen for events instead of orchestrating. 5) Abstractions: Make it possible to use functions/modules without knowledge about the abstracted code. 6) Avoid state =)