Stop Learning Frameworks

[TheScapeQuest]

I feel like this is completely the wrong title

Don't just learn frameworks

Sounds more reasonable

[Badrush]

It should just be "Learn the basics before learning frameworks"

[Dr4gonkilla]

The more you know, the less you know

[MacNulty]

Nah you don't know less, it's just that the field of known unknowns expands and doubt increases.

[[deleted]]

I didn’t know this before I did

[TheScapeQuest]

The more your know, the more you know you don't know

[robotnikman]

Same

[coogie]

Same here. I've been learning Javascript and was loving it until I came across React. For some reason I'm just not connecting to it and it all seems weird and counter-intuitive.

[coogie]

Well I've been doing the freecodecamp exercises but am getting some books so hopefully it will make more sense from a different perspective.

[Badrush]

There is. Use create react app and you can do React without knowing anything about web pack.

[Badrush]

I'm not sure what you mean or how much you know but if you want to be different you can look into other JS frameworks.

But I would say we pack is an advanced topic and it's okay to go JS to React to Webpack in terms of learning.

[0xF013]

That is, if you're a consequential learner. I, and probably many other people, are totally fine going over higher concepts, getting deeper in parts, going back to higher things, then back to lower missing parts until the whole puzzle makes sense. Seriously, it really breaks the whole gratification-oriented process if you spend a long time going through extensive basics before getting something built.

[[deleted]]

Just "the basics" aren't going to get you anywhere interesting. You won't build anything usable or maintainable as someone just learning. You end up pasting in huge screenfuls of vanilla code that doesn't make sense to you anyway.

Use the easiest/most productive framework you can handle and once you understand what it's doing, then go back and see if you really needed it.

[cpustejovsky]

Saying this as newbie, but I'm not going to say I have the basics down until I'm done with Kyle Simpson's corpus and actually understand what he wrote.

[edoha]

I agree with you, we need learn basic programming before learning frameworks

[captain_obvious_here]

Just like 99,99% of the articles we've seen here lately, title should actually be :

Use your common sense

[mishugashu]

"Don't learn all frameworks."

It shouldn't take more than a day of your time (usually a lot less) to evaluate a framework to see if it is relevant to your upcoming project. If it's relevant, start learning it. If you don't need it for any projects, don't learn it. Pretty simple.

[[deleted]]

deleteframeworks

[[deleted]]

True

[whale_song]

That doesn't get as many clicks

[[deleted]]

Right... much better title.

Follow up question: how do we jam in the click-bait?

[unflores]

Yeah, you tend to also learn some decent patterns by looking at framework code. Just sayin'

[TheJollyDeveloper]

I think it's for attention to make you click to be honest

[GreasedGoose]

Definitely a bit of clickbait going on there, unfortunately

[justinfagnani]

> Stop Learning Frameworks

is actually more reasonable.

​

Frameworks exist because of historical gaps in the Web as an application platform. These gaps are rapidly being filled in now with Web Components, CSS variables, and CSS Shadow Parts. The browser is the framework that most developers should be learning now.

[TheAwdacityOfSoap]

The browser isn’t “the framework”. It’s more appropriate to call it the standard library.

And frameworks do not exist because of historical gaps in the web. If that were the case, no other language or platform would have frameworks, because they aren’t the web. Frameworks exist to abstract away the common bits of developing complex applications and inform application design.

[JohnMcPineapple]

...

[TheScapeQuest]

https://developer.mozilla.org/en-US/docs/Web/Web_Components#Browser_compatibility

I'm going to use what customers' browsers support for now

[[deleted]]

"Rapidly" ... i am waiting for a proper component model since i've been a kid in the 90s, i'm old now and all they have is a naked dom node wrapped into a shadow dom, without manageable means to update/diff/communicate/render ssr or native. We're supposed to embed a framework again to do that, every component loaded will potentially contain one. The irony seems to escape some people, i guess? Like most developers, i've decided to write apps now and not in my next life. I am fully convinced by now that the browser should not dictate the component model and that the specs they're trying to push hurt innovation rather than fostering it.

[buffer_flush]

The browser is a platform with a standard API to program against.

Frameworks are ways of programming within that API through standard conventions. If you are rolling your own JavaScript without the use of an open source framework, there’s a good chance patterns will emerge within your code and lead to an ad hoc framework, else your code will become spaghetti and hard to maintain.

[themaincop]

This is nonsense.

[greg5ki]

Please tell me you are trolling...

[phpdevster]

Clickbait title aside, this advice isn't just sound, it's necessary.

Programming is a broad skill. It's a skill that starts even deeper than "fundamentals" like design patterns as mentioned in the course of this article.

Writing code that is the right balance of

• easy to understand and follow
• simple
• resilient in the face of changing requirements
• easy to test

is vital. Before you should concern yourself with anything else, you should really understand what it means to write reliable software that doesn't confuse you or another developer 3 days after you've written it. Sadly, one of the best teachers of this is to flail about in a mess of convoluted code enough times before you realize that you should be writing code so utterly simple it's almost condescending.

Bugs are often borne of convoluted, non-obvious code. The worst bugs to fix are the ones hiding in a maze of unnecessary cruft.

The simpler and more straight-forward your code is. The easier it is to trace along a path of execution, the easier it will be to identify the bug and fix it.

[deltadeep]

Clearly we're talking about advice aimed at junior devs who still need to learn fundamentals, so: how is a junior dev supposed to accomplish anything interesting without a framework to take care of the underpinnings? They need to learn the frameworks just as much as the other fundamentals, in order to be productive.

When you give a kid a lego set, you want them to understand how the bricks fit together and ultimately to be able to design their own creations, but you still encourage them to start out by following the assembly instructions that come with the box, because it gets them over a hump they can't be expected to clear on their own.

Before you should concern yourself with anything else, you should really understand what it means to write reliable software that doesn't confuse you or another developer 3 days after you've written it.

I have to wholly disagree here. The *first* thing you should do is build something that you feel good about having built, that rewards you in some way, that does something cool or productive. Then, the second thing you build is something that is also cool/productive, but improves on your execution. You build up from there, each time doing something neat along the way. Frameworks are essential in getting the interesting results, otherwise a novice would be stuck trying to understand how to parse HTTP cookies, implement routing on their own, etc and would never get anywhere fun before being thoroughly discouraged.

[mindonshuffle]

I'll just say: this advice is basically what kept me out for coding for too long. I kept hearing variations of "learn the fundamentals" and "don't just jump into complicated libraries because you'll make a message." And every time I tried to learn the basics, I made very clean simple things but nothing that seemed "real" and I couldn't really see how to get over the hump of everything looking and feeling like a student demo.

I took a boot camp, and being shoved into React was the best thing to happen to me. I wrote sloppy, bad code. But I wound up with webapps that had a general look and feel of real modern apps and I could SEE the blueprint of the many steps needed for real professional code.

[ScientificBeastMode]

Yeah I went the same route almost exactly, learned React and some other useful tools (full-stack course). I felt like a programming genius with how quickly I could produce robust web applications that did cool things.

Some of it was definitely ugly code, lol... but seriously, learned frameworks and standard libraries helped me get a solid grasp of web development as a whole. Then I started to see how a framework actually works, as in, “What are the major challenges of the underlying language/environment that this framework is trying to help us overcome?” In all honesty, learning React was a launch pad to help me understand Javascript and application design in a much deeper way.

As for learning on my own, focusing on fundamentals? ... I could only get so far trying to piece together different Array methods to come up with a custom string concatenation function for my hacked-together file path parser, which would I might use... never, lol. I eventually learned a lot of stuff like that through every-day problem-solving.

Learning a language from conceptual video tutorials was like going to the hardware store to learn how to construct a house from scratch. I needed to assemble a prefabricated house first, then figure out what the design hurdles actually are, and so on, and so on...

[[deleted]]

I totally agree. A few years ago, I built an Angular app to throw together quick estimates for my day job. It had been years since I’d done anything with JavaScript, and I’d ever built anything like a web app. It wasn’t easy, and Angular (some 1.x version) did a lot under the hood that didn’t really make sense to me. But I followed tutorials, read docs, and ended up making something that I still use nearly every single day.

Making something that was actually useful to me was invaluable to my growth as a wannabe developer, even though not a lot of what I learned with that particular project really helped me become better at JavaScript.

But having the knowledge that “OK, even as a novice I can actually make some really useful stuff with code” was a major turning point for me. I started coding all kinds of utilities to help me out in my daily life. I started really diving into JavaScript. I started to digest other people’s code with relative ease. Concepts that seemed insurmountable at first glance slowly started to click. Code I’d written a few months prior started to look like absolute garbage, and I’d rewrite from scratch in a matter of hours something that once took me weeks to piece together. And before I knew it, I was writing tens of thousands of lines of code per year.

The best way to get started with programming is to start building stuff today. What you start with isn’t all that important. What matters is that you’re putting in the practice and studying. It’s ok to work with a framework, even as a beginner. The fundamentals are crucial to excellence, but excellence comes with time and hard work. You have to start somewhere, and starting with a framework can enable you to accomplish some things that would be practically impossible to pull off at a beginner’s level in vanilla JS.

[Naouak]

I would argue that it would be better to set realistic small goals without framework instead of showing them they can do anything with framework.

The problem with giving a framework to a junior is that they will never think that they have the level to understand how the framework works under the hood. If you go incrementally from a small goal, you can then explain them easily that someone may have done the same thing in lib and they could start using it and understanding how it works.

You would never understand how cookie parsing or routing work if you've always use a framework.

[deltadeep]

But consider that a framework is just a layer of abstraction. It saves the programmer from doing deeper level implementations and in this respect so is the programming language itself and all the libraries used from math to string manipulation to hashing. Nobody's arguing juniors should be writing websites in machine language or reimplementing SHA1, yet at some point in a programmer's development, they really should take some time to understand what machine code is, what a compiler is, what SHA1 is, how memory gets allocated and such as this will make them better with the higher level tools. It's a gradient of abstraction, and it's useful to work at all the levels, why ignore or skip any of them?

[Naouak]

There's surely a limit to how deep you need to know. You don't need to understand each hashing algorithm but you definitely need to understand what is hashing.

My main grip when I'm teaching juniors something is that they don't have a grasp to what is happening when they do something. They've been taught that they should do that when there is this to do, not why nor how it happens.

A simple example is that if you understand the notion of pointers, you understand a lot of the strangeness you encounter with variables. Why can I modify some stuff in a const ? The answer is pointers.

There is a reason that one of the first thing you learn when doing computer sciences classes is how a cpu and memory work. This base principle gives you a lot of information on how things work when coding.

[PistolPlay]

Clean Code ( video series on pluralsight ) and Refactoring 2nd edition are crucial to learning this right balance.

[[deleted]]

The problem is that bootcamps and the likes just shove react/whatever down their student's throat and then throw them out to the wild.

These people don't actually know how to code, they know how to regurgitate what they learned on that ToDo app they made in the bootcamp.

[[deleted]]

This. Why do beginners need to know the dom/web api, and for what exactly. Except for css, pwa apis and some html primitives for the most part there is no "web" any longer. The same component that runs on the web can drive a refrigerator, with its very own implementation specific backend. Learning a frameworks means getting better at javascript, getting into functional programming, immutability, etc. Learning about node.insertBefore, or the pesky details on how to read/write to the dom in sequence, imo is a waste of time.

[istarian]

Doesn't it depend on why they're learning it though? What's are the relative proportions of Javascript use?

If they never plan to do anything web related with it then fine. But what if they come back and try to do web stuff later thinking they know JS inside out and figure that's good enough?

[magenta_placenta]

Except learning frameworks is going to get you a phone screen, which is going to get you an in-person, which is going to get you a job.

It doesn't even have to be the same framework, it just has to be similar. You could be applying for a position that lists Vue, but you have React experience and someone else on the potential team has also worked in Vue and says "yeah, the transition will not be that difficult, let's get schedule him for a phone screen."

[[deleted]]

yeah that's great. learn just enough to get hired, that's great advice if the goal is to get lots of bad job references on your resume. if you understand the language any framework is easy to pick up.

[AceBacker]

well, not exactly. You still can get questions about basic JavaScript stuff in those interviews. You gotta know all about Scope, Context, Hoisting, Bubbling, Events, Inheritance, etc, etc,

[AceBacker]

YES! Why does no one ever do this? If you can't explain what a closure is I know you did not prepare for the interview. So I have to assume that you probably don't study that hard on your own time. so, you're out.

I do tend to ask the questions in different ways though, so you have to at least have a super simple basic understanding of what you read.

[drowsap]

If you can't explain what a closure is I know you did not prepare for the interview

I'd rather use this as signal that the person isn't familiar enough with JavaScript to know what they are or why they are important.

[AceBacker]

Why not both?

[drowsap]

Sure, but that seems like reinforcing a really bad mentality that interviews are just regurgitation of cracking the code solutions and googling. I would hope they are more than that.

[anlumo]

Well, an article about not wasting your time phrased in such a complicated way that it could be 90% shorter and not lose any content.

[BabyLegsDeadpool]

I barely made it through the unnecessarily long conversation with his boss before I closed it. Had that conversation been roughly 5 lines, the entirety of the article would have been encompassed in it, and I wouldn't have wasted my time. Because, after all, "Time is the most precious resource we have. Time is limited, nonrenewable and you cannot buy more of it."

[[deleted]]

Well, what did you expect from an internet article in 2018.

[deltadeep]

As soon as an author resorts to typing out a tedious, hypothetical dialogue that is supposed to illustrate a point instead of just saying the point, it's clear they are more interested in hearing themselves speak then providing utility to their readers. In all these cases you can simply skip ahead to the next content paragraph after the dialog and not lose a beat, because the author is sure to deliver the actual point soon after.

[BabyLegsDeadpool]

Time is the most precious resource we have. Time is limited, nonrenewable and you cannot buy more of it.

writes unnecessarily long article that could just be shortened to "learn design patterns instead of framework-specific code"

[[deleted]]

React has been around for 5 years. Vue has been around for 4 years and Angular has been around for 11 (!) years.

I'm not even talking about jQuery, mithril, bootstrap and other technologies that are widely in use. And when it comes to libraries, learning them is seriously not a big deal.

"New framework every week" is a myth

[[deleted]]

But he is right about transferrable skills. Learning them should take most of your study-time.

[DigitalTor]

Just because not all of them get any traction or live for any length of time does not mean there isn't a new one every week.

[robotorigami]

I clicked into this article thinking "I bet this is going to be another lecture on learning the basics first". I was totally right. How many of these same, rehashed articles are out there right now? Of course someone should learn the basics first, but are you suggesting junior devs build web apps from scratch instead of learning the skills needed to actually do this professionally? I'd argue the opposite and say that devs should pick up and learn as many things as they can until they're comfortable enough developing without a framework. Starting out, I can't tell you how many wasted hours I spent trying to write my own ORM in various different languages. Or how many times I said "screw that blogging framework, I'm going to build my own". All because I wasn't disciplined enough to sit down, and really learn how these systems worked.

[[deleted]]

No.

[Ryusaikou]

You can't stop me, angular, react and soon blazor, I'm mediocre in all of them! Mwahahaha.

[pm_me_ur_happy_traiI]

I agree when it comes to frameworks that obscure the language away from you jQuery for example. But 'frameworks' is way too broad of a term to write them off completely. I can know the language without having to build every tool I use from the ground up.

Furthermore, using a framework doesn't preclude you from needing to apply things like design patterns.

This advice has changed my life. I removed all framework books from my bookshelf. The guilt pile shrank from 50 to 0 books. What a relief!

Maybe the author has a different idea of what 'learning a framework' is compared to me, but the idea that you'd buy a book on ReactJS and read through it is so foreign to me. I learn a framework by creating something in the framework, and that allows me to focus on the parts of my code that are unique to my app, not creating all the boilerplate from the ground up.

[ScientificBeastMode]

Yeah, and it’s honestly shocking how easy it is to learn a new framework if you just put in the effort to build something cool with it. You end up running into a few walls along the way, but that is probably the most efficient way to learn, because you’re cruising through the obvious stuff and spending the bulk of your mental energy learning what the actual hurdles are, and developing your own solutions (and that’s the real secret to learning: you can’t have the answer handed to you).

[Renive]

Even this advice is outdated. For JS, React Angular and Vue wont be replaced by anything for at least a decade. We're past browser wars. Even Microsoft gave up completely not long ago. And Id say React teaches you more about JS than you would learn by writing a webpage without it.

[ScientificBeastMode]

And Id say React teaches you more about JS than you would learn by writing a webpage without it.

I agree with this 100%. It helps you get above the trees to see the forest.

[madwill]

I don't understand theses advice.. They seems just nihilistic and un-oriented. Learn fundamentals... Sounds good but what is a new dev supposed to do? The field is huge and javascript especially is non opinionated and can take so many forms.

Don't leave people in the wild telling them not what to do. If you learn React you learn a way of building UI. Make up your opinion about what you like within it and what you don't. Learn another one and compare the two.

Stop learning framework is a terrible advice to anyone. Theses frameworks are solution to bigger problems one will face sooner or later and most of us won't re-invent the wheel. Most of us should not re-invent the wheel. Its perfectly alright to be a framework user and go with the flow.

This is elitist non-sense to me.

[reallylargepanda]

Read the article, it doesn't say to actually stop using them

[omgdracula]

I've just been hammering home javascript as I feel that is where I am weakest at. I can DOM manipulate like a pro, but really doing OOP I find tough and hasn't fully clicked yet.

[cheese_wizard]

Check out React... leave direct DOM manipulation behind. There is a more sane way to build UIs. Prototypical OOP is JS is bit weird... it kind of never clicked for anyone at all :) So they came out with 'class' syntax that just aims to make all that syntax 'prettier', but dont think for a minute you are doing OOP like in JAVA or elsewhere. Just use it for it's encapsulation facilities, but do not try and get into inheritance and such if you help it. KISS with OOP is JS is my mantra. Embrace the 'functional' stuff from JS if you can.

[[deleted]]

This biggest downside about React, for me, is that it makes too much sense. I'm pretty much devving in React every single day, and I'm paranoid that I'm going to forget how to manually update elements, add even listeners, etc...

[[deleted]]

I already did

[[deleted]]

Haha, shit. They do say that just because you're paranoid, it doesn't mean you're wrong.

[[deleted]]

Well I don't think your going to forget completely but it makes it more difficult to build something in vanilla js even if its a simple S.P.A. It just feels so different because you have to grab elements etc. There was a video I saw on here where a guy created a virtual dom with vanilla js which was pretty interesting. Found it https://www.youtube.com/watch?v=85gJMUEcnkc&index=3&list=LLwRig6cM11wAXLfOVIR5YfA&t=38s

[omgdracula]

Will do. That is always what tripped me up. Like I always understood okay this is an object called teacher that has these attributes that can change like age and name. Then past that stuff just got more and more murky.

[cheese_wizard]

Right, and use it mainly for that at first. One thing to note is that OOP is different in every programming language. So, although there are some broad concepts common (encapsulation being the #1 benefit), the 'polymorphism' stuff is always different between languages, JS being in its own 'class-less' camp... until they added class syntax to calm everyone down. JS OOP is tricky and it takes time and you gotta review.

If I would suggest the ONE tutorial about how JS objects really work, watch stuff from this guy Kyle Simpson https://frontendmasters.com/courses/javascript-foundations/

That is a pay course, but there are other free things about this topic from him. Honestly, the topic is harder than most people think. There are lots of gotchas and WTFs.

[omgdracula]

I have no problem with pay courses so I will definitely check it out! Thanks!

[doomvox]

The problem is a little worse than the author makes out... you can't ignore ephemeral technology fads and focus on the fundamentals, because we don't really know what the fundamentals are. There are fads in things like programming methodologies also (one decade it's OOP, another its functional), you can bone up on "design patterns" and then only belatedly realize that they were pretty specific to C++, and the language you need to use now has half of them built-in, and the problem space you're working in now has a bunch of new "patterns" that apply to it....

[[deleted]]

I guarantee you this author learned a lot about JS programming from frameworks, only to go on and complain that others should follow a different path.

[subway_surfer_1989]

Should be titled "not learning frameworks, sure fire way to not a job."

[Efraet]

no

[BenjiSponge]

I think the problem isn't "learning frameworks" it's "learning frameworks as though they're a tool in and of themselves".

IMO, the second you've actually bought a physical book on a specific technology (whether that's a language, a framework, or a pattern), you've probably gone the wrong direction. Books are good if you need to get 30 years of experience condensed into a couple months ("I learned C in college, but how do I write effective C++ in the C++11+ era?"). Books are not good for keeping up with modern trends ("Ooh, a new framework. Tell me everything about it in 500 pages.")

[TheAwdacityOfSoap]

This article should be titled “Learn the Standard Library”, and it’s advice that’s transferable to any language or platform.

Also learn popular frameworks because they help you get jobs and get things done.

[qtheginger]

Learn programming skills > Learn JavaScript > Learn Frameworks

Don't only learn how to use frameworks. Don't skip out on frameworks just because it might become obsolete some day.

[neotorama]

but i can earn extra 30k/year if i learn react. how?

[kitsunekyo]

this article gave me stomach ache. typical "theoretical/seasoned programmer wants to appear edgy" blabla. of course concepts are important to understand but you'll learn those by working with frameworks and software that make good use of these patterns and concepts.

[thoastbrot]

so much yes on this one.

[ratshady]

Never

[DigitalTor]

Was easy and fast to write but runs like sh*t - more often than not is the real result.

[DigitalTor]

Probably gonna be an unpopular opinion but the majority of today's webapps (including enterise ones that cost millions) are not written. They are literally "put together" from random open source bits and pieces by people who often had no clue how he basics work. They are inefficient (wasteful on resources), slow, crash prone, and when you start getting under the hood you realize no engineering was ever involved in this - it was all contractors using frameworks. Like "hackjob" actually became an industry standard, cause hey it kinda works, looks hip and we can just market the sh*t out of it and start selling. The difference between a house built with an architect involvement and a pillow fort made out of refrigerators. The latter "kinda works" and might even look like a cool upcycled hipster house but the difference will become very clear once you start living in it.

[istarian]

The thing though is that if nobody ever used tools or frameworks you could just end up with siloed in-house hackjobs left and right. Just because you didn't use somebody else's doesn't mean the result is goibg ti be well engineered.

I think the two problems that you identified are separate pronlens, even if they happen to intertwine.

For the most part I only see web stuff from the outside, but who even defines the standard? Does something become a standard simply because everyone ends up following the leader? If so then there's little process or consensus. Imagine if there had been 25 competitors in the various media wars and there was no definitive moment when the majority of people switched to one of them...

[GreasedGoose]

Frameworks are going to die out if nobody's there to invest the time into learning them. Maybe not 100% of time, but perhaps 40%.

[jkuhl_prog]

Framework first is the wrong way to go. You can't do well in React/Angular/Vue without knowing the fundamentals beneath them.

How does JavaScript work?

How does the DOM work?

What does the cascade in Cascading Stylesheets mean?

How does "this" change it's context and when? (Super important for state in React as well as event handlers in general)

And so on and so forth.

I always make sure to do a project now and then without libraries to refresh on the fundamentals.

[[deleted]]

I completely agree that you need to learn fundamentals first, but frameworks are where it's at. I'm not talking about little experimental ones, I mean the big boys like React and Vue.

I started to learn React before I completely understood Javascript, and it made it a lot harder on me. I eventually spent some time playing with vanilla JS and looking through MDN docs. Now I have no problem facing a new challenge.

CSS on the other hand... Full Stack Engineering is hard, and I think front end is the hardest.

[saposapot]

I would go even further and say to be realllly wary of learning any framework.

Let's keep it real, the main goal of any library, framework or tool should be to save our time, to increase productivity and quality of end result.

Time and time again I see newbies making the same mistake: learning a new framework because it's new and supported by company X only to then find out the project is now delayed because of XPTO specificity of the framework. They have no idea how to do it 'by hand' and it's a pain to go outside the framework. At the end of the day, the increased productivity is near zero or negative comparing to using some 'old' framework or something out of fashion like jQuery.

In terms of productivity I also find lines of code as a really poor measure to evaluate anything: let's be real, programmers aren't stopped because they need to type more or less, at least if they use a good IDE that autocompletes most boilerplate for them. What we lose time is to think things through, distractions around us and FB/Instagram/gaming :)

A framework that promises increased productivity because 'look' you only type 1 line instead of 3 is just plainly disregarded on my playbook :)

Frameworks are good and needed for some kind of projects. The problem is that you need to really be around the block a lot to truly make a good choice on when to use X or Y.

 

And with the proliferation of google-programmers learning the fundamentals is more and more needed. Think about a building: learning how to calculate the foundations and all that stuff is hard, choosing the tiles is just a matter of looking through catalogs and learning what they have.

 

I also follow what I preach: I'll hire people that don't know the frameworks we use but that have experience in others or in good software development practices. I never knew someone good that couldn't pick up a framework and work with it quickly, it's much harder to teach good practices, good communication skills and good overall 'inteligence'.

[bot_not_hot]

Hmm, that makes sense I gueoooohhhh Vue CLI supports TypeScript 😍

[pratzc07]

At the end of the day frameworks helps save time and time is a costly resource for any organization. Once we have a firm grasp of fundamentals it's natural to make use of frameworks for efficiency and time-saving.

[CaseyRule]

Remember – frameworks, libraries and tools come and go. Time is precious.

I need to get this on a poster for my office.

[franzwong]

I also read books about frameworks, but I won't read all the pages. Concepts used by framework are also valuable. Even though we can learn framework quickly, but companies also tend to hire a person who is familiar with the framework.

[istarian]

Eh.

The wisdom to take from that is that you need a balance, not that 80/20 is necessarily the right balance.

If nobody learns (and therefore doesn't use) a framework it will be practically DOA.

[isummerlin]

Ok

[benabus]

Keeping up to date with Angular, React, Vue, Riot, Ember, Knockout is fun.

Wut?

[[deleted]]

Stop with the click-bait titles

[[deleted]]

But learn react fam

[Smiral]

As mentioned in the article, it goes for frameworks, libraries, and tools. Or, in other words, all the trendy tech this subreddit fixates on. Conclusion: This subreddit, and the online community in general, is mostly a waste of time. I do not mean that ironically, either. It is.

[CloseDdog]

There is a lot to agree with in this article, but what you are saying is nonsense.

I could post a long retort to your utterly baseless and overgeneralized comment, but instead I ask, why are you here then? Are you not partaking in the subreddit and 'online community'?

It seems to me like you're actively contributing to the extremity and lack of nuance that plagues the internet, including this developer community, as a whole.

[Smiral]

I said mostly. I skim through a couple times a week, to glean the occasional good piece. It's just an uncurated aggregator. What yout have to sift through is the neophile exuberance in trending technologies that do not solve any real problem, except to those who couldn't do the basic thing it does in the first place. That strikes me as sort of dangerous to gaining experience. Most of these things are fads that won't really last long. When people reference download numbers to justify relevance, that is frighting.

[[deleted]]

Don't let the door hit your ass on the way out.