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

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.
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.
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.
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

Your article makes it sound like you've never heard of node. Javascript especially as an isomorphic language has many advantages.

@bmlyon I am always talking about JS only from the browser perspective and don't care much about server-side JS and native apps written with JS. JavaScript will never conquer the world and it primary purpsoe still will be the browser scripting (at least until WebAssembly). Use right tool for the right job. For server-side I am still using PHP since it was invented to do so and PHP7 is as same fast as Node.js. For MacOS, iOS I use Swift. When you need something lower-level there is C/C++ or at least Java.

Wow, that's one huge text! I really enjoyed reading it. but I do absolutely not agree with you. So I am really looking forward to your article to see the complete picture :) But for now, here is my opinion:

A programming language is a formal computer language or constructed language designed to communicate instructions to a machine, particularly a computer. Programming languages can be used to create programs to control the behavior of a machine or to express algorithms.

Wikipedia

JavaScript is a "real" programming language, not a framework. It is a formal language used to interact with the PC, change its behavior and express algorithms. Even when many things are already implemented by the browser, just think about the standard libraries of languages, like C++, Delphi and Rust. They also do contain an awful lot of things which you do not have to write yourself any more. The power of the standard library is no argument for or against a formal language being a programming language. All the "tools" you quoted are just part of the standard library of the browser, supplied by web standards to make interaction with rich controls and bindings to hardware possible.

I don't know why you would mention UNIX there. UNIX does also allow for shared libraries, which are big, fat constructs with lots of flaws, used by many programs simultaneously. Then there are distributions, like Stali which try to solve that problem. Oh, and do not forget about all the other distributions which all try to solve different problems - why not be pure and just go with a Kernel+the GNU tools? Ironically, it is quite similar to what you try to tell us is bad about JS libraries.

The passage about frameworks is disagreeable, because neither of your "reasons" applies for frameworks, like React, which try to solve an internal problem one of the biggest internet companies around had. They do have money and people, so the first argument does not apply and React was built for their own needs and open-sourced for your convenience, so the second argument does not apply either. I am pretty sure that a lot of thought went into React (which, btw. is written in VanillaJS) in order to improve their overal architecture while trying to improve some other problems as well.

The second passage does not make any sense to me, because you admitted that you actually wrote a library (MVC adapter) to make your life easier. What is the difference between using a 3rd party lib and using your own? Heck, I also write VanillaJS 99% of the time, but I still create libraries as I see fit in order to bundle functionality logically. Libraries actually are a valid architectural decision and, again, not limited to JS.

The first halve of the fourth part might be agreeable, if not for the very dynamic nature of JS, where you have to actually run the code in order to find out what is happening. Will a variable contain a String? An Integer? Maybe an Object? What kind of Object? What about the surrounding closures? How can your static analysis grasp that? I get the feeling, that you completely ditch that fact for the sake of the argument.

About that designer's advice: It sounds a lot too spartanic to me. I wrote 50k LoC, then I notice that I have a bug somewhere, so I delete 50k LoC and just start from the beginning and try to remember not to introduce that bug again? No way. That's not how you improve, that's how you go mad.... :( Also no company in the world would hire anyone with such a mindset, because it's a complete waist of money. Something like that might be OK for an artist, but not for a programmer - and I am pretty sure that it was meant like that (since you quoted Photoshop so nicely).

Again, I find your post highly interesting, so maybe we can use this opportunity for a little discussion? :)

If "javascript frameworks are useless", why the fuck did you write one?

@maruru

Wikipedia is never a source you should rely your argumentation on. Anyway there is a direct link from your Wikipedia page to a more precise section - List of Scripting Languages - wikiwand.com/en/List_of_programming_languages_by_… JS was weak from the beginning and still doesn't has many constructions you can find in many other languages. ES6 was the biggest evolution in JS for 20 years but "classes" are still far away from being what people want to see.

I mentioned UNIX because of it's philopophy and simplicity. React or Web components, for example, uses these principles as well. In web you are building a lot of components and for the maintainability, reliability and stability purpose they should be simple, small and do not know about each other.

like React, which try to solve an internal problem one of the biggest internet companies around had.

Can you provide me researches, links to the articles, precise numbers about that "internal problem", about why people are using React and moreover I am interested in measured results (at the end was that experiment successful, how exactly, or not?).

wrote a library (MVC adapter)

I didn't wrote an MVC library. The main architecture and most of components are part of business code and are only available within a private repository. Something similar to "jQuery UI" would be more correct.

What is the difference between using a 3rd party lib and using your own?

I am using 3rd party libraries as well and do not reinvent the wheel if there is already one. Answer is simple - look, for example, on Bootstrap 4 dropdown. What Bootstrap offers you is a huge jQuery itself only because of a dropdown which is 2kb of Vanilla JS? Same is now with React, a lot of simple components but to make these components working I need to include React, Redux and some other libraries often.

I am pretty sure that a lot of thought went into React (which, btw. is written in VanillaJS) in order to improve their overal architecture while trying to improve some other problems as well.

The most went to Angular and other frameworks, React itself still is a small UI library which suck less, a complicated templating engine. Problem is people can't explain anything about their decisions, why they use it, what problem it really solves, how exactly, numbers, results. When people don't know about the architecture patterns which exists for tens of years and telling you that React introduced it, well, this is not the improvement of the architecture. You mentioned "some other problems as well". Again, may I have links, researches, discussions, results?

Will a variable contain a String? An Integer? Maybe an Object? What kind of Object? What about the surrounding closures?

Interface should be simple and static. If you don't know the type of variable could be, then there is something wrong with your architecture and/or code. Also code should be pure and without side effects.

Again, I find your post highly interesting, so maybe we can use this opportunity for a little discussion? :)

We can. Are you in Hashnode's Slack?

@hugollm

If "javascript frameworks are useless", why the fuck did you write one?

I didn't wrote a framework. Well, some complicated components such as Validation can be viewed as small frameworks. You can build own form validation on the top of it very fast.

@mevrael Well, your view on Wikipedia might be outdated. Today, citations from real books, articles and statements are needed, just like in a scientific paper. So Wikipedia is indeed quotable, given that necessary citation is provided. In case of the programming language article it is. Also your link shows, too, that JS is a Programming Language. Here is another, concrete evidence, that being W3C listing JS as programming language for their tutorial course. I yet have to see evidence against JS being a programming language ;)

The UNIX philosophy and how stuff developed are two different things. So again the situation is very alike.

About the internal problem, let me direct you to one of Hashnodes AMAs. It's not about numbers or anything, it's just that one guy had a problem with the available tooling and developed a solution. React is like some packaged architecture to help you structure your app and people like it. That's why they use it. If you want numbers, you will have to first explain what you want to measure? All results are only relevant when relative, so what do you want to compare them against and in what categories? I see great difficulty in such a benchmark, because React really is mostly about architecture, so measuring the structure of a project in numbers is a little...

You know, I wrote in my FSWD 101 that many people miss-use React. You might be on that track. React is nice when your application becomes so big that React is small. It's OK, when you build a Facebook, but definitely a nuclear bomb to kill an ant when it comes to personal sites and the like.

Angular is a Google product, so I do not think that Facebook put a lot of thought into its development. And If you want to know what problems React solves, please take a look at the official homepage, everything is written there in the docs. Or read the Wikipedia page, which sums it up nicely.

JavaScript allows for dynamic content and I think it's a shame if you do not make use of that when it is convenient. It's not about bad design, but leveraging the power of the language! Sure, an interface should be static, but why not have multiple possible return types, depending on the input? If you pass no callback, then you will receive a promise, else you will receive a return code (number). As long as these things are documented explicitly in the interface documentation, it is a valid design decision humans can live with; but machines cannot. That's why we have to write test cases for every possibility. That's why there are so many unit testing frameworks for JS out there.

Yeah, I am on Slack, but I prefer an open discussion. That's what Hashnode is for, after all :)

About that framework of yours... could you please read the headline of your homepage to me? Doesn't it say "BunnyJS - Browser ES6 framework". If it's not a framework, why does it say so everywhere on your page?

@maruru

Whenever you read or answer something always look into the context and stay to it. I didn't said JS is not programming language, I said it is not "real" programming language in context of it's history and purpose, it was designed by a great software designer for a one simple use case - to script a browser. It changed a lot for 20 years but still mostly used to do the same thing - script a browser and after that SpiderMonkey/V8/Whatever else will do real job. Looking out of the context and to be more precise - JavaScript is not a language but a standard and is a major section of Web Standards. This standard, if you know it good, allows you to do whatever you want. When your lovely framework doesn't gives you a ready solution you still have to write vanilla JS yourself.

I have read that AMA and offical docs. Here is Ben's answer to my question - Describe in 2 sentences what real world problem React is solving?. He as everyone else tells that React gives you component-based architecture easy to maintain. Problem is people believe that they need to use React to have a component-based architecture, to have a lot of small blocks where you can easily replace/change one without breaking anything else, they need to use React when they have to deal with DOM, etc. You actually just said exactly the same again. There is no connection between that general architecture pattern and React. You can do it without React and you won't have any problems, your code won't be bigger. Actually React doesn't provides any tools for architecture itself. Here is a simple real problem with DI: you have object A, B and C. B and C both depends on A, you want to extend object A and make these changes available in B and C also. What you need to do is to update 2 dependencies manually, i.e. B.A = newA, C.A = newA. Does React solves this simple problem? Except giving me cool architecture I already had for many years before React was born, what else React can give to me?

You know, I wrote in my FSWD 101 that many people miss-use React. You might be on that track. React is nice when your application becomes so big that React is small. It's OK, when you build a Facebook, but definitely a nuclear bomb to kill an ant when it comes to personal sites and the like.

My time and experience is too expensive, I am not working on small projects anymore. My applications grows, are big and I feel myself very comfortable without React because I have almost the same architecture React tries to sale to anyone, but I know that I don't need React to give it to me.

About that framework of yours... could you please read the headline of your homepage to me? Doesn't it say "BunnyJS - Browser ES6 framework". If it's not a framework, why does it say so everywhere on your page?

Marketing. Same as JavaScript was called that way because that time Java was so popular and everyone was crazy.
My own view on what a framework really is is different from what the most people understands by that term. Framework is something could be used to build/extend/adapt/configure your own architecture on the top of it and doesn't dictates you what you should do and how exactly. You are not in the cage, you are absolutely free. BunnyJS right now is not a framework by the definition but, probably, later there will be something like BunnyApp where basic app skeleton and architecture will be set up. One of the greatest examples about the frameworks is Laravel framework (not Laravel itself). There are two repos. Laravel is based on it's own framework which uses Illuminate namespace everywhere, it core components are based on another framework Symfony and it uses many 3rd party libraries by default like Carbon under the hood of all Laravel's components and methods using dates.

Yeah, I am on Slack, but I prefer an open discussion. That's what Hashnode is for, after all :)

Hashnode right now is not designed for a lot of big comments.

@mevrael You say to me you didn't write a framework, but claims in your tagline to be the author of BunnyJS. The website says "framework" very clearly. I guess I'm missing something here.

@hugollm

I've answered about that in last section in the post above you just submitted.

@mevrael right, on the other "thread". Listen, I don't think trash talking your own stuff is helping your marketing. But well, if you have a reason you have a reason. I just commented here because I got angry at your text anyway, so I'm in no position to judge you.

@mevrael

I said it is not "real" programming language

It's funny, because then again, what is a "real" programming language. It's like saying cacti are no "real" plants, because they have no leafes. A language either is a programming language, or it is not. There is no stuff in between. Even in terms of history it is a real PL, because it was designed as scripting language (that's what you say) and a scripting language is a programming language. The interpreter will not do the job for you, it will only interpret your program and connect it to functionalities supplied by your browser or Node.JS or Electron or...

JavaScript is not a standard, it is a language based on ECMAScript:

JavaScript (JS) is a lightweight, interpreted, programming language [..] The standard for JavaScript is ECMAScript.

[..] they need to use React when they have to deal with DOM, etc. You actually just said exactly the same again

Where did I say that you need React? My statement is that an architecture, like what React gives you (Virtual DOM), is important when dealing with big applications. That's also in my answer to the OP. And I fully agree that a lot too many developers think they have to use React for everything. It is very scary, just looking at Hashnode and all the people enforcing React, how many new big web apps are being worked on and should be released, if everyone had ligimate reasons :) I have not learned React and I am fighting against learning Angular and other frameworks, because I do think they overcomplicate a lot of problems. Either way, there are people who, in their heads, need these libraries. And even if it's only a mental thing, it's a reason for them to use those libraries and build great websites and applications. Personally, I don't judge. I don't care. If they can handle it and work with it, that's OK. People are different, after all! I think, as a user, in this very special case, that the result is more important than how they got there.

My time and experience is too expensive, I am not working on small projects anymore.

I do not see how experience and time have anything to do with project size. My job is to build appliances which are needed by my department and to build prototypes and experiment with certain new technology. I never have the chance to build big applications. Does that mean that I do not have any experience at all? That my labour force is cheap? That I have too much time?

Marketing. Same as JavaScript was called that way because that time Java was so popular and everyone was crazy.

That's not what the inventor of JavaScript says... Also why would you spread false information, even though you allegedly know better?

My own view on what a framework really is is different from what the most people understands by that term.

It's not about your own view, but about the definition. If we talk about our own ideas of things, then a computer is an animal which lives in the subtropics and eats sun rays (proof me wrong). Could you please find me an official source which explains, what a framework is and why yours is not? Because it's hard to find anything supporting your statement...

Hashnode right now is not designed for a lot of big comments.

Haha, very true, I am actually writing my answer into notepad right now just so that I can see your text while typing :D

@maruru

My statement is that an architecture, like what React gives you (Virtual DOM), is important when dealing with big applications.

Why it's important? Virtual DOM is a marketing around a virtual problem doesn't exists. So far I've seen only one benchmark showed React was a bit faster then vanilla JS to sort a huge table a lot of times per second which by the fact won't ever happen in real life. Avarage human reaction is 300ms, changes in the UI are called by user actions, screen size physically is very limited, etc. Under the hood it, of course, calls vanilla JS DOM API itself. I'm sure even using VirtualDOM people can write bad code. I have no problems with DOM manipulation and I am doing exactly what I want to do, no more, no less and for that I don't have to store in memory a VirtualDOM and do a diff every time.

So again what React gives me? I already have a component-based architecture, I already have DOM manupulation which is in most cases much faster and cheaper then React.

And I fully agree that a lot too many developers think they have to use React for everything. It is very scary, just looking at Hashnode and all the people enforcing React, how many new big web apps are being worked on and should be released, if everyone had ligimate reasons :) I have not learned React and I am fighting against learning Angular and other frameworks, because I do think they overcomplicate a lot of problems.

At least on the main topic itself we have absolutely the same opinion and fighting against the same problem.

That's not what the inventor of JavaScript says... Also why would you spread false information, even though you allegedly know better?

In the link you provided Eich says what I have written. How my statement is false or are you always reading the words and not trying to understand the meaning altogether?

It's not about your own view, but about the definition. If we talk about our own ideas of things, then a computer is an animal which lives in the subtropics and eats sun rays (proof me wrong). Could you please find me an official source which explains, what a framework is and why yours is not? Because it's hard to find anything supporting your statement...

Exactly, there is no standard single definition about a complicated topics. Moreover, everything depends on context. React is a library or is a framework depending on what angle you are looking on it from. Never read words and sentences, always read what is under them and try to understand what other person tried to describe.

This question is about a simple certain topic and now there is a huge offtop. I am not going to keep discussion about what is a framework, is X a framework or not, etc. This is very complicated scientific discussion which is out of the scope of this Hashnode question.

Call BunnyJS whatever you like. It doesn't matter. Matters only the purpose, difference and benefits and they are obvious: Instead of including a React Dropdown which requires to import also React itself, React DOM and may be something else - you can simply include a 2kb stand-alone component which can be used anywhere. That's all, you don't need to read huge docs, you don't need to setup, change your build process. Total file size is tens of times smaller and code works faster.

@mevrael

So again what React gives me? I already have [..]

It's OK if you do not need it. Just do not generalize your projects and way of working.

In the link you provided Eich says what I have written. How my statement is false or are you always reading the words and not trying to understand the meaning altogether?

No. You said that JavaScript has it's name because Java was so popular and everyone was crazy. (which is a completely random reason), while Eich said that the idea was to make it a complementary scripting language to go with Java (which is a very valid reason). The difference might seem subtle, but the resulting statements are very contrary!

I am not going to keep discussion about what is a framework

Why not finish it with a solid quotation, then? A definition for a framework is nothing scientific at all. It's just a definition. For example Dirk Riehle of Universität Hamburg submitted a dissertation to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZURICH, in which he defines a software framework as:

[A software framework] leaves enough room for customization to solve a particular problem in the application domain. Developers who apply a framework reuse its design and implementation. They do so to solve an application problem that falls into the domain modeled by the framework. By reusing the design, application developers customize a (hopefully) well-understood software architecture to their own specific application problem.

Which means that someone writes a piece of software which solves a problem and can be extended/customized by application code, which has the certain problem which is solved by the framework. This means that a framework is a skeleton for the actual application or solution.

Instead of including [many frameworks] you can simply include a 2kb stand-alone component [..]

Yeah, let's agree on that! I think that's the one advice which we really need when we talk about VanillaJS :)

Search Hashnode

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

Libraries can and should be used

Some myths about the frameworks and Vanilla JS