Am I the only oddball that actually likes using pure vanilla JS without frameworks?

#1

I like using vanilla Javascript without frameworks and libraries like react, angular, or vue. I tend to write things out procedurally, so I get to see the flow from start to finish. I still use webpack and babel (a very basic setup), but using vanilla JS w/ DOM api’s just seems more natural to me and clicks.

Right now, I am building a GirlsAskGuys clone entirely in JavaScript. I use JavaScript for my frontend and JavaScript for my backend (w/ NodeJS/Express of course).

I still import some dependencies like express-validator and express-fileupload. But in terms of major frontend libraries and frameworks, I don’t care much for using them.

Now, I don’t know how it will affect job opportunities, which I assume will hurt them a little. But I am making my own web apps.

4 Likes
#2

The frameworks like React and Vue aren’t just adding “bloat”, they also come with optimizations like a virtual DOM with an efficient diffing algorithm. In other words, they’re much faster than most any DOM manipulation you’d do by hand, and it’s mostly done declaratively, which reduces the many errors you get from doing things in ad-hoc imperative ways. And that’s to say nothing of an ecosystem. How many plugins and extensions does your hand-rolled framework support?

There’s certainly nothing wrong with rolling your own: It’s good learning experience, it’s fun to find new elegant solutions, and it’s how new frameworks get started after all. However, preferring one’s own framework over all others for all things results in confining most your development experience into an applicable niche of one. It’s ultimately not good for learning (other frameworks have much to teach) and it’s definitely not good for career prospects (you have to work with other people’s code)

3 Likes
#3

I like having an awareness and an understanding of the frameworks - I’m comfortable with React, Vue and Svelte, for example. Each of them work in a slightly different way, but it was getting into rolling my own systems that showed the advantage of each.

That said, I too prefer to work in plain old javascript (POJ, from here down). I remember when jQuery became the big thing, and companies were preferring “experience with jQuery” over “experience with javascript”, as though it was this great replacement. It wasn’t, and frameworks aren’t. Getting into frameworks too soon, IMO, is one of the biggest downfalls of budding developers.

As I said, I understand, use, and like frameworks. In pretty much any language. But, if I can “roll my own”, I will. I grok React components, sure - but I really enjoy playing with pure Web Components. There is a power there, a flexibility that is missing when tied to a framework.

Another advantage, of course, is all the POJ skills and tools you learn should work, regardless of framework. Learn the tricks of power-sorting, or multi-filtering, or using reduce() to group for stats reporting, and it just works, framework-agnostic.

As to how it might affect job prospects, I think having a deeper understanding of javascript will tell over a deep understanding of any one framework. At least, that’s been my experience.

2 Likes
#4

@snowmonkey

Some reason that using frameworks is much easier than using pure, vanilla JS. For me, however, it is the opposite. I cannot really grasp using a framework to save my life. I can use vanilla JS easily.

I think the biggest disadvantage for me using frameworks is managing state in a complex web application.

#5

I guess most people would prefer to just use simple JS for everything up to a point. And that point is inevitable, it is where it becomes complicated and you need to write abstractions to handle the complexity. And as it gets more complex (and it always does), you will need more abstractions. And if you want to reuse the effort you’ve put in, you have to write general abstractions. And lo and behold you are writing a library or framework. Your approach and API may be better than what’s available and easier to use, and if so, congrats, but more than likely you’ll be reinventing the wheel. Express is a framework, you could make the exact same argument for backend, why not just use JS and Node’s stdlib 🤷

If you know JS very well then in theory it should only take a matter of days to be basically productive in a frontend framework, but yea not knowing one would place you at a slight disadvantage re hiring for frontend. Just going off your posts, I feel like you have had some difficulties with learning frameworks – getting better at JS will help with that, and building what you’re building should give you some appreciation of why they are useful, as well as making it easier if you give say, learning React another go.

3 Likes
#6

@DanCouper
I know JavaScript extremely well. I have been coding in it for over 2 years now. In addition, I know all the “hard parts” about Javascript. I have read the mdn documentation and books.

When it comes to frontend frameworks, I am clueless.

#7

Frameworks in general made sense to me, the biggest hurdle was trying to wrap my mind around Redux (or Vuex), or whatever data store and reducers to handle data immutability and… eh? But then, as I got deeper and deeper into reduce(), and looking more at functional programming, it kind of clicked.

I don’t feel that the framework paradigm fits every case. And when a project or idea is starting out, it often makes sense to keep the conversation framework-free. But often, there comes a time where, in order to support the productivity of the entire team, a skeleton makes sense.

Its like that cartoon about “I don’t like frameworks, too much enforcing of this artificial construct or that language addon… I know, let’s make a framework that simplifies all that, and lets you just get on with the coding!” And thus, another framework is born. And it evolves and becomes complex.

I remember being a part of the conversations when jQuery wasn’t a thing, when it was in pre-alpha and alpha testing. There were a few other libraries out there doing much the same thing: YUI and Mootools spring to mind. And the big conversation was, “while this library might help, what are the ramifications of everyone using it?” Aspiring devs learned to write truly ugly code, because the utility libraries were very forgiving. Spaghetti code and mickey-mouse patches were everywhere. Following back how an event was handled was like looking for an aux cable in that huge box of cables in the bottom of the closet.

Frameworks are the same. Someone new to coding hears about this amazing way of developing complex SPAs or whatever, and they jump into writing React without knowing how to elegantly, cleanly, properly structure code. While React may enforce a certain level of organization, without the coding discipline that POJ provides, it is easy to make an AWFUL mess.

I have been writing in javascript since Netscrape introduced it, and I still have so much so much to learn. Frameworks are on the list for me - I learn some, then I wander off into POJ curiousity again.

#8

Think of each framework as a different programming language all it’s own, just one that’s “embedded” within the regular JavaScript language you know. Some share their syntax with the host language – express for example is just plain javavascript, Laravel looks like plain PHP (its behavior is another rant entirely). The Amazon JavaScript SDK – a giant framework if there ever was one – is still something you write plain javascript to use. Then there’s frameworks like React, Vue, and Angular, each of which invent their own template language. Still JS under the covers, but you’re not always writing JS to use it.

Thing is, there’s basically no difference – it’s still another language, whether it’s some exotic template language or just a bunch of methods on objects. You have to use certain verbs on certain nouns with certain qualifiers, then expect a response of some kind that follows some grammar – in other words, call methods on objects with arguments, get a return value or maybe call a callback.

For example, in Java, one very standard way to write an error to a log is:

logger.error("Something went wrong with {}", someObject, caughtException);`

But with google’s logging library, looks like:

logger.atSevere()
  .withCause(caughtException)
  .log("Something went wrong with %s", someObject);

They’re doing the same thing, but expressed differently. A different language if you will, or perhaps in this case a very different dialect.

Treat learning new frameworks like learning a new language. Sometimes the idioms are easy to pick up (express for example is simple JS objects and methods) and sometimes not (React is functional reactive programming, not always an easy abstraction to grok). The more frameworks you learn, the more familiar their concepts become, and the more you’ll “get” whatever abstractions they use. BTW, the same goes for full-blown programming languages like Python or Kotlin or what have you.

#9

Am I the only oddball that actually likes using pure vanilla JS?

No, but I believe most developers today don’t use vanilla JS. JQuery for simple cases, the big three frameworks, and other frameworks rule the web. Vanilla JS has one significant disadvantage it doesn’t scale, and not in the sense of performance, but rather for developers. You either have a simple enough use-case when almost anyone can grasp how to make stuff happen, or not a lot developers that need to learn how things are done. There are always exceptions to the rule, but generally vanilla JS doesn’t scale when it comes to more complex use-cases, and or when it comes to adding more developers. You either end up with a custom framework that needs to be documented and up-kept (happens all the time), a huge pile of code that only a few understand (yikes), or a simple web app that is limited by the previous 2.

Its fine if your on your own, as it will teach you a lot. But think of it as being a mechanic. You can build your own engines from scratch, but getting a job working on other types of cars becomes less and less sensible the deeper you go down the “custom” job. You get to learn different skills, but your missing out on “common” skills often sought out.

This is actually slightly concerning. Frameworks always come with some overhead to “learning how its done with X”, but almost all frameworks are built using known well establish patterns, or at least “remixes” of previous implementations.

Here are some examples of the big three frameworks and the patterns they integrate, leverage

  • React - Functional programming is actually pretty old, and usually the recommended way to use React, component based architecture.
  • Angular - Dependency Injection, Reactive Programming, OOP, are all previously established well known patterns
  • VueJS - AngularJS “remixed”, which originally followed the MVC pattern (Model View Controller)

So yes its one thing to miss out on how “Framework X works”, but all of them are built on patterns that are good to know, to use the framework and for future use.

Finally it is worth mentioning 2 things:

  1. Re-inventing the wheel - its easy to re-invent the wheel for a given use-case. Same goes for web frameworks. Its almost a guarantee what ever your doing with vanilla JS has been done before by someone else. Now if its better is up for grabs, but if you only have 1 tool everything starts looking like a nail, same is true with your own code/framework or others.
  2. the “Not Invented Here” syndrome - where you keep “building your own” stuff rather then using existing solutions for one reason or another. (similar to 1)

I’m sure there are others out there building stuff using vanilla JS, but like any choice, knowing if its the “right” one really depends on the situation. Just don’t stick with it because its the only choice, its best if you know its the best choice for a given problem, otherwise you may be just pigeonholing yourself.

Good luck :smile:

2 Likes
#11

I’m going to make this short and sweet. Currently, I am seeking employment at one of the FANG companies. The job requires full focus on JS and they are not concerned with React ( I won’t say Angular because React is their baby ) So, I would say that focusing on JavaScript is a good way to find a job with a top tier company. One thing I have learned as an engineer is to be an engineer. Big companies want master engineers and not coders who solely rely on frameworks/libraries. It’s good to know the libraries like React, but don’t get so reliant on it that you forget to write good code.

#12

I used to feel this same way, but the matter of the fact is:

as your projects get bigger, vanilla javascript becomes harder and harder to read, and this is the very purpose of frameworks from what i can tell; keeping things organized.

yes, it is close to impossible to get a good job now without knowing a javascript framework, especially with how everyone is demanding a full team of full-stack developers. with how streamlined web development has become, only hiring for front-end or back-end is becoming more of a thing of the past everyday.

bonus: javascript frameworks do not slow the user’s computer down, because they are rendered in the server, and then sent to the client. react also makes it very simple to create the visually satisfying loading bars for the user to ogle at while they wait for the page to load, with extremely simplified component state management :wink:

#13

I know this is an older thread now, but I feel its important to mention a few things for newcomers.

<begin-rant>

First, there seems to be a general consensus that using a framework is how you scale, or keep your code clean, maintainable, etc… This is a fallacy. YOU are responsible for keeping your code clean. Only YOU can prevent dirty/unmaintainable code!

Regardless of project size (referring to scope), a framework is neither good nor bad, it is scaffolding that surrounds an idea, or a design pattern. It can become bad if your project outgrows the capabilities of the framework, or is hindered by it in some way. How easily can you decouple your code from the framework? This is a real issue that comes up in years long projects that chose a framework (with good intentions) to get the project started, and now the framework is getting in the way more than helping. Read → AngularJS. Many projects are still stuck using this old(er) framework because its very deeply integrated into the entire project, it is the foundation of the project. Good luck moving to React or <insert-new-framework-here> without completely starting fresh. I can think of several projects that started completely fresh, only this time, choosing to go with Web Components, or a well documented (w/tests) roll-your-own solution.

Second, its ridiculous to say that if you don’t use a framework, future developers will suffer because there will only be a couple people that truly understand the code. This isn’t for lack of a framework, this is because properly tested and clean code wasn’t the foundation of the project. Tests self-document the code for you! Future developers only need to look at the tests to understand how the code works.

How does this class work? How do I use it?
Oh, the test does it like this. Yup, that worked!

Frameworks deceive us to thinking that you don’t need to test your code. So we skip that part until the end… which means never, because projects never seem to end. Except when they do, and at that point things seem to be working, so why do we need tests?!

Third, Question the de facto standard. Just because everyone uses Express when they need a NodeJS web server doesn’t mean its the right solution. How many lines of code does it take to write a basic web server in JS? If you use the HTTP standard lib, 30-50 lines max? Do you really need Express? Maybe, but don’t default to it. (And yes, I know Express offers a lot more than just a web server, but that’s my point, unless you truly need it, don’t default to it)

Conclusion: Frameworks have their place, BUT don’t pick one until you TRULY need it, and even then, work around that problem, until eventually you have no choice but to return to that original need. Is it something you can solve with vanilla <insert-lang-here>? You may discover that the framework you might have chosen, isn’t the one you’d choose now. Or, better yet, you may discover a framework isn’t really needed at all.

</end-rant>

#14

A good framework is properly-tested code, almost certainly more tested by the maintainers and field-tested by thousands of users. And this is to say nothing of documentation. No, don’t start with a framework that you don’t need, but holding off until you’ve accumulated tons of code is even worse. Scolding has never been a particularly reliable methodology.

2 Likes
#15

I had the same thought. I don’t see how writing a bunch of plain JS and then realizing you need a framework is any better than picking a framework and outgrowing it. With the framework, you most likely also have a quicker MVP you can put into the real world and see if it works or not. I also strongly doubt simply writing “good” code and tests will let you magically scale well.

I do sometimes see abstractions used in frameworks causing beginners to think they do not need to understand the underlying language. Garbage in, garbage out, a framework will not save you there.

1 Like
#16

I appreciate your point of view @chuckadams. I certainly didn’t mean to scold. I have just worked on so many projects that chose frameworks early on when in reality, they weren’t needed at all. My takeaway is to make sure the framework is truly necessary. That’s all. Accumulating tons of code and then picking a framework wasn’t what I was trying to suggest, I was saying that there are usually other “problems” to solve before getting to that decision (i.e. domain/business logic, overall architecture, persistence layer, cloud provider / self host, etc… etc…). I definitely wasn’t suggesting that you write a ton of code and only then bring in a framework. That would indeed be a nightmare.

I hope you now understand my more general point. Thanks for the reply

#17

I strongly disagree with this idea. Documentation is your documentation. Tests are your tests. Tests can help provide examples for your documentation, but failing to provide documentation because ‘tests self-document’ is a bad idea. Tests only show how to use an object or function or component. They don’t tell you the big picture.

Maybe I’ve missed where frameworks try to trick you into not writing tests, but the folks I know who use frameworks also write tests. Tests are important. If you don’t write tests, you have bugs. If you do write tests, you have fewer bugs. You always need tests.

Sure, question the standard and look for better solutions. But realize that code you roll yourself will almost certainly be less tested than third party frameworks. And see above - if it isn’t covered by a test, then you should assume it’s bugged.

Rolling your own is great for small stuff, but don’t waste your time rolling your own when someone has a better tested and more flexible implementation sitting out there for you to use.

#18

@lasjorg thanks for the reply. See my response to @chuckadams.

I don’t see how writing a bunch of plain JS and then realizing you need a framework is any better than picking a framework and outgrowing it.

I wasn’t suggesting you write a ton of code and then say oh crap… now I need a framework. I was suggesting that you should know very certainly that a framework is indeed needed. In my experience, a framework is basically the first thing developers default to. I just think we need to challenge that. It should definitely not be first, so many things come first.

With the framework, you most likely also have a quicker MVP you can put into the real world and see if it works or not.

If you are putting things into the “real world” (assume you mean production) to see if it works or not, then I think we are not on the same page about much of anything. Your tests should prove if it works or not. Maybe I misunderstand your point though. If your point was just a quicker MVP, then that’s possible. However, MVP isn’t there for long and if you don’t properly prepare for changes/features, then a quick MVP isn’t valuable. It’s just a POC (proof of concept, maybe even a piece of crap? lol).

I just think we can do better as developers. I advocate for testing your code, and making it readable. That’s pretty much it. Framework or not, someone else needs to be able to understand “your” code. That’s the most important part.

Thanks again for replying @lasjorg

#19

By “works” I just meant is it worth the time and effort.

For most projects based on the initial requirements, you can fairly quickly determine if there is a need for a framework or not. The original post in this thread is talking about view libraries, like React. In my opinion, doing plain DOM manipulation for anything remotely complex is just not a good idea, short or long term.

Sure, trying to solve everything using “npm install” isn’t a good idea either but I also know when not to re-invent the wheel. Code isn’t “good” just because you wrote it. I definitely do not consider myself “better” than library authors writing battle-tested code with thousands or millions of users.

I don’t think anyone would disagree with this.

1 Like
#20