As long as you are using some form of module bundler (webpack/browserify/rollup, etc), you can go a really long way with relatively plain JS... The only reason I mention using a bundler is it allows you to write your code in discrete modules.

As it is, you can go a very long way. Also, it makes it easier to add micro libraries via npm after you've done this, which allows you to stay very close to vanilla while still being able to support a growing codebase.

Pretty far, indeed.

A company I worked in had their entire frontend codebase written in in-house javascript. JQuery was the only external library linked but I never actually found where it was being used.

It was quite a lot of stuff: a full, feature-packed SOA client, something I would call an ORM even though it wasn't exactly it, a standard library of utilities and, more interestingly, a visual styling IDE for creating responsive websites based on tiling (like webflow), etc.

Yeah, there were no tests and massive refactoring could've gone a long way, besides changing a few idiosyncrasies (such as replacing SOA for full-featured REST among other stuff). But that they managed to build all that from scratch and it, mostly, worked I find a bit impressive.

The company eventually went under but the reason was not their technology.

All of that taught me to always think very carefully before deciding to use external libraries or full-featured frameworks, as I know that we can work without them and have worked like that already. I still reuse a lot, but I do so critically and will write my own code confidently if I feel that that will save me time and pain.

Of course, we can do everything without the frameworks.

Thanks for invites to answer this question. For now I will just give a very short answer since the full one is very big. I am going to finish my article on Medium about Vanilla JS architecture in some weeks where I am going to explain a lot.

People are confusing Browser environment and JavaScript with a real programming languages and server environments.

JavaScript is a scripting language - general Browser's API, it never was a full serious programming language and it shouldn't be. JS was invented to do a simple job - add dynamics to browser and allow not even an engineerers, but designers, just coders to "talk to browser". A bit later JS become a standard known as ECMA and most of the JS engines are written in C/C++/Java. In simple words - JavaScript itself already is a framework and JavaScript (ES6 with Web APIs) today is a very powerful browser's framework.

On the other hand, real programming languages exists for general purpose and give you access to OS, processes, I/O and etc. They by default do not provide you any tools. If you need to parse a string which is HTML and build a DOM, you need to write your own solution (or to include a package which was anyway written by someone previously). In JavaScript you already have many of these packages included globally by default and you don't need to implement them yourself, you have access to client's window, document, images, links and many other stuff. Today there are a lot of modern Web APIs which allows you to send push notification, get acccess to microphone, camera, you can draw 3D games in canvas and do a lot of cool things. For example, most of JS users (developers) don't know basic algorithms in computer graphics, higher mathematics, data structures and a lot of other topics from Computer Science. That's why JS become so popular - because it is very simple and gives you a lot of built-in tools.

The reason why frameworks are needed in real programming languages and especially on back-end is, simply, because it's not the language's job to give you APIs.

That's why JS frameworks are useless. Moreover, they just add extra abstraction and increase the code you should transfer to user from the server and in mobile age of the slow Internet, it is crticial. Why do I need to include a 50-500kb of JS which doesn't do anything? I can include a stand-alone library which will do a form validation, for example, and only for cost of 5kb. I can include another library and write a bit of custom codebase. At the end I may have full codebase which does a lot and still is much smaller then a framework which doesn't do anything.

Libraries can and should be used

The reason why UNIX is so popular - because it is simple set of many small components, small programs, where each one is doing it small job and they all do not depend on each other. You probably have been using many of them in last week. Here is just a very small example of common ones: ls, cd, mkdir, rmdir, mv, cp, top, kill, man, ssh.

Some myths about the frameworks and Vanilla JS

1. People are using frameworks because of 2 reasons: 1) they believe it will give them some magic and automatically write their app. 2nd reason is - marketing. One of the comments below proves it again. People believe in a myth that they need to use React to do a DOM manipulation. In modern society there is a problem - people think that they need X to do Y, e.g. I need a co-founder to start my idea, I need to use a framework to build a website, I need to look good to ask for something, etc. You don't need X to do Y, just do it. But let's go back to the React. There are no real proofs and noone can give precise numbers on how React solves that problem and what problem it actually tries to solve. React invented a virtual problem doesn't exists. Facebook news feed still lags but browsers crashes more today. I hadn't pressed Reset button on my PC for many years and some time ago I did it because of a browser.
2. Myth - If you are not using framework you don't have an architecture and code is hard to maintain. Again in one answer below I see people are blaming Vanilla JS for unmaintainability. It IS engineer's fault not JS's if code is hard to maintain, simply, it means you have NO architecture. Well, the fact is the most projects and even small companies/startups don't have an architect and it's not engineer's job to maintain the architecture, however, each engineer is making small architecture decisions all the time. That's the real problem why most of codebases in most projects around the world is hard to maintain. Believe me my Vanilla JS code is simple as React and maybe even simpler. I do not reinvent the wheel, I have a very basic MVC adapted for browser.
3. Myth - perfomance is bad. Vanilla JS is actually faster because of the obvious reasons. Anyway such microperfomance is evil. If code is slow, then again it is engineer's fault. I've seen people failed even using solid frameworks many times.
4. Myth - hard to write a code and debug - Again it's not problem with JS. Use ES6 and some bundler like rollup, set up IDE, ESlint and other tools and you will have a lot of warnings and even errors during "compliation" if something is wrong in your code. But I would like to recommend something I've learned from a one designer many years ago when I was visiting her master class because it was free and I wasn't much interested in design itself. She once said - "Forget about Ctrl+Z / Undo / Eraser in your PhotoShop or any other tool. Always think like in a real life where there is impossible to undo a past. If you designed a logo and something went wrong - don't save a file, just start everything from the beginning again and do not repeat same mistake again". It teaches you the highest discipline and attention to smallest details. You always will have problems until you won't stop thinking that it can be undone anytime without loss. If you have done something, it's done, deal with it. Don't repeat it, plan better and control yourself more next time.

So yes, you can go very far with modern Vanilla JS and build complicated modern apps.

Finally at the end I want to remind every software engineer one of the core principles in software engineering which is also applied everywhere in the life - KISS (Keep it simple, stupid)

“Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupery

I've built a complete phonegap application in 2014 with vanilla js (ES5) and just CSS + html5 even with canvas fireworks animations based on jack rugiles code pen examples + local storage + workers. I totally agree with @maruru as long as the codebase remains small it's doesn't really matter.

Websites? Go for it. Javascript is very mature right now for simple tasks, you don't even need jquery for that anymore.

Applications? I wouldn't. DOM manipulation will bite you in the ass at no time. Even if you manage to pull it off, you'll probably end up skipping usability improvements because they will be too hard for the value they would aggregate.

I'm saying this because I currently have to deal with projects that are somewhat close to Vanilla JS. The developers carefully tried to organize things and make for a reasonable project. They are still a pain to maintain, and it's not the developers fault at all.

Especially lately, I am ditching all JS frameworks in favor of CSS3 (animation, transition,...) and VanillaJS. I only use small libraries, like reconnecting-websockets.js, which make my life easier. Why re-invent the wheel when I do not need an innovative solution but just something which works?

But careful there! I am not a professional front-end dev who builds the next Facebook. Depending on your project, things like Virtual Dom can make a huge difference, and when using Virtual Dom, you do need frameworks, like React; or HTML manipulation becomes tedious.

Another thing to look out for is big projects. We have Dart and TypeScript for a reason: To minimize stupid bugs. We are humans, so we have difficulties making sure that everything is exactly what we expect all the time. Though, given proficient developers, they will surely come up with an adequate solution in a timely fashion, written entirely in modern JS. But how many people could pull that off? What about mixed or loose teams?

So the bottomline is: We can go all the way with VanillaJS, but at some point, the performance becomes terrible or programming becomes tedious or we start making stupid bugs because we lose oversight, are missing knowledge or just have a bad day.