Of course, ultimately, all frameworks become vanilla js under the hood, but given the advances of HTML, CSS, and ES6 - how far can we go to build great websites without the need for Library/Framework X?
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.
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.
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.
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.
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.
Software Engineer
Marco Alka
Software Engineer, Technical Consultant & Mentor
Michael J. Ryan
Alpha Geek
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.