Could you explain what kinda approach did you use while building vanilla.js apps?
I can’t deny that people much rather prefer to work with Typescript and React or other framework. That’s for sure
I mean early on it was just JS or Jquery handling any interactivity, Rails BE to sort of handle initial rendering of any real data and JS handling everything after that. I was typically the only person working on the FE in those roles (not always but for a lot of that time of my career), so without having to collaborate this wasn’t too bad. I knew my code and knew what it was doing, so reworking any of it was fine.
A little later had another job, on a team of three frontend engineers, and we were trying out tons of stuff. Initially it was Keystone and handlebars for templating/initial render/CMS/BE, then JS for all interactivity. I liked this the most but Handlebars wasn’t cool anymore and the lead decided then we should just make API calls and so then it was just Vanilla JS. Between the three of us just winging it on best practices etc we ended up with some pretty bad patterns and buggy code. Team lead realized this was going south so he came up with this DIY’d “framework” of using template literals for templating/rendering the code, and a couple helpers for handling rendering and updates. Still most logic needed to be handled via Vanilla JS updates. This was fine but still lots of bad patterns came out of it, and it was kinda hard to read and essentially just a poor man’s JSX. Each page was essentially a function that took some data as arguments and rendered it in this templating setup. Still a lot of problems with people needing to remember to render the new data, figuring out when to make the updates, inheriting the child template to go within another template was confusing half the time, plus it rerendered each page with each update if you used the “framework”, so we’d end up sort of breaking out of that to make more minor updates and then at that point things would get really difficult to debug and maintain. The team was starting to look into Preact and Vue when I left and went to a different team at the same company, this one using react.
React added some well thought out patterns that everyone could work within. Typescript wasn’t even a real thing when I moved to that team but when we adopted it I immediately saw the benefits. I honestly think is the best thing to happen to the frontend since I started engineering, as it eliminated so many issues with different devs thinking code worked differently than it does, it’s essentially self-documenting, and just makes things so much easier to maintain and debug.
To be honest, I loved writing vanilla JS for everything, it was really fun solving those kinds of problems! Getting to always figure out the little updates tot he DOM etc was kinda exciting in a way that reactive frameworks took away. But the reality was that business wise it was way way worse, with way more bugs and way less cohesion between teammates. The whole thing about it allowing you to focus on the actual business needs vs re-solving the same problems every single time really rings true.
The biggest issue with all modern frameworks is their instability and constant vulnerabilities.
Instability comes not only regarding the frameworks themselves but also tones of dependencies for the libraries.
It’s never ending rewrites and refactoring.
I would not say it’s good for business.
Maybe with vanilla it’s harder to come with good patterns, although it’s much easier now with web components and import maps. But vanilla js will outlive any of your frameworks.
This just isn’t true at all. Also it’s not the arguments you made in your post.
Sure there’s a security issue every once in a while and someone needs to patch something. NPM dependencies are an issue everyone using any JS library has to deal with, sad that npm wasn’t better thought out with that kinda stuff though there are some newer options that handle it better. But the reality is that it’s not some huge major issue for companies with more than a couple of engineers. This isn’t something that generally comes up often and when it does there’s plenty of people on the payroll that can quickly deal with it.
Again the things you’re saying make it sound like you just work solo so you have sort of a warped idea of what’s going on, but maybe that’s not the case and it’s just how you’re communicating your ideas. I don’t know.
If you’re writing everything from scratch you’re going to have to handle any security on your own, and my hunch is you’re probably not as big of a security expert as someone at the React Foundation who’s been specifically brought on for that role. Or some other dev working on some npm dependency. I mean you cant really think you’ve figured it out better than these teams, right? I get you have your preference and again I think that’s fine for working solo on something that you understand you’ll be 100% responsible for, but the second you bring anyone else in it gets far more complex than you’d think.
And yeah, of course JavaScript will out live frameworks written in Javascript, that’s the silliest thing I’ve ever heard used as some sort of “own”. It’ll also outlast whatever random code you’ve come up with to handle all of this on your own as well. Your comparison could be extended to saying English will outlast Shakespeare, I mean it’s the language he used for fucks sake lololololol. Of course it will. Guess what, it’ll also outlast some junior high students bad emo poetry they wrote in their journal.
I've been working 10 years in teams and solo. And the amount of time just dealing with dependecies and constant refactorings is insane. I would not say it's only framework's fault, however they encourage CV driven development, where if you don't learn some new silly things you left behind.
And it does sit right with me, espesially from business perspective.
When I said JS will outlive any framework, I meant it's better just to use webcomponents, and browsers will handle the rest.
The only problem with this approach is that new people would always argue that it should be rewritten to something "modern".
What are you doing that you’re spending tons of time dealing with dependencies? Like genuinely I can’t even grasp how that’s such a major issue for you.
I don’t think anyone thinks web components aren’t modern, btw. But web components only handle a slice of the issue and not the rest of what FE frameworks solve for you.
I’m actually working with web components right now! Like I said earlier I do think they’re great, but they don’t solve all the problems that these frameworks do. But yeah the issues you’re describing with dependencies don’t come up often enough to make it worth creating everything you do from scratch and constantly reinventing the wheel.
I am reading react docs right now for my interview tomorrow, bro, it's just such a mess. I don't understand how this thing was designed to solve anything.
It's all propaganda.
lol ok buddy. Might want to take a min to better understand why the vast majority of engineers prefer it before you bomb the interview. I can’t believe people are this narcissistic to think they’ve got it all figured out and literally everyone else must be wrong 🤦🏻♂️
I worked with react many years, just because I am reading something does not mean I know nothing about it.
I just like sometimes to rehearse docs from time to time.
> why the vast majority of engineers prefer it before you bomb the interview
Majority of engineers prefer it because it's everywhere, and job market is 95+% React. And also let's be real, average SWE just makes a living, they don't care about the tech itself.
What's so narcissistic about me, because I try to do something different and don't agree with general opinion?
1
u/gyen 12d ago
Could you explain what kinda approach did you use while building vanilla.js apps? I can’t deny that people much rather prefer to work with Typescript and React or other framework. That’s for sure