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

Front End Help
#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)

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

2 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: