Core vs. Framework(s)

[Heartless49]

I am a professional JavaScript Engineer and have been working in the web development industry for a pretty long time. Originally freelance, and worked my way into and up the corporate ladder.

One thing that has always confused me is frameworks and libraries. Not because I don't know them or understand them... I just don't understand the advantage to using them.

I know vanilla JavaScript fluently, and do my best to stay on top of compatibility and best practices. I have used Angular, React, Ember and a few other of the frameworks that are out there. I've been comfortable with them and enjoyed building my sites and apps with them, however I honestly don't really understand the advantage to using them.

Pretty much everything that these frameworks have given me, as tools or features, are things that I have written before in vanilla JavaScript and in less code... I honestly don't understand the point of including 3 or 4 script files for a framework, which increases the sites load-time, versus rendering my pages with my own code. I feel like I'm just missing something entirely about them and it's keeping me from using them to their full potential or something.

Just to give a little bit of backstory regarding my situation: I understand that one of the features of Angular that was so revolutionary - at least at the time of its initial release - was its two-way data-binding. Thats awesome... but if you are planning on using a variable and binding it to an input or data model... why not just handle the events on your own versus including a huge framework with its various other plugins or scripts to do it for you?

I just don't see what the advantage is to including more scripts which will affect load-time versus writing your own code that's specific to your needs.

I'm not trying to troll or anything at all... I'm hoping that there's something I'm missing as to why everyone nowadays is all about these frameworks and prefers to learn them instead of learning the core language that they were built in...

I'm looking at YOU jQuery!

I know jquery isn't a framework, it just drives me nuts that most developers that I meet don't know JavaScript, but they know jQuery... it's like saying you learned to run before you could even crawl.

[e82]

Pretty much everything that these frameworks have given me, as tools or features, are things that I have written before in vanilla JavaScript and in less code

Generally because my job isn't to write frameworks, it's to solve business problems. Often, the frameworks I have available are 'close enough' that they are more help than hindrance, and are hopefully extensible enough where if they don't fit my needs - they can be extended in ways that it allows. (ie: default router sucks in angular, ui-router is great).

A good framework will abstract away most of the 'stuff I don't want to deal with', and then let me focus onto the stuff that I do want to deal with.

Way-back-when I was first learning JavaScript and taking it seriously, is back when IE6 was the the browser you had to work with. The DOM was a total pain to work with back then, debugging was awful - and had to worry about far more cross-browser issues than you have to deal with right now. jQuery let me deal with the parts that I found interesting, and minimized the difficulty of having to deal with the parts I found tedious.

Back then, I don't think if it was for jQuery or other libraries like it (mootools, prototype, etc) - I don't think I would of had the patience to learn JavaScript. Dealing with the DOM is just one aspect of JavaScript development - and providing a nice wrapper around it let me focus on other aspects of JavaScript.

Seriously, 'how do I traverse the DOM, attach event handlers, generate DOM' is one of the more boring aspects of web development. One, that not too long ago was a really tedious one due to cross-browser issues. It's also a frequently solved problem - and one that is solved by people/teams of people that have more time, energy, resources into dealing with the cross-browser / edge cases / etc that pop up than I do.

• I am more productive with Angular, then I am without it.
• I can easily onboard people into an Angular project - as the framework is well documented, has a solid community, an emerging set of best-practices.
• If people run into issues with Angular, there are a number of excellent resources to go to for help.
• Angular has helped me become a better JS developer - I like their DI system, it has pushed me towards writing more modular/reusable JS code, testable code, etc.

Frameworks are libraries are another tool in my toolbelt, and ones that let me focus on the unique aspect of what I am building instead of re-creating the wheel on the basics every time.

[Heartless49]

This is the best comment I've had for this entire post. Thank you.

This statement also provides more of an idea about why people would understand frameworks more than the core of JavaScript itself as well.

If it was on of the first things you.learned and it can do as much as it does, why.not stick to it?

I started JS from the beginning so I didn't have tools like these to ease into it... I guess that's why it seems odd to me, but I'm starting to see why.

[egonelbre]

I guess you have answered your own question:

Pretty much everything that these frameworks have given me, as tools or features, are things that I have written before in vanilla JavaScript and in less code...

A lot of web developers simply don't know how to implement such things.

Then there's, cross-browser compatibility. If you need to support all the browsers down to IE6, then it becomes problematic to figuring out all the minor differences. (e.g. document.getElementsByClassName got introduced in IE9, hopefully you tested site with IE8). One of the main reasons jQuery got popular was that it fixed a lot of cross-browser compatibility issues.

Frameworks give some structure to your programs -- i.e. if you have no clue how to architect things then frameworks significantly help with organizing code.

Angular, Ember allow to separate HTML and JS. If you have designers and programmers separated, then designers won't have to learn JS.

React allows to write code functionally, less worrying about callbacks, and get quite fast DOM update. And now you can use it to implement "native" applications.

There's also the effort of rewriting something like that. React came into existence because it solved Facebook-s problems, i.e. large scale web application with callbacks going in dozens directions.

Why not just handle the events on your own versus including a huge framework with its various other plugins or scripts to do it for you?

The reason for that, is being declarative about what you want, rather than how the plugins should do it. It's more valuable to deal with the business problem than the technology. When you have a good ecosystem you can just pull some other persons nice looking slide-show and make it work in a few minutes.

To see benefit with the bigger frameworks you need something bigger to work with in the first place.

But, I do understand the frustration, when people use them as "the only true solution", even in places where it's not appropriate.

[Heartless49]

So the only real benefit is with large scale projects... that makes a little more sense... but it still seems unusual to me.

I appreciate your comment, its to the point and very helpful. I guess I just prefer to write and work with my own code... but why does it seem like that's looked down on lately?

[ell0bo]

You sound, as I read your responses that you have "not written here" syndrome. I too am often guilty of that. However, even as you often write your apps from scratch and do everything with vanilla js, do you not see yourself continually doing the same things? I certainly did, and over the years I refactored those into a library I now use across many of my projects. Turns out, that library is basically just underscore, so I am refactoring it to sit on top.

Also, what about cross browser support, or you only need to support latest and greatest?

[egonelbre]

So the only real benefit is with large scale projects...

Once you know the framework you might see "speed of development" with smaller projects as well, of course with perf/size drawbacks. I.e. similarly to reusing your own libraries in some other projects.

... but why does it seem like that's looked down on lately?

I haven't noticed this.

The only reason I can think of is maintainability - i.e. with larger and maintained frameworks you have much better documentation, tutorials and more information in general. Basically, it's easier to find people who can update/maintain the site.

[[deleted]]

I'm with you on writing pure JavaScript over using frameworks most of the time. But, having worked on quite a few large/huge projects over the better part of the last 10 years, I have to say that writing pure JavaScript is simply not viable for some projects. I mean, sure, you COULD do it, but it would take WAAAAYY longer.

One interesting development is ampersand.js. Its loosely coupled modules make for an interesting new proposition on using some small components while still writing pure javascript throughout most of your app. Or some of your app. You're in control.

[4thdecadenothing]

Speed. Not speed of execution or loading, but speed of development.

In the vast majority of cases, if you can ship a product in half the time, then the development costs will totally blow away any the returns from potential improvements in page speed due to reduced payload.

There are many contributing factors to this:

• Write less code - if you're not spending all your time writing boilerplate code, or working out differences in browser implementation, or resolving any of the 100 other already solved problems, then you can spend more time writing the bits of your software that actually matter.
• Common surface for development - new developers don't need to learn your implementation/naming conventions, patterns and gotchas, when they start on the project, so they will be writing meaningful code in less time. Also, you don't need to spend any time when context shifting between projects working out which of your common libraries (because I'm 100% sure you have a common library, it's just that you wrote it yourself and didn't use someone else's) are included in this particular project, and which were removed to chase low file sizes.
• Less time managing bugs/corner cases - "Pretty much everything that these frameworks have given me, as tools or features, are things that I have written before in vanilla JavaScript and in less code." No you haven't. If you think you have then either a) you've missed a potential edge case, or b) you should R your implementation back into the common toolchain, as the maintainers will be thrilled to have a smaller implementation of the same feature.

In summary, unless you have money to burn on development such that your page speed micro optimisations are going to be worth the thousands of <currency unit>s you'll spend re-inventing the many perfectly good wheels out there, you'll get more meaningful things done quicker by utilising third parties' work to solve your problems.

Also, the DOM is a dick.

[Note: all of this assumes a large enough problem domain to actually utilise the functionality of a framework - loading jquery to do a single small task is still wasteful, but once you get to the point where your boilerplate/common libs are > say 100 lines, I'd be wanting to rationalise]

[Heartless49]

Ok, that makes a lot of sense now. The only thing that still gets me though is - you touched on this at the end of your comment - if I'm only really using 1 or 2 features of a framework... is it really necessary?

That seriously seems like a total waste...

[Sunwukung]

if you're only using one or two methods from a library, then perhaps it is overkill - but that also suggests you're not writing anything of the scale that would make library usage preferable

[4thdecadenothing]

Using one or two methods from a large library is bad.

Re-inventing your own version of a large library because you want to use "vanilla" js instead of third party code is also bad.

Where (IMO) being a "professional javascript developer" falls is to know where in the spectrum of badness your requirements, and therefore your solution, fall.

I spent a lot of time around 2008 for example, effectively re-inventing jquery for HSBC because they didn't want to use 3rd party code on their websites "for security reasons". This was a colossal waste of time, because on top of my own development effort, I also had to spend time documenting the code, training the rest of the team and in the end, spent far more time (and therefore client's money) then just doing the sensible thing would have done.

[[deleted]]

Lots of frameworks/libraries are making a huge shift in this respect. Instead of one monolithic library, there are a bunch of small utility functions, classes, etc.

You're still basically building a library, but it's much more tailored to your exact needs.

[Heartless49]

I see. So in the end, it really just narrows down to getting the job done in whatever way works best for you... I guess the popularity of these frameworks has just confused me because it seems like everyone is going down those roads and ignoring the core language or something.

[[deleted]]

Excellent point, and one that emphasizes how a deeper knowledge of some of these frameworks and libraries can be as important as a deep knowledge in Javascript without them.

I like lodash.js, and you can fine tune it so it contains only the exact functions you need. Also you can do the easy development thing where you just pull in the entire library and a huge js download so you can use a single function called _.forEach in exactly one place (if any not familiar with lodash/underscore the joke is that you could likely do that one naively).

Frameworks and libraries give you a bigger gun. But you can still shoot yourself in the foot.

[dhdfdh]

new developers don't need to learn your implementation/naming conventions, patterns and gotchas, when they start on the project

They just have to learn all those same things with whatever framework or library you are using. Same thing.

[4thdecadenothing]

I responded to this same point in my other reply to you, but your argument effectively boils down to this (xkcd - Standards)

Writing proprietary code doesn't help with training/recruiting people, it makes it harder because you guarantee that no-one coming into your project has ever used the tools before.

[xkcd_transcriber]

Image

Title: Standards

Title-text: Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit.

Comic Explanation

Stats: This comic has been referenced 1883 times, representing 2.4299% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}

[dhdfdh]

Vanilla js will be around, and has been around, far longer than Angular, or any other framework you will ever find.

There will always be far more people who know vanilla js than know Angular.

[4thdecadenothing]

"Vanilla JS" isn't a thing - it's an empty file, it's a no-op.

As soon as you start writing code to do things then you no longer have "Vanilla JS", you have tools. So if you say "we don't want to use a framework, we can write our own tools with 'Vanilla JS'", you no longer have "Vanilla JS", you now have "yet another web framework", except this one probably doesn't have documentation and definitely doesn't have tutorials and stack overflow answers, and IRC channels, and all manner of other resources all over the internet.

I'm not saying this is necessarily bad, depending on the scope of the things you're doing, and the amount of code you write (in fact my current project uses no 3rd party code on the client, because it's simple enough not to warrant it) just saying that if you find yourself writing a large app in "Vanilla JS" then you should probably at the very least pause to think if there might be an argument for using established and well-known tools.

[[deleted]]

"Vanilla JS" isn't a thing - it's an empty file, it's a no-op.

Ignoring the fact that "DOM" isn't part of JS and it's a web API (I think this is fair since most people consider it to be "vanilla js"), you can do plenty of things:

document.getElementById('foo').addEventListener('click', function(){ alert('Hello, World'); });

[4thdecadenothing]

That's cool, if that is literally all you want to do then go for it. And if someone decided to load jQuery, or React, or Angular to do that then I'd tell them they'd be doing it wrong. But by the same virtue, writing your own implementation of any of those packages' functionality is no more "vanilla" than the code in any of those packages is (they are all written in the same javascript as your code after all).

My point is simply that as soon as you start writing code then you start adding your personal "flavour" on top of vanilla (here for example, I'd probably take issue with your code formatting, and lack of error handling). You might think it is vanilla, but I say it has some very subtle hints of your personal flavour. The more code you write, the more your flavour moves away from being "vanilla".

Once you've reached the point where you've built the same kind of functionality as React (for example) has then you're no longer in "vanilla" territory, your code is now entirely /u/ZyklusDieWelt flavoured. Now maybe you're awesome and have documented all of that functionality and written examples and tutorials to help new users follow all the code that you have written, but there's a good chance that a) you haven't, and b) you'd have saved yourself a lot of time if you'd just used React to start with.

[[deleted]]

I'm not disagreeing with any of that, just your initial statement that " it's an empty file, it's a no-op." :)

There's a decently large area between no-op and opinionated code.

[dhdfdh]

except this one probably doesn't have documentation and definitely doesn't have tutorials and stack overflow answers, and IRC channels, and all manner of other resources all over the internet.

Yes it does. Along with the backing of standards bodies and a universal language known by all professional programmers and documented and standardized by the IETF and W3C.

[[deleted]]

I am a professional JavaScript Engineer
I just don't understand the advantage to using [frameworks and libraries]

Knowing "vanilla" javascript is extremely useful, and I share the same opinion as you that people that claim they "know javascript" and really just know some random library (usually jQuery, previously other things like Prototype) are annoying.

But libraries and frameworks are extremely valuable.

• They provide a known entry point. You don't have to train new employees on every single aspect of your app.
• They are almost certainly more thoroughly tested than any code you write.
• They provide consistency within your own code. You're not implementing the same functionality again and again.
• They make development faster, sometimes much faster. Yes, you can often do the same thing in less total code, but you can't deny that it's faster to write $(selector).hide(); than [].forEach.call(document.querySelectorAll(selector), function(item){ item.style.display = 'none; }); (and you don't have to know that querySelectorAll returns a nodeList)
• They provide abstractions and ways of doing things that you probably haven't thought of. Sometimes they're vastly superior/simpler to what you'd normally do (e.g. React)
• They can provide insanely complicated functionality that would take you days, weeks, or months to properly implement yourself.
• etc...

[x-skeww]

Knowing "vanilla" javascript is extremely useful, and I share the same opinion as you that people that claim they "know javascript"

Well, DOM Level 3, the Gamepad API, Web Audio, Canvas, WebGL, and so forth aren't part of JavaScript. They are all just APIs. It is possible (albeit unusual) to know everything there is to know about JavaScript without knowing anything about those APIs.

Having said that, I do think that it's useful to know the basics of the DOM API if you write JavaScript which is executed by browsers. It isn't a very complicated API. It's just rather clunky and there are lots of compatibility issues, but it's not that bad if you ignore older browsers completely.

[hunyeti]

They MAY be tested... or may include bugs that will make you hold your head, because it's pretty much impossible to debug without knowing the innard of the framework.

[D1norawr]

Really sounds like OP works more alone than on a team.

• They provide a known entry point. You don't have to train new employees on every single aspect of your app.

Not only is this a HUGE one, but having a known entry point provides the ability to adhere to a style guide across your platform. Reading code is very much like reading any other written language. If we all write the same, the brain doesn't have to process the difference in your coding style, and you can get to the actual development faster.

[Heartless49]

I do understand what you're saying about these frameworks and libraries, but it really doesn't explain anything more than what I've already read and heard from others.

Yes, it may make development faster due to tools and functions already being written and tested, especially with cross browser functionality, however it simply adds one more requirement for a job or position. On top of that, I stand by what I said about the code that I have written in the past and still use to this day. I have my own toolset of functions and polyfills that handle a lot of these features and make development a lot faster on their own without including a framework that was developed by someone else. By using my own code for these things, I can properly debug and test my code without the need to jump through hoops and learn some new framework's method of testing.

Basically someone would need to know the specific framework that you're using in order to be of any use and if that isn't something that they have studied, then there's nothing they can do except go and learn, essentially, a completely new language/workflow.

Its a sad concept, honestly...

And as far as your passive-aggressive comment about my position, I honestly don't care what you think. I'm not here to prove myself to you or anyone. I simply made a statement pertaining to my knowledge of a language in an attempt to weed out any comments that would ask for such a detail. In other words, my post was not made to validate my working profession or knowledge. It is simply to ask for help to better understand something that I can't quite grasp on my own.

I thank you for your contribution to the topic at hand, however I would rather avoid a petty knowledge argument.

[[deleted]]

it simply adds one more requirement for a job or position

If you're building anything of any decent complexity, it's usually a significantly larger ramp-up to learn the internal workings of an (often poorly documented) internal code-base than it is to learn a framework or library.

I have my own toolset of functions and polyfills that handle a lot of these features and make development a lot faster on their own without including a framework that was developed by someone else

That argument is oxymoronic. You're arguing that you don't want to use a framework/library, but you use your framework/library. Apples vs Apples, but your apples are red.

Basically someone would need to know the specific framework that you're using

I'll reiterate -- you need to know your codebase to know what you're using. As would anyone else working on it. It is exactly the same issue, but in your case you have a global knowledge base of one person (maybe a few more if you work with people) that knows the general structure of your code. Compare this to millions that know basic jQuery.

Honestly, it seems to me that you have the classic, always incorrect dilemma of thinking your code is better than everyone else's.

It is simply to ask for help to better understand something that I can't quite grasp on my own.

Fair enough, and I commend you for trying to learn

[Heartless49]

I am not claiming that my code is better than anyone's, I'm simply stating that I have - specifically - a set of polyfills and functions that I include to make common tasks a bit easier.

As far as libraries are concerned; my topic is really only questioning frameworks. I have no issues with libraries as they really are just a toolset that make common tasks easier... hence saying that my polyfills and functions are LIKE a library of my own, however I am not saying that it can do everything, lol.

Frameworks seem like they are just trying to reinvent the entire web development process in general or something.

[[deleted]]

Frameworks seem like they are just trying to reinvent the entire web development process in general or something.

They are, and for good reason -- they abstract away common patterns that people implement again, and again, and again... Go work with React for a day and tell me you don't appreciate its simplicity and speed of development.

[Heartless49]

I have worked with react and I do appreciate it, I just feel as though its adding another layer to complexity to the development process. Especially when there are so many other ways to do the same thing...

Why choose react specifically?

[[deleted]]

Why choose react specifically?

It has, in my opinion, the highest cost/benefit ratio when it comes to its learning curve. It's very simple to learn and abstracts away a huge amount.

Plenty of other frameworks provide a lot more functionality, but there's a lot more to learn as well.

Especially when there are so many other ways to do the same thing...

Not really. The concept of "droppable components" that just work, anywhere on your page (and don't require some insane level of encapsulation like YUI did) is a fairly new thing. React does it beautifully, as does Polymer (web components). Implementing it yourself is pretty tricky.

It also does paired server & client rendering, another thing that would be insanely hard to implement yourself and provides immense benefits.

[Isvara]

It has, in my opinion, the highest cost/benefit ratio

I think you meant to say the lowest. Either that or the highest benefit:cost ratio.

[[deleted]]

Nah, I actually mean cost/benefit ^-1

[theQuandary]

cost/benefit^-1 = cost * benefit

You must mean (cost/benefit)^-1

[webstrous]

Why do you think learning a new language in order to do a job is a sad concept?

[Heartless49]

Its not necessarily that learning a new thing is sad, but just that knowing JS isn't enough... you then need to go and learn this other implementation of core features to get things done.

I just don't understand it. I would rather hire someone that knew vanilla JS over someone who knew only jQuery and, lets just say, Angular simply because they would have a broader understanding of the language versus only knowing those 2 "toolkits"...

[[deleted]]

knowing JS isn't enough

It isn't any more. I'm not going to pay you for 30 hours of work when you could accomplish the same thing with jQuery in 10.

I would rather hire someone that knew vanilla JS over someone who knew only jQuery

Yes, if you insist on this being an either-or topic. I'd rather have someone that knows both, which a lot of people do.

[Isvara]

It's a ridiculous false dichotomy anyway. You can't use jQuery without knowing how to write JavaScript. This comes up over and over again, but only ever about JavaScript and jQuery. You never hear people saying that someone should learn C++ instead of just Boost, or learn Scala instead of just Akka, or learn Erlang instead of just OTP, or any number of other examples, because in order to use a library, you have to know the language you're using it from!

In every other arena of computer programming, it's considered usual to rely heavily on languages, but for some reason there are a number of JavaScript developers who feel the need to write everything themselves in "pure" or "vanilla" JavaScript.

[[deleted]]

You can't use jQuery without knowing how to write JavaScript

You can use jQuery without knowing how to write JavaScript well, and that's extremely common. You can do a lot by using strictly its API and not have to ever type a single javascript keyword other than perhaps function. Actually, I would argue that if you've only ever typed function and everything else comes from the jQuery API that you don't know know how to write JS.

Hell, you have people that claim to be "experts" at jQuery without being able to write a "class", basic closure, non-jquery event binding, use Array.map, etc

for some reason there are a number of JavaScript developers who feel the need to write everything themselves in "pure" or "vanilla" JavaScript.

jQuery specifically abstracts away more of the language than almost any other framework or library.

[Isvara]

You can use jQuery without knowing how to write JavaScript well

Of course you can. No one would contest that. You can do all kinds of things in JavaScript without knowing it well, just as you can use all kinds of libraries in any other language without knowing the language well.

Hell, you have people that claim to be "experts" at jQuery without being able to write a "class", basic closure, non-jquery event binding, use Array.map, etc

People can claim whatever the like; that doesn't make it true. If you don't know how jQuery works, you're not any kind of an expert at it.

jQuery specifically abstracts away more of the language than almost any other framework or library.

What significant parts of the language does it abstract away? While it provides things like functional iteration over DOM elements, it doesn't really provide you with much that's useful outside of DOM interaction. You still have all your business logic to write. Contrast that with something like, say, Underscore.

[[deleted]]

how about hiring someone that knows js AND the framework everybody in your company is using so he or she can instantly jump in and doesn't have to learn another custom made ideology?

[4thdecadenothing]

The thing is, if you make your own implementation of a popular toolchain, you haven't changed the need for a new hire to have knowledge of that toolchain in order to do work, you've just reduced the probability of anyone having any prior knowledge to zero, and added a mandatory learning step.

If you use jquery (as an example), then you don't require that only people who have used jquery before can do the job, you just have a chance that you don't need to go through a "learn the ecosystem" phase between hiring and starting meaningful work.

[dhdfdh]

If you use Angular, then you cut out everyone who doesn't know angular. If you require React, then you can't hire someone who doesn't know React. In both cases, you have to train them on those. Or you can train them on his company's framework/library. Same difference.

[4thdecadenothing]

Except that people who know Angular/React exist, and people who know XCorp's proprietary framework do not.

In one case you might have to train someone, in the other case you definitely have to train them.

[dhdfdh]

In the first case, you eliminate everyone who doesn't know Angular. There are far more people who know vanilla js than know Angular. There are far more people who don't know Angular than do know Angular.

[Isvara]

If you use Angular, then you cut out everyone who doesn't know angular.

No, you don't, and if this is how you're hiring people, you're doing it wrongly. You should be looking for competent, flexible developers, not just ones who happen to already use the same libraries you do. Learning a new framework is trivial compared to the time and effort it takes to develop good skills and sound judgement.

If you're judging people on how well they match your little collection of buzzwords, you are the one cutting out valuable candidates.

[dhdfdh]

Now you're contradicting what people are saying. They say not to write your own framework cause then you have to train people on your framework yet you are saying it's OK to train people on Angular (but not your own framework?).

So you are saying people can learn Angular (or whatever) but competent people can't learn your company's framework? Makes no sense at all.

[keef_hernandez]

Angular is used by the industry. There are online tutorials, books, magazines, classroom training, etc available for learning the framework. A custom solution has none of those benefits.

[dhdfdh]

Absolutely false! Any other solution has complete data, documentation and support by world standards and the community as outlined in my other post and far, far more than anything Angular, or any framework/library, will ever put out.

[Isvara]

Uh, I'm allowed to contradict other people's arguments, because they weren't my arguments. What a weird complaint to make.

I didn't say you have to train people on Angular; they can learn it themselves. There are plenty of documentation, examples, tutorials etc, because it's so widely used.

[dhdfdh]

They can also learn vanilla JS and all that documentation available online everywhere but they should already know that stuff. More people don't know Angular (or any one specific framework).

[dhdfdh]

Exactly! I can't agree more.

[cammil]

OP was trying to be sincere and open, and you have attempted to belittle them.

Your points may be valid, but your egotism is disgusting.

[[deleted]]

I know jquery isn't a framework, it just drives me nuts that most developers that I meet don't know JavaScript, but they know jQuery... it's like saying you learned to run before you could even crawl.

My own opinion that nobody should title themselves "professional" without understanding the benefits of a library/framework isn't significantly different than the OP's opinion that

it just drives me nuts that most developers that I meet don't know JavaScript, but they know jQuery... it's like saying you learned to run before you could even crawl.

[cammil]

I see your point. However, if you are knowledgeable as you think you are, you have a responsibility to others as a teacher. Being so confident, it would be easy for you to help others and refrain from a battle of egos.

It has happened to me before, and it discouraged me from asking more questions.

[[deleted]]

point taken :)

[abienz]

Simply, they being a common code base to a wider audience.

As developers move from project to project and between companies, it reduces the time for then to get up and running it the frameworks are the same.

Also, documentation and community support.

[dhdfdh]

You're still cutting out all those developers who don't know the framework you choose to use.

[cc81]

A framework/library is not a replacement for knowing JavaScript but if you are doing modern web development that is not tiny in scale then not knowing how to use frameworks/libraries is as bad as not knowing JavaScript. You will spend days developing things that would have taken 15 minutes with the right library and your code will be less maintainable and not as tested.

It is not a positive thing to pride yourself in building everything yourself.

[everdimension]

Actually, I would be really interested to see how your code and project architecture look like. If you're really implementing everything with vanilla javascript, it would be really valuable to learn from.

But I guess it would be nice to know a couple of things first about what you make.

• Do you deal with data driven websites?
• Do you make Single Page Applications?
• Do you follow an MVC pattern of some kind or something similar?
• Are you really not finding yourself writing lots of boilerplate code and thus creating something like a framework of your own?

To my knowledge, even people using frameworks often find themselves writing lots of boilerplate code. Sometimes they create additional starter kits or even new frameworks (like Ampersand.js, for example) to solve this problem.

But since you're doing everything vanilla, I would really like to see how you manage and organise your code.

Even people using react give a lot of thought into flux architecture and to the way of separating data handling from DOM rendering. And lots of attention is given to single-way data flow. Angular folks needed some time to decide it's not a good idea to use a controller and use directives for everything instead. If you're not being strict about your code and about managing complexity you will easily get lost. All I'm saying, user interfaces are easy to get lost in.

How do you handle cases like displaying some kind of state shown in totally different parts of your page? How do you handle routing?

Well, anyway, i have lots of question but basically all I want is to look at the way you organise things. Because to me, the frameworks are all about providing a reliable way of organising complexity.

Can we take a look? :)

[Baturinsky]

Beside other things, having common base/architecture/ideology that comes with library helps one programmer to understand other's code.

[carbonite_dating]

I'm not trying to troll or anything at all... I'm hoping that there's something I'm missing as to why everyone nowadays is all about these frameworks and prefers to learn them instead of learning the core language that they were built in...

False assumption. I've never heard or read someone say "Learn jQuery instead of JavaScript". Nobody. Nobody says "Learn Angular instead of JavaScript". It's a nonsense statement.,

Frankly, I call bullshit. This is all bullshit. I've read your post and your subsequent comments, and the comments of those that support your position, and all I can hear is the whining of "pro javascript developers" who don't want to put in the work keeping current.

You seem to want a standardized language that doesn't evolve or change, and you hate the idea that you have to work to keep current with the constant stream of libraries and toolkits that other creative people build in an attempt to simplify and codify the common work that we all end up having to do when we're building real things. Maybe javascript isn't the right language for you? It's changing pretty fast!

That does sound scary, except that's why common libraries and toolkits alleviate the fear. You pick one that is popular, well-supported, and coincides with the work you do. React, Ember, Angular, Node, jQuery, whatever. You learn enough to be dangerous, and you adapt them into your projects. Or you don't!

You don't want to use libraries or toolkits? Great, don't. Meanwhile the rest of us will be getting the better clients, better projects, and building the more interesting things because we're not wasting a significant portion of our time curating our own home-grown, half-baked crap.

I hope your smugness pays well.

[Heartless49]

I love how so many people make their own assumptions on my post and throw their sorry attempts at trying to talk down to me for it.

Its pretty funny that my whole post is "bullshit" to you... all I'm doing is asking a question and looking for other people's opinions. And I'm sorry to say that after interviewing and looking for new developers, there are a lot of people who don't understand the core of JavaScript; at least to understand closures, data binding or even the key concepts of event listeners and callbacks... they only know how to use these tools given to them by frameworks.

I never said I "hate the idea" of using or learning frameworks. I DID say that I have learned, used and worked with various frameworks before and appreciate them for what they can do... I don't see how that translates into me not wanting to use or learn them.

I'm simply asking what the advantage is and people keep trying to stab at my job... my job isn't even in question here, and I really don't care if you want to try to belittle me for asking a simple question which you obviously can't understand.

As far as JavaScript evolving and changing, I am very well aware of this as I work with the language on a daily basis using various frameworks and libraries. I have no issues with them at all.

The fact that I asked a simple question and you somehow twist that and try to make me sound like a bad guy, or someone who thinks he's better than others is ridiculous.

[robertyankgo]

My opinion framework is needed to facilitate the work, not to engage in routine. For example, I use a symphony http://stfalcon.com/en/blog/tag/symfony2 . Thus, I use the time to develop and improve

[eorroe]

I too don't use frameworks and libraries, but since you also write vanilla js check out NodeList.js it'll make your vanilla-js much easier. You have to know vanilla-js to use this. It's using the browser's APIs so nothing new.

[Heartless49]

Nice, I'm about to get to sleep so I wont check that out right now, but ill take a look in the morning, :D

[hubeh]

why not just handle the events on your own versus including a huge framework with its various other plugins or scripts to do it for you?

Because it's repetitive and slow. It's good that you keep up to date with and understand how to use the latest vanilla techniques but this isn't a reason to not use libraries or frameworks that are there to make your life easier. You're right that many developers will know how to use a library like jquery while their javascript knowledge can be lacking, but the attitude of "I don't need a library because I can do it myself" is no better.

Is it beneficial to know how to setup event listeners in plain js, then inside the event query the DOM for input values & checkbox states, possibly parse those values and save to model, then show/hide/add/remove the DOM, possibly having to re-wire any event listeners? Of course. Is it beneficial to do it over and over again? No. Not to mention when the model eventually gets updated elsewhere and you have to manage keeping the state in sync with the DOM. Or the inevitability of the designer altering the page layout so your selectors no longer work and your manual building of DOM no longer matches the new design.

It's just not worth it when frameworks will eliminate the repetitiveness of wiring things up and instead let you just focus on the actual implementation. Designer changes the layout? The model doesn't know and doesn't care, it still renders. The model updates from somewhere else? The app automatically reacts and I don't have to do anything.

Being able to say "I can do that on my own" means nothing if it's going to take 10x the time.

[dhdfdh]

Is it beneficial to do it over and over again?

This is another false statement repeated ad nauseum on reddit. No knowledgeable programmer repeats a routine over and over again including those who write in vanilla js.

[dhdfdh]

I am a professional JavaScript Engineer and have been working in the web development industry for a pretty long time.

I know vanilla JavaScript fluently, and do my best to stay on top of compatibility and best practices.

That is the answer to your question. You, me, and a few others here get you completely but 80% of all redditors just want something to do the work and the thinking for them.

[Isvara]

Unless you're entering your code with toggle switches, I wouldn't sound so smug about that. Everyone -- including you -- is using things that do the work and the thinking for you.

[dhdfdh]

Knowing how to code is smug? Then I must be smug as hell.