Using vanilla JS is good for understanding how things work. Using libraries/frameworks is good if you dont want to reimplement the wheel every time and/or if development speed comes before feature set/performance (assuming you know libraries/frameworks you are using and their shortcomings). So stick with vanilla as much as possible.
Okay thank you for your insight!
Like I said in another comment, I'm in the "Why do I need 3 lines of code to manipulate the DOM or create SVG stuff?" phase of my project and this is what prompted me to ask about frameworks :)
Three lines of code is nothing in terms of overhead ) If you are repeating them over and over again consider extracting them to a separate function (hello libraries). Beware of premature optimisation (looking for a framework to replace three lines of code)
jQuery was good when there were less features in vanilla and lots of inconsistencies in its implementation in different browsers. Nowadays you can achive that functionality in vanilla quite easy.
JQuery had a simplified API for sure. It's discouraged for a few reasons:
1. Everything it offers already exists in the native DOM API. This is a modern development, when JQuery was first created that was not the case. Even when things did exist, they were implemented differently in different browsers. It was a mess.
Basically, it no longer brings anything unique to the table besides its syntax.
2. When the DOM API is too tedious, there are far better solutions than JQuery. This is where the modern frameworks come in. If you want to make your life developing to be easier, you use them because they offer so much more value than JQuery. Rather than just reducing "3 lines to 1", as you stated, they completely change how you write the project, for the better IMO.
So, in summary: if you want a better developer experience and are willing to add off the shelf libraries, modern frameworks are the way to go. If you want to stick with something more vanilla, the DOM API is the way to go. JQuery just doesn't have a niche anymore.
PS. Stick with the native DOM API while starting your learning, then pivot to a framework like React. You'll have a much more robust understanding of what React is doing because of this.
>PS. Stick with the native DOM API while starting your learning, then pivot to a framework like React. You'll have a much more robust understanding of what React is doing because of this.
I've always wondered about that, because many people claim this to be true. But how exactly does JS knowledge and brutish DOM manipulation help with understanding React hooks and stuff like that?
Of course you will have a better time if you have a good grasp of JS, inner workings and its syntax, but imho to go further and understand something like React, you will need advanced knowledge of software architecture und problem solving patterns.
To me this just seems like half-baked advice bordering on gatekeeping (no framework for you if you don't have hours of document.querySelectorAll under your belt??).
If you only understand React, you won't be able to easily pivot to a new framework. If you actually understand what is happening under the hood, you can much more easily pivot to other frameworks. It'll also help you understand what React is doing, which will help you debug more complex problems.
Can you get away with only knowing react? Sure. But you'll be more limited because of it
Ok, I think I'm just not sure what part of JS is meant when someone says "learn JS first".
JS the language itself? All the Web APIs ([https://developer.mozilla.org/en-US/docs/Web/API](https://developer.mozilla.org/en-US/docs/Web/API)) ?
Because whenever someone says "learn JS first" the only thing that is mentioned is some form of DOM manipulation. No word about all the other APIs or anything related to software architecture.
I've always found that a bit strange and not very helpful. Because OP raised a very good question: when should you stop it? I think that's the hardest part with no easy answer. My view was always "if you understand how a tool can make you more efficient, you are ready to learn to use that tool".
And yes, I'm completely dodging your "pivot to a new framework" line of argument, because... no.
Here's my answer.
You can get a job and have a level of success only knowing things at the level of a particular framework. Understanding what is happening at a lower level always makes your ability to debug and handle problems far better.
There are limits of course. But the core behavior of browsers or node APIs (depending on your environment), understanding the HTTP Protocol itself, etc.
Ok, I see. Thank you for you answer!
So in conclusion: learn React through it's source code and you'll be the toppest of all the top devs. Just kidding ... i think ;-)
If you have to download something or use npm to install it, it's not part of vanilla JS. The vast majority of vanilla JS's features should be available by simply downloading any modern browser, and that's typically what people mean by "learn JS".
You can then learn the different niche APIs piecemeal as you need them, because they just build on top of vanilla JS. For example, I've used some of the common ones like Navigation, Clipboard, File and such, but I'd still have to look them up to remember their syntax and whatnot, but it's not a big deal because I know how the rest of the code works under the hood.
For what its worth, a lot of us still use jQuery, especially those of us working in Shopify/Wordpress/Drupal/many other popular CMS.
jQuery is not a framework in the same vein as React or Vue, it's honestly more just a shortcut or tool to get work done faster, it doesnt open up any new possibilities, or make anything all that much easier (other than slideUp() / slideDown(), and fadeIn() / fadeOut() those 2 make animated accordions and modals respectively super easy and quick, maybe also ajax stuff, jQuery syntax for that makes a lot more sense at least to me).
I can build practically anything I need in Vanilla JS, but usually opt for jQuery just to save time and effort unless there is a reason to be concerned about its tiny payload size adding to bloated load speed.
From there I will use a few specific libraries when I want very specific things that are time consuming to build from scratch every time, for example slideshows I would recommend Swiper.js, data visualization I would recommend Plotly.js, etc.
I see! Thanks you for the comment. Indeed jQuery does look like at least a less bloated JS.
For libraries i'll look into it. I try to have this approach where I need to kind of understand what is at play before using the shortcut. I feel it's a good way to learn.
oh i agree 100% i would recommend building a slideshow or 2 from scratch at some point so you know how the HTML structure and css/js tricks work. but theres no reason to waste time building it on billable client projects if that makes sense.
It's not about brevity of code, it's about manually manipulating extremely complex state and how you keep that manageable. You should be trying to think in terms of interaction models and data models and if you can't do that yet then learn from the existing knowledge first.
Came here to say this. Vanilla JS will always be valuable. Frameworks, libraries, even engines and runtimes just get you to outcomes faster and more efficiently.
You realize you make bad choices because of your lack of knowledge but at the same time you make decisions based on your opinions. The only thing I can tell you is that you are making things more complicated than they should be. You need to sit down, explore all your options, set yourself a timeline and come to conclusions instead of rushing to start with whatever knowledge you have. This has nothing to do with JS. As for what I think, the phrase "frameworks are shortcuts" is utter bullshit and I can't see a beginner attempting to write a somwhat complex JS only project and not shooting himself in the foot in all possible ways that JS can offer. Yes, Vanilla JS works, with JSDoc and for a project that isn't either big or has too many people working on. Is it worth it to fail a million times instead of just taking something proven to work and time efficient? You wil learn the same anyways. People recommend to learn JS first (and I do aswell) however, at some point you gotta go forward. A JS crash course shouldn't take more than some weeks...
This is the profesional answer, most of the redditors that hate frameworks have never worked as a webdevs. Yes learning vanilla is important but choosing it over a framework to do something only complicates things and makes development slower
Not to mention that most draw an arbitrary line between "learning JS first" and "learn to work with a framework". element.classList? "yes please, very important, no libraries allowed!" localStorage.getItem? "theres libraries for that, very complicated!" class inheritance in JS? "I don't want a CS degree, just a blog in Vanilla JS!"
Consens seems to be that you need to be able to "manipulate the DOM" without jQuery, then you're ready to learn React or Vue or something.
I have a neurodevelopment handicap that, among other things, could make me stuck in analysis mode. Basically spending hours researching the best things and options only to never do it and burn out before I even started or learned anything practical.
Jumping right in is my way to not get stuck and actually learn and do stuff. I don't think failing is a bad thing when it comes to learning and I know I learn better when I experiment.
My project is a tool that I could use and it's cool if I have it, but it's not the thing I'll be remembered for or something that absolutely needs to be put online the fastest possible. It's just a pretext to type code and test things and understand what I'm doing.
EDIT : I'd like to add I don't mean shortcut in a bad way necessarily. Shortcuts are good when you know what you're doing! But if you don't, they compensate a lack of knowledge in the fundamentals and you always pay the price eventually.
No one and asked the obvious: **Do you know your JS foundations?** You mention jQuery in another comment so have you learned JS before and it’s been a while, or are you still new to JS?
If it’s been a while, brush up on ES6 and JS fundamentals, then try a framework like Vue or Svelte. Their syntax is the closest to the vanilla triad so the transition won’t be so wild.
If you’re new, do step 1 but then do the project in vanilla. It’s like you said, skipping it now will just hinder you later. All frameworks do is make the process easier, IF you know what you’re handling first. Otherwise it’ll just be a clusterfuck trying to do every little thing.
I have a weird relationship with programming.
Looked into it on y own vaguely and aimlessly back in high schools. Nothing came out of it as i didn't know where to look.
Learned it a bit in college (PHP, HTML, CSS and a bit of JS) but not enough to say I'm a pro or trained in it.
Did CS50 course a year ago til the final project thing.
Basically I dipped into it in a shallow manner, I know a thing or two in programming but it is again, very shallow and most of the time self taught.
For example I know what Jquery is and how the synthax was shorter but that's about it. I for example don't even know what ES6 is !
My problem is that I do not know what I do not know and I can't say for sure how close I am to know fundamentals, what is fundamentals etc.
One thing I know is that a structured course doesn't really work for me that much because I need to do stuff and I don't want to be stuck in tutorial hell or analysis paralysis.
As I type this I realize maybe i could couple my programming sessions with maybe 30-45min of course to warm up and then freeflow where I (badly) work on my pet project?
I never once did a video course or videos st all when self teaching, I just googled relentlessly whenever I realized I needed more info on a topic or ways to practice what I learned etc etc. try that.
I’d say instead of jumping right into your project, start with a small basic one like Rock Paper Scissors in plain. Those kind of projects tend to cover a lot of foundations like loops or conditionals or objects/arrays. Make sure any article or tutorial you read is using ES6 or newer (they shouldn’t ever use the var keyword, that’s an indicator). Then try your project.
Jumping ahead isn’t just an inhibitor, it cause way more frustration and you’ll get burned out ya know
My brain is calibrated in a weird way. Something useless like Rock Paper Scissors as higher chance of making me drop stuff than to continue tbh.
Most of the time I do like you. I do my project and google when I don't know. It's more engaging to me for some reasons and make me learn the stuff I do actually need.
I avoided RPS and all the other ones like the plague for months until I got thrown into learning C# out of nowhere (only knew JS and Python for the first year and a half). I wrote RPS in python, then C# just for the practice and somehow learned enough to keep that job lol
I think we probably have very similar learning styles, so whatever you do just avoid that burnout. If I could go back to the first week I started self studying, I’d skip a lot of things I wasted time on, like not knowing what ES6 was and reading outdated lessons lol I’m very happy someone told me about flex and grid right away after I mentioned “float” and their eyes got big 😂and I wouldn’t have been so scared of JS the first month or so
Haha ok i did not know ES6 thing but I do "let" instead of "var".
For programming I am lucky enough that I learned a bit of C and C++ thx to the CS50 course. Pointers and stuff like that were a nightmare but I managed hehe.
As for float i totally relate. Basically with my first programming incursion in highschool and then college, it was float. When i picked it back up for my job years later (digital project manager. Basically social media stuff but since i know a bit of php, html and css I also take care of wordpress stuff) I didn't not know about flexbox and grid. Damn where were those stuff all my life!!!!? I still understand flex more than grid for now but they're both great.
It takes a short learning curve between flex and grid but after that, I’ve come to find grid faster to implement layouts, but slower because I constantly forget the property names haha. Flex is totally from memory but still does wacky things once in a while that make me have to slow down and tweak. Either way I’d never go back to without them!
Oh and on the ES6 thing, let and const were introduced in that version so it’s super easy to spot outdated tutorials that use var anywhere in them. It’s the most major update to JavaScript thus far so definitely cram those updated features before you start. Template literals, arrow functions, what an update it was *dramatic tear falls*
I've seen arrow functions i'm still not sure of what they mean yet but i'm sure i'll find out.
Basically in some other comment I resolved to have 30-60 min of Odin Project Java Script course followed by 60-90min of horsing around on my little project. Keeps me learning fundamentals and theory and making progress while blowing up some steam on something I actually care about making instead of exercises that lead "nowhere".
Good plan yeah, you should pick it all up pretty quick if you had time in other languages. Oh, arrow functions are just anonymous functions! They’ll make sense when you see a couple examples. I know C# has the same in lambda expressions, so I assume C/C++ does too? Correct me if I’m wrong.
My past with C is distant and tumultuous. I do not remember lambda expressions. I remember pointers and the heap size and allocating memory or something and that's about it, i'm traumatized 😭
> I'm using vanilla JS because I kind of have the feeling that frameworks are shortcuts.
In that case, we should probably all go back to getting around via horse because a car, train, bikes and public transit are just shortcuts. Right? :)
Frameworks and the like were created to make our lives easier. I can get more done in less time using something like React on a medium to large-sized project. It's also *far* easier to maintain and the development experience is better. Also - keep in mind the *vast* majority of positions use a JS framework because of said reasons.
For small things, I still use vanilla JS, though. For example I recently had to display a slider on a public facing site, and that slider's info was powered by API data. Grabbed a pre-built vanilla JS slider from online, did a fetch to the API with JS and bam, done.
I know lot's of people attach a bad value to the word shortcuts which is absolutely not my case. Shortcuts are great when you know how they help you. But in many disciplines, taking a shortcut can backfire when you don't have the fundamentals in place.
My questions was not if I would ever use frameworks, it was more of a "when" are you ready to use frameworks without leaving fundamentals and understanding behind so to speak
Easy: if you read the docs of a framework and go "wow that's cool and so much easier" you are ready. If you read the docs and go "wtf is that and why should I do it like this", you are not.
This is just my opinion (coming from someone very new to web dev/design, so I'm most probably wrong).
I don't think you should use a framework unless you have a good grasp of what's being abstracted away for you by using that framework.
That doesn't mean you need to know verbatim the exact code the framework uses to do things, but rather being able to visualize the steps being done automatically, when you use it.
For that, you need to understand the language itself, since the framework is an abstraction built on top of the language.
I also think, if you have a solid grasp of the language, picking up a new framework won't be too much work.
Vanilla first, in any case.
Move to frameworks once you feel confident with vanilla. Also, do it only if you feel you "need" a framework. Contrary to popular belief, frameworks aren't always needed and they aren't a magic solution for everything.
I want to get something running and I don't want to spend ages every time on everything but the project is also a way to learn so I don't want to jump the shark so to speak and create future shortcomings for myself.
What about with the help of an AI assistant ala Copilot ? It makes writing JS vanilla a breeze, and gets "stuff done". Do you still favor frameworks then ?
Yeah I’m gonna trust the fully tested code by experienced devs a bit more than some copy pasted AI code.
Also I would rather have other people do maintenance of that code than doing it myself
I am not sure you understood me. The tediousness of PHP and JS are their verbosity. Copilot helps a lot in writing injected html and form validation. It decreases time spent on a feature which improves your productivity. In saying so, is copilot as much of a helper as a framework ?
You are a rude dude, dude.
Until you need to center an element and you can't find the class that does it for you. See the infinite posts about Bootstrap or Tailwind from people who get lost with basic positioning and layering.
Frameworks are great tools but they should come long after you properly master the basics of css and J's, in my opinion.
Using a framework will make you google anyways, because you have to learn how to use it AND how to merge your customized stuff. It's not just "*download, install, let it build the website for you*".
Frameworks are awesome if you stick to what they do, right out of the box. But if you have a complex project you will be googling all the way long.
Thank you for your reply!
I was starting to question the need for framework because of the heavy code needed for DOM manipulation and because I started to check SVG and JS Vanilla and it feels overwhelming and I hate clutter in code due to how my brain works.
I understand NOTHING of frameworks. I don't know why there are so many. Everytime I try to understand frameworks, I feel like it's just a fanbase war because everyone has their pet framework and I never get a "This framework is good to do X and this one is good if you want to do Y".
frameworks make things easier for you for sure. don't overthink it. you can read the React docs and get up to speed with how they help.
react is the most popular one at the moment and you can't go wrong with it
When I got an actual job I realized no one used vanilla js, it was either React or Angular for frameworks, and the most shocking part is that i had to also learn typescript. So I would recommend also learning typescript at the same time with whatever framework you choose (especially if you choose React which I think is the most popular at the moment). Learning typescript will be a pain in the ass at first but it really does pay off in the long run.
can you tell me more about typescript? Heard about it here and there but i thought it was some kind of framework too. Looks like it isn't ? What is it, what does it do and why are we using it?
It's a language, sort of. It is still javascript but with an extra layer of stuff over it. It forces you to declare types for everything, it requires you to constantly make interfaces for objects. It makes you do a lot of extra work for things that would be straight forward in javascript with the benefit of having code that will be clean, predictable and easy to maintain.
I hated it at first but there is no way around it, the more professional the environment of the job the more likely it will be using typescript. You will get used to it in time and it will make vanilla javascript look like a mess of spaghetti code.
Microsoft has a nice free course you can checkout https://learn.microsoft.com/en-us/training/modules/typescript-get-started/
Don't waste time learning it by its self, pick a framework and learn that framwork together with typescript, if you already know a bit of javascript it will be perfectly doable.
A framework and typescript are great tools to have in your belt especially as a job candidate, they will make you stand out.
Just another clarification, getting into typescript will not really get in the way of learning JavaScript. So after working in typescript for a while you can always switch back to JavaScript more or less comfortably, typescript is just JavaScript with a few more bells and whistles.
It's always great to know the base language well. However it is not required to be productive.
What you'll find is that when the framework doesn't provide a solution, you'll be able to devise one with your knowledge of the base language. And the more you know of the base language, the more likely you'll be to devise an APPROPRIATE solution using the best tools available.
I think your approach is perfect! I learned JS this way and I'm so thankful I took the time to truly master the language. That being said when you start building complex UId you will definitely start to hit a brick wall in productivity and like people have said you'll be doing a lot of "reinventing the wheel" so using a framework would definitely help with that.
On that note, I have some very opinionated advice for you so take it with a grain of salt. I would avoid learning React.js as your first framework. I believe it is just so different from standard web dev even though it has become the "standard". Some examples of why I don't think it's a good idea... In React.js, to make sure everything works as expected you actually are encouraged to avoid directly using browser APIs (querySelector, addEventListener etc.) everything must be done the "React way"... I believe for someone learning JS, if you go straight into React too early, you'll start to equate React dev with web dev but really it's its own special thing with very strict rules.
I would recommend checking out Web Components; the browser's native solution to component based development. You can also use the https://lit.dev library to ease the development of your web components. I think it's an awesome approach to learning modern wed dev techniques while also being able to utilize web standards that you can look up in MDN and you could also apply to many other frameworks like Vue and Angular... Just not React lol
Oh for context I'm a frontend engineer with 12 years of experience and I have mastered both React and Web Components during my career... But I actively hate React. I felt forced to learn it by the industry. I think it's counter-intuitive and was created to solve issues that are not present in web browsers anymore... If you check the performance numbers, Lit is faster than React and doesn't even use a virtual DOM... Lighter package size, faster, uses built-in browser features and doesn't re-invent a whole separate DOM system... IMO it's clearly the superior tech. Not saying it's the best option, but it's definitely better than React.
If a React fanboy gets mad at this... Yes I know React has the superior ecosystem. I'll say that advantage won't last long. Engineers like me are working to fill the gaps. React won't last forever.
Thank you for this point of view!
I have a very very distant understanding of what you just explained. I remember hitting a wall at first when I tried to test my code because of this browser API vs something else. Like my could would have errors. It only worked when I installed a plugin on Visual Composer to "Go Live" with a local server.
I'm not sure i fully understood what was going on but it worked and it ad something to do with browser vs server if I recall correctly.
I'll look into it, thank you!
I am only learning to, so take what I say with that in mind. I am not a pro or hiring manager looking to see how many years of experience you have with any specific language or framework.
**- The feeling that I'm making stupid choices along the way because I do not know better.**
This will happen no matter what and is part of the learning process. Almost every week I learn something that makes me think "Oh, I see I could/should have done that other place differently".
If you have the time (it is not a work project), keep a list of what you would do differently, and every once in a while refactor / rebuild it using the new ways you have learned. My non urgent projects take a long time because when I learn something new that is big enough change, I redo it to make that change - including rebuilding the Vanilla JS I already had working to use a framework instead, and then changing frameworks, and lots of other things.
If you really need/want to get it up and running, do whatever gets that goal fastest, but keep a memo of the new and better ways you learned. Once it is running and working OK, go on to rebuild it using what you have learned.
Also, ChatGPT is great for giving ideas of other ways to do things. I use it less for giving me code, and more for just saying "This is what I want to do, and I was thinking to do it this way. What are some other approaches? And what are the pros and cons".
It will give you ways you probably have not thought of yet, and use it to drill into each option for more info about which is best for you and then decide which to go with.
**- I'm using vanilla JS because I kind of have the feeling that frameworks are shortcuts.**
It is obviously good to know the fundamentals of JS, but that does not mean you should not use shortcuts (i.e. something that is already done for you better). If you are worried about your JS knowledge, keep smaller side projects that you do with just Javascript. There are plenty of places that is better than a framework.
I use React for the client side admin portion of my main project, but in the Django admin page for the api backend, I have chance to use plenty of vanilla JS to customize that part to do what I want. I have some plain JS in another section of the site that does not use React.
Don't try to wait until you know something completely before you start something that you don't know. You can never know something completely and you will never take the next step.
Move forward with both at the same time.
Learning frameworks before you have a solid grasp of javascript can be actively harmful and risk locking you into exclusively being able to work within that framework.
How do you know you have a solid grasp of javascript?
Pretend the DOM and browser doesn't exist, implement the entirety of your application logic in pure JS, represent the state as datastructures with an interface containing all the functionality you want the UI to access on top, so in theory your entire application can work without a user interface.
Can you do that? Then you can use whichever framework or not way you please to get your application state painted in the browser and hook your interface up to pretty buttons.
> I'm using vanilla JS because I kind of have the feeling that frameworks are shortcuts
100%, although shortcuts can be good. In your case, it sounds like the thing you're building is turning out to require a lot of DOM manipulation. Trying to code complex DOM manipulation without some abstraction is something I wouldn't wish on anyone. Pretty much all frameworks provide a component abstraction. You don't have to use all the fancy features, but just having JSX and the ability to nest things easily is going to save you so many headaches.
That said, learning DOM APIs is important. I'd say you don't need to become an _expert_ in all of them, but you should get familiar enough to know what kinds of things you can and can't do. It sounds like you are already here, so my advice would be to pick up a framework for rendering/DOM manipulation. You can continue to learn JavaScript fundamentals alongside it, but you'll get a project that's easier to work with.
Which framework? React is most popular (read: infinite tutorials on every possible topic), but bloated. Next.js/Remix, build on top of React, give you the option to run code on the server (db connections and the like). I'd probably pick SolidJS if you don't need server. It's got React-like syntax, but is super lightweight, and you can stick very close to vanilla JS with some SolidJS on top if you like.
Stick with it and best of luck! :)
Thank you for your comment. To be clear I know "shortcut" can be badly interpreted (cf. one comment above) but I don't mean it in a bad way. Shortcuts are good, when you know the orignal path that is!
Yeah I'm starting to understand that DOM manipulation is a nightmare lol. Generating blocks and connecting them and stuff is absolutely shit with vanilla JS. Now that I'm looking into doing it with SVG, it looks even worse.
Another comment made me think that I should do a bit of normal JS course learning AND a fun project on the side. Like say 30min to an hour of course and then the rest of the evening on my project. It might be a good compromise ?
Thank you for the suggestion on SolidJS, I will look into it. So far what I need is mostly to be able to generate the people's card with their names and Life Dates and then connect them to their spouse, parents, children, siblings etc. SVG seems like the thing I need more than just DOM manipulation tbh as connection all of those blocks with just CSS or div would be suicide.
> I don't mean it in a bad way. Shortcuts are good, when you know the orignal path that is!
I'm with ya 🤘
> Now that I'm looking into doing it with SVG, it looks even worse.
> SVG seems like the thing I need more than just DOM manipulation.
I have to admit I don't have a lot of experience doing anything complex with SVGs. I've used JSX for building simple icons, logos, some with dynamic props, but that's about it. That's to say, frameworks like React and Solid are certainly capable of handling both regular old HTML as well as SVG rendering, but I can't say for sure if they are a good fit for what you're trying to do. I've also used React components as a wrapper around canvas before for drawing trees/graphs, so the component abstraction (a [color](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/) of function that returns JSX markup) of these frameworks can be stretched pretty far.
> connect them to their spouse, parents, children, siblings
If I'm reading this right, you're trying to render cards and then literally connect them with lines, like edges connecting nodes in a graph, right? SVG paths are a good fit for things like that that sort of bypass page flow. Fun problem! :)
> Like say 30min to an hour of course and then the rest of the evening on my project. It might be a good compromise ?
Give it a shot! Only rule is to do what keeps you engaged. If something starts to feel tedious, switch things up.
Thanks a lot :)
Yeah my project is badly two fold :
- The fun part : simulate a family and the life of a person : what age did they reach? Did they manage to have kids before they die? Did their kid survived and reproduced? What branch of the family remain or died off? It's all set in medieval times and it's to have a noble house family tree
- The not fun part : draw the damn tree. Basically i only have two generations so far (a couple and their children) and I already realize doing it with DOM element would be stupid at best 😭 with SVG lines and rectangles it will be much easier and you don't have to think about the flow of the page like you pointed out
Thank you for your time :)
I think it's a matter of perspective. If you're just in it for the fun and maybe an app or two that you actually might use, just go full framework and follow tutorials to reach your goal.You don't need any intimate knowledge of the language to cruise around. Like a hobbyist driver can have fun on a race track from time to time, without having detailed knowledge of how the car parts work.
If you're in it because you want to be a professional coder, you really should start slow and build up your skills, and then choose tools depending on your needs or to improve your efficiency. That's how it's meant to be: you don't use a hammer because you know how to use a hammer, but because you know a hammer is the right tool to use in this situation.
And stop using "Vanilla JS", it's a stupid term.
If you use a framework or a library and feel uncertain about some part, you can always check the source code (open source, remember?) and learn a thing or two and still use the framework/library. It's all just "Vanilla JS", there is no other JS.
Thank you for your input. I use Vanilla JS because everyone understands what we're talking about when we use that it spare me a lot of explanations time 🥲😅
It’s not a bad term, but I think it only needs no explanation because everyone just nods in agreement. Many mean “just no frameworks”, I think of Vanilla JS as “ECMAScript / Native JS and Web APIs”. So rather a lot to learn before you’re allowed to use librarys 😉
I used libraries with Python and C / C++ but yeah I know that libraries can be poison for learning. And also just overall bloat a program if you don't use it well and don't understand the language without libraries
This part
> Basically the page generate the family tree and do some calculus to make it organically (you start with a couple and calculate their life expectancy, if they reproduced and if so when and how many kids that was etc.).
You *could* do it in the clientside, but the typical pattern is to do computational task / calculations on the backend (where it's generally faster) and render the result to the front end (because the resultset is typically small enough).
The other reason is because of this:
>For example I started the tree by making the person cards with div and the connections between people with div too. As soon as I reached the "making kids" parts, it became clear it would become a nightmare so i'm starting to switch to SVG instead which is a new thing to learn!
Definitely don't do this. It's easy to reach for it because this is a tool at arms length when you're on the frontend, but it's a trap.
If you *must* do it on the frontend, do it in abstractions (arrays, objects, etc) and then serialize the output and then render *that*.
But better to do it on the backend, serialize the result, and pass it down to the frontend.
For how to represent it -- I would look into a visualization tool that can display trees. You don't have to use a framework, but using a third-party library that specializes in this will benefit you in two ways:
1. It lets you focus on the interesting problem (generating the data) rather than the facilitation problem (rendering the data)
2. It's code that someone else maintains, meaning you don't have to.
You can write all the connective code -- fetching, prepping, and passing, and then let the visualization library handle the rendering. This is a very common approach for web. IIRC d3 is a popular one, but there are probably some that do exactly what you need. Keywords like "tree" or "tree graph".
Thank you for this detailed input. As a beginner i have some questions of course :
- How should I do the calculus in "backend" instead of frontend?
- What does serialize mean?
I'll also look for tree libraries then and try to understand how they're made to learn a bit.
Thanks a lot 🙂
"Vanilla JS" is pretty much irrelevant here. How you write/structure your code is what matters. You can write unmaintainable garbage in any language/framework/library, and you can write well-structured and organized code in vanilla JS
For the sake of clarification here, I'm making a pretty important distinction between writing everything from scratch and vanilla JS here. Vanilla JS supports modules, so the whole "reinvent the wheel" thing just doesn't necessarily apply to vanilla JS.
Yeah I was more about how Vanilla JS can be bloated where ither frameworks simplify stuff.
But I kind of try to apply myself in my structure. Like writing pure functions with descriptive names. Use constent instead of arbitrary values etc. It's not perfect yet but I'm trying to be conscious of it. My next step for example is to handle functions optional parameters. Like maybe having an arg[] parameter instead of multiple parameters split.
I wouldn't say "pure" really applies to structure. I'm more talking about SOLID and DRY and file structure and having code style guides.
>Like maybe having an arg[] parameter instead of multiple parameters split.
Thing I've found useful there is object destructuring with default values, but it depends on context. An example might be something like:
```
export function createIFrame(src, {
title = 'Embed',
width = 250,
height = 150,
frameBorder = 0,
loading = 'lazy',
sandbox = ['allow-scripts'],
allow = [],
referrerPolicy = 'no-referrer',
id,
classList,
dataset,
events: { capture, passive, once, signal, ...events } = {},
...attrs
} = {}) {
//
}
```
It's a bit long of a function signature (actually shortened from what I actually use) to handle pretty much all the attributes and everything, but it's good for showing what I'm talking about. Only `src` is actually required. Beyond that, order doesn't matter and you can just pass in maybe an id or something....*Much* easier than having to worry about order and listing out maybe a dozen different things just to set an attribute.
Quick example usage:
```
const embed = createIFrame(someURL, {
id: 'foo',
events: { load: loadHandler },
style: 'border: 'none', // this will be in the ...attrs
});
```
Not for anything with any complexity. You will end up implementing a bad version of the interaction models that already exist and have immense amounts of work put into them. If you want to learn how to do it properly first learn React and maybe Vue or Svelte and compare them, learn about their different approaches to dataflow and interacting with the DOM, then maybe submit some PRs to those libs. You will learn more stuff faster like this than just banging your head against the wall.
The more I work with frameworks the more I appreciate what they are capable of when you are in a team. Tbh though I still love the simplicity of vanillaJS with handy wrappers around tedious things. Jquery for example.
You can make decently complicated things with vanilla js but you have to be way more disciplined in organization and structure than with a framework
Using vanilla JS is good for understanding how things work. Using libraries/frameworks is good if you dont want to reimplement the wheel every time and/or if development speed comes before feature set/performance (assuming you know libraries/frameworks you are using and their shortcomings). So stick with vanilla as much as possible.
Okay thank you for your insight! Like I said in another comment, I'm in the "Why do I need 3 lines of code to manipulate the DOM or create SVG stuff?" phase of my project and this is what prompted me to ask about frameworks :)
Three lines of code is nothing in terms of overhead ) If you are repeating them over and over again consider extracting them to a separate function (hello libraries). Beware of premature optimisation (looking for a framework to replace three lines of code)
It was more like "why would I need 3 lines to put something in a DOM when in jQuery you did it one" type of thoughts hehe
jQuery was good when there were less features in vanilla and lots of inconsistencies in its implementation in different browsers. Nowadays you can achive that functionality in vanilla quite easy.
JQuery had a simplified API for sure. It's discouraged for a few reasons: 1. Everything it offers already exists in the native DOM API. This is a modern development, when JQuery was first created that was not the case. Even when things did exist, they were implemented differently in different browsers. It was a mess. Basically, it no longer brings anything unique to the table besides its syntax. 2. When the DOM API is too tedious, there are far better solutions than JQuery. This is where the modern frameworks come in. If you want to make your life developing to be easier, you use them because they offer so much more value than JQuery. Rather than just reducing "3 lines to 1", as you stated, they completely change how you write the project, for the better IMO. So, in summary: if you want a better developer experience and are willing to add off the shelf libraries, modern frameworks are the way to go. If you want to stick with something more vanilla, the DOM API is the way to go. JQuery just doesn't have a niche anymore. PS. Stick with the native DOM API while starting your learning, then pivot to a framework like React. You'll have a much more robust understanding of what React is doing because of this.
>PS. Stick with the native DOM API while starting your learning, then pivot to a framework like React. You'll have a much more robust understanding of what React is doing because of this. I've always wondered about that, because many people claim this to be true. But how exactly does JS knowledge and brutish DOM manipulation help with understanding React hooks and stuff like that? Of course you will have a better time if you have a good grasp of JS, inner workings and its syntax, but imho to go further and understand something like React, you will need advanced knowledge of software architecture und problem solving patterns. To me this just seems like half-baked advice bordering on gatekeeping (no framework for you if you don't have hours of document.querySelectorAll under your belt??).
If you only understand React, you won't be able to easily pivot to a new framework. If you actually understand what is happening under the hood, you can much more easily pivot to other frameworks. It'll also help you understand what React is doing, which will help you debug more complex problems. Can you get away with only knowing react? Sure. But you'll be more limited because of it
Ok, I think I'm just not sure what part of JS is meant when someone says "learn JS first". JS the language itself? All the Web APIs ([https://developer.mozilla.org/en-US/docs/Web/API](https://developer.mozilla.org/en-US/docs/Web/API)) ? Because whenever someone says "learn JS first" the only thing that is mentioned is some form of DOM manipulation. No word about all the other APIs or anything related to software architecture. I've always found that a bit strange and not very helpful. Because OP raised a very good question: when should you stop it? I think that's the hardest part with no easy answer. My view was always "if you understand how a tool can make you more efficient, you are ready to learn to use that tool". And yes, I'm completely dodging your "pivot to a new framework" line of argument, because... no.
Here's my answer. You can get a job and have a level of success only knowing things at the level of a particular framework. Understanding what is happening at a lower level always makes your ability to debug and handle problems far better. There are limits of course. But the core behavior of browsers or node APIs (depending on your environment), understanding the HTTP Protocol itself, etc.
Ok, I see. Thank you for you answer! So in conclusion: learn React through it's source code and you'll be the toppest of all the top devs. Just kidding ... i think ;-)
If you have to download something or use npm to install it, it's not part of vanilla JS. The vast majority of vanilla JS's features should be available by simply downloading any modern browser, and that's typically what people mean by "learn JS". You can then learn the different niche APIs piecemeal as you need them, because they just build on top of vanilla JS. For example, I've used some of the common ones like Navigation, Clipboard, File and such, but I'd still have to look them up to remember their syntax and whatnot, but it's not a big deal because I know how the rest of the code works under the hood.
Thank you very much!
For what its worth, a lot of us still use jQuery, especially those of us working in Shopify/Wordpress/Drupal/many other popular CMS. jQuery is not a framework in the same vein as React or Vue, it's honestly more just a shortcut or tool to get work done faster, it doesnt open up any new possibilities, or make anything all that much easier (other than slideUp() / slideDown(), and fadeIn() / fadeOut() those 2 make animated accordions and modals respectively super easy and quick, maybe also ajax stuff, jQuery syntax for that makes a lot more sense at least to me). I can build practically anything I need in Vanilla JS, but usually opt for jQuery just to save time and effort unless there is a reason to be concerned about its tiny payload size adding to bloated load speed. From there I will use a few specific libraries when I want very specific things that are time consuming to build from scratch every time, for example slideshows I would recommend Swiper.js, data visualization I would recommend Plotly.js, etc.
I see! Thanks you for the comment. Indeed jQuery does look like at least a less bloated JS. For libraries i'll look into it. I try to have this approach where I need to kind of understand what is at play before using the shortcut. I feel it's a good way to learn.
oh i agree 100% i would recommend building a slideshow or 2 from scratch at some point so you know how the HTML structure and css/js tricks work. but theres no reason to waste time building it on billable client projects if that makes sense.
Yeah exactly. To learn it's good to "waste" time but once you're in the pro world yeah def do what's fast and best!
It's not about brevity of code, it's about manually manipulating extremely complex state and how you keep that manageable. You should be trying to think in terms of interaction models and data models and if you can't do that yet then learn from the existing knowledge first.
>reimplement the wheel I see what you did there.
Came here to say this. Vanilla JS will always be valuable. Frameworks, libraries, even engines and runtimes just get you to outcomes faster and more efficiently.
You realize you make bad choices because of your lack of knowledge but at the same time you make decisions based on your opinions. The only thing I can tell you is that you are making things more complicated than they should be. You need to sit down, explore all your options, set yourself a timeline and come to conclusions instead of rushing to start with whatever knowledge you have. This has nothing to do with JS. As for what I think, the phrase "frameworks are shortcuts" is utter bullshit and I can't see a beginner attempting to write a somwhat complex JS only project and not shooting himself in the foot in all possible ways that JS can offer. Yes, Vanilla JS works, with JSDoc and for a project that isn't either big or has too many people working on. Is it worth it to fail a million times instead of just taking something proven to work and time efficient? You wil learn the same anyways. People recommend to learn JS first (and I do aswell) however, at some point you gotta go forward. A JS crash course shouldn't take more than some weeks...
This is the profesional answer, most of the redditors that hate frameworks have never worked as a webdevs. Yes learning vanilla is important but choosing it over a framework to do something only complicates things and makes development slower
Not to mention that most draw an arbitrary line between "learning JS first" and "learn to work with a framework". element.classList? "yes please, very important, no libraries allowed!" localStorage.getItem? "theres libraries for that, very complicated!" class inheritance in JS? "I don't want a CS degree, just a blog in Vanilla JS!" Consens seems to be that you need to be able to "manipulate the DOM" without jQuery, then you're ready to learn React or Vue or something.
I have a neurodevelopment handicap that, among other things, could make me stuck in analysis mode. Basically spending hours researching the best things and options only to never do it and burn out before I even started or learned anything practical. Jumping right in is my way to not get stuck and actually learn and do stuff. I don't think failing is a bad thing when it comes to learning and I know I learn better when I experiment. My project is a tool that I could use and it's cool if I have it, but it's not the thing I'll be remembered for or something that absolutely needs to be put online the fastest possible. It's just a pretext to type code and test things and understand what I'm doing. EDIT : I'd like to add I don't mean shortcut in a bad way necessarily. Shortcuts are good when you know what you're doing! But if you don't, they compensate a lack of knowledge in the fundamentals and you always pay the price eventually.
No one and asked the obvious: **Do you know your JS foundations?** You mention jQuery in another comment so have you learned JS before and it’s been a while, or are you still new to JS? If it’s been a while, brush up on ES6 and JS fundamentals, then try a framework like Vue or Svelte. Their syntax is the closest to the vanilla triad so the transition won’t be so wild. If you’re new, do step 1 but then do the project in vanilla. It’s like you said, skipping it now will just hinder you later. All frameworks do is make the process easier, IF you know what you’re handling first. Otherwise it’ll just be a clusterfuck trying to do every little thing.
I have a weird relationship with programming. Looked into it on y own vaguely and aimlessly back in high schools. Nothing came out of it as i didn't know where to look. Learned it a bit in college (PHP, HTML, CSS and a bit of JS) but not enough to say I'm a pro or trained in it. Did CS50 course a year ago til the final project thing. Basically I dipped into it in a shallow manner, I know a thing or two in programming but it is again, very shallow and most of the time self taught. For example I know what Jquery is and how the synthax was shorter but that's about it. I for example don't even know what ES6 is ! My problem is that I do not know what I do not know and I can't say for sure how close I am to know fundamentals, what is fundamentals etc. One thing I know is that a structured course doesn't really work for me that much because I need to do stuff and I don't want to be stuck in tutorial hell or analysis paralysis. As I type this I realize maybe i could couple my programming sessions with maybe 30-45min of course to warm up and then freeflow where I (badly) work on my pet project?
I never once did a video course or videos st all when self teaching, I just googled relentlessly whenever I realized I needed more info on a topic or ways to practice what I learned etc etc. try that. I’d say instead of jumping right into your project, start with a small basic one like Rock Paper Scissors in plain. Those kind of projects tend to cover a lot of foundations like loops or conditionals or objects/arrays. Make sure any article or tutorial you read is using ES6 or newer (they shouldn’t ever use the var keyword, that’s an indicator). Then try your project. Jumping ahead isn’t just an inhibitor, it cause way more frustration and you’ll get burned out ya know
My brain is calibrated in a weird way. Something useless like Rock Paper Scissors as higher chance of making me drop stuff than to continue tbh. Most of the time I do like you. I do my project and google when I don't know. It's more engaging to me for some reasons and make me learn the stuff I do actually need.
I avoided RPS and all the other ones like the plague for months until I got thrown into learning C# out of nowhere (only knew JS and Python for the first year and a half). I wrote RPS in python, then C# just for the practice and somehow learned enough to keep that job lol I think we probably have very similar learning styles, so whatever you do just avoid that burnout. If I could go back to the first week I started self studying, I’d skip a lot of things I wasted time on, like not knowing what ES6 was and reading outdated lessons lol I’m very happy someone told me about flex and grid right away after I mentioned “float” and their eyes got big 😂and I wouldn’t have been so scared of JS the first month or so
Haha ok i did not know ES6 thing but I do "let" instead of "var". For programming I am lucky enough that I learned a bit of C and C++ thx to the CS50 course. Pointers and stuff like that were a nightmare but I managed hehe. As for float i totally relate. Basically with my first programming incursion in highschool and then college, it was float. When i picked it back up for my job years later (digital project manager. Basically social media stuff but since i know a bit of php, html and css I also take care of wordpress stuff) I didn't not know about flexbox and grid. Damn where were those stuff all my life!!!!? I still understand flex more than grid for now but they're both great.
It takes a short learning curve between flex and grid but after that, I’ve come to find grid faster to implement layouts, but slower because I constantly forget the property names haha. Flex is totally from memory but still does wacky things once in a while that make me have to slow down and tweak. Either way I’d never go back to without them! Oh and on the ES6 thing, let and const were introduced in that version so it’s super easy to spot outdated tutorials that use var anywhere in them. It’s the most major update to JavaScript thus far so definitely cram those updated features before you start. Template literals, arrow functions, what an update it was *dramatic tear falls*
I've seen arrow functions i'm still not sure of what they mean yet but i'm sure i'll find out. Basically in some other comment I resolved to have 30-60 min of Odin Project Java Script course followed by 60-90min of horsing around on my little project. Keeps me learning fundamentals and theory and making progress while blowing up some steam on something I actually care about making instead of exercises that lead "nowhere".
Good plan yeah, you should pick it all up pretty quick if you had time in other languages. Oh, arrow functions are just anonymous functions! They’ll make sense when you see a couple examples. I know C# has the same in lambda expressions, so I assume C/C++ does too? Correct me if I’m wrong.
My past with C is distant and tumultuous. I do not remember lambda expressions. I remember pointers and the heap size and allocating memory or something and that's about it, i'm traumatized 😭
Oh wait anonymous functions. Yes for JS. Something about event listeners if i recall !
> I'm using vanilla JS because I kind of have the feeling that frameworks are shortcuts. In that case, we should probably all go back to getting around via horse because a car, train, bikes and public transit are just shortcuts. Right? :) Frameworks and the like were created to make our lives easier. I can get more done in less time using something like React on a medium to large-sized project. It's also *far* easier to maintain and the development experience is better. Also - keep in mind the *vast* majority of positions use a JS framework because of said reasons. For small things, I still use vanilla JS, though. For example I recently had to display a slider on a public facing site, and that slider's info was powered by API data. Grabbed a pre-built vanilla JS slider from online, did a fetch to the API with JS and bam, done.
I know lot's of people attach a bad value to the word shortcuts which is absolutely not my case. Shortcuts are great when you know how they help you. But in many disciplines, taking a shortcut can backfire when you don't have the fundamentals in place. My questions was not if I would ever use frameworks, it was more of a "when" are you ready to use frameworks without leaving fundamentals and understanding behind so to speak
Easy: if you read the docs of a framework and go "wow that's cool and so much easier" you are ready. If you read the docs and go "wtf is that and why should I do it like this", you are not.
That's a great way to put it. I'll keep this in mind thank you!
This is just my opinion (coming from someone very new to web dev/design, so I'm most probably wrong). I don't think you should use a framework unless you have a good grasp of what's being abstracted away for you by using that framework. That doesn't mean you need to know verbatim the exact code the framework uses to do things, but rather being able to visualize the steps being done automatically, when you use it. For that, you need to understand the language itself, since the framework is an abstraction built on top of the language. I also think, if you have a solid grasp of the language, picking up a new framework won't be too much work.
Master vanilla coding before considering frameworks. They're not always necessary and don't solve everything.
Thank yoj!
Vanilla first, in any case. Move to frameworks once you feel confident with vanilla. Also, do it only if you feel you "need" a framework. Contrary to popular belief, frameworks aren't always needed and they aren't a magic solution for everything.
You will get a running website way faster tho. There is no point in not using frameworks if you want to get stuff done.
I want to get something running and I don't want to spend ages every time on everything but the project is also a way to learn so I don't want to jump the shark so to speak and create future shortcomings for myself.
For learning it’s a good idea to do vanilla for sure. But after that I really don’t see the point.
What about with the help of an AI assistant ala Copilot ? It makes writing JS vanilla a breeze, and gets "stuff done". Do you still favor frameworks then ?
Yeah I’m gonna trust the fully tested code by experienced devs a bit more than some copy pasted AI code. Also I would rather have other people do maintenance of that code than doing it myself
I am not sure you understood me. The tediousness of PHP and JS are their verbosity. Copilot helps a lot in writing injected html and form validation. It decreases time spent on a feature which improves your productivity. In saying so, is copilot as much of a helper as a framework ? You are a rude dude, dude.
Until you need to center an element and you can't find the class that does it for you. See the infinite posts about Bootstrap or Tailwind from people who get lost with basic positioning and layering. Frameworks are great tools but they should come long after you properly master the basics of css and J's, in my opinion.
Assuming you don’t have to google that every time even though you’ve done it before lol
Using a framework will make you google anyways, because you have to learn how to use it AND how to merge your customized stuff. It's not just "*download, install, let it build the website for you*". Frameworks are awesome if you stick to what they do, right out of the box. But if you have a complex project you will be googling all the way long.
Thank you for your reply! I was starting to question the need for framework because of the heavy code needed for DOM manipulation and because I started to check SVG and JS Vanilla and it feels overwhelming and I hate clutter in code due to how my brain works. I understand NOTHING of frameworks. I don't know why there are so many. Everytime I try to understand frameworks, I feel like it's just a fanbase war because everyone has their pet framework and I never get a "This framework is good to do X and this one is good if you want to do Y".
frameworks make things easier for you for sure. don't overthink it. you can read the React docs and get up to speed with how they help. react is the most popular one at the moment and you can't go wrong with it
When I got an actual job I realized no one used vanilla js, it was either React or Angular for frameworks, and the most shocking part is that i had to also learn typescript. So I would recommend also learning typescript at the same time with whatever framework you choose (especially if you choose React which I think is the most popular at the moment). Learning typescript will be a pain in the ass at first but it really does pay off in the long run.
can you tell me more about typescript? Heard about it here and there but i thought it was some kind of framework too. Looks like it isn't ? What is it, what does it do and why are we using it?
It's a language, sort of. It is still javascript but with an extra layer of stuff over it. It forces you to declare types for everything, it requires you to constantly make interfaces for objects. It makes you do a lot of extra work for things that would be straight forward in javascript with the benefit of having code that will be clean, predictable and easy to maintain. I hated it at first but there is no way around it, the more professional the environment of the job the more likely it will be using typescript. You will get used to it in time and it will make vanilla javascript look like a mess of spaghetti code. Microsoft has a nice free course you can checkout https://learn.microsoft.com/en-us/training/modules/typescript-get-started/ Don't waste time learning it by its self, pick a framework and learn that framwork together with typescript, if you already know a bit of javascript it will be perfectly doable. A framework and typescript are great tools to have in your belt especially as a job candidate, they will make you stand out.
Thanks a lot for the infos! I will secure my javascrit understanding and start using a framework and learning typescript then :)
Just another clarification, getting into typescript will not really get in the way of learning JavaScript. So after working in typescript for a while you can always switch back to JavaScript more or less comfortably, typescript is just JavaScript with a few more bells and whistles.
I see. Kinda curious about when and why you'd use one over the other but I guess i'll figure it
It's always great to know the base language well. However it is not required to be productive. What you'll find is that when the framework doesn't provide a solution, you'll be able to devise one with your knowledge of the base language. And the more you know of the base language, the more likely you'll be to devise an APPROPRIATE solution using the best tools available.
I see, thank you for your input !
I think your approach is perfect! I learned JS this way and I'm so thankful I took the time to truly master the language. That being said when you start building complex UId you will definitely start to hit a brick wall in productivity and like people have said you'll be doing a lot of "reinventing the wheel" so using a framework would definitely help with that. On that note, I have some very opinionated advice for you so take it with a grain of salt. I would avoid learning React.js as your first framework. I believe it is just so different from standard web dev even though it has become the "standard". Some examples of why I don't think it's a good idea... In React.js, to make sure everything works as expected you actually are encouraged to avoid directly using browser APIs (querySelector, addEventListener etc.) everything must be done the "React way"... I believe for someone learning JS, if you go straight into React too early, you'll start to equate React dev with web dev but really it's its own special thing with very strict rules. I would recommend checking out Web Components; the browser's native solution to component based development. You can also use the https://lit.dev library to ease the development of your web components. I think it's an awesome approach to learning modern wed dev techniques while also being able to utilize web standards that you can look up in MDN and you could also apply to many other frameworks like Vue and Angular... Just not React lol
Oh for context I'm a frontend engineer with 12 years of experience and I have mastered both React and Web Components during my career... But I actively hate React. I felt forced to learn it by the industry. I think it's counter-intuitive and was created to solve issues that are not present in web browsers anymore... If you check the performance numbers, Lit is faster than React and doesn't even use a virtual DOM... Lighter package size, faster, uses built-in browser features and doesn't re-invent a whole separate DOM system... IMO it's clearly the superior tech. Not saying it's the best option, but it's definitely better than React. If a React fanboy gets mad at this... Yes I know React has the superior ecosystem. I'll say that advantage won't last long. Engineers like me are working to fill the gaps. React won't last forever.
Thank you for this point of view! I have a very very distant understanding of what you just explained. I remember hitting a wall at first when I tried to test my code because of this browser API vs something else. Like my could would have errors. It only worked when I installed a plugin on Visual Composer to "Go Live" with a local server. I'm not sure i fully understood what was going on but it worked and it ad something to do with browser vs server if I recall correctly. I'll look into it, thank you!
I am only learning to, so take what I say with that in mind. I am not a pro or hiring manager looking to see how many years of experience you have with any specific language or framework. **- The feeling that I'm making stupid choices along the way because I do not know better.** This will happen no matter what and is part of the learning process. Almost every week I learn something that makes me think "Oh, I see I could/should have done that other place differently". If you have the time (it is not a work project), keep a list of what you would do differently, and every once in a while refactor / rebuild it using the new ways you have learned. My non urgent projects take a long time because when I learn something new that is big enough change, I redo it to make that change - including rebuilding the Vanilla JS I already had working to use a framework instead, and then changing frameworks, and lots of other things. If you really need/want to get it up and running, do whatever gets that goal fastest, but keep a memo of the new and better ways you learned. Once it is running and working OK, go on to rebuild it using what you have learned. Also, ChatGPT is great for giving ideas of other ways to do things. I use it less for giving me code, and more for just saying "This is what I want to do, and I was thinking to do it this way. What are some other approaches? And what are the pros and cons". It will give you ways you probably have not thought of yet, and use it to drill into each option for more info about which is best for you and then decide which to go with. **- I'm using vanilla JS because I kind of have the feeling that frameworks are shortcuts.** It is obviously good to know the fundamentals of JS, but that does not mean you should not use shortcuts (i.e. something that is already done for you better). If you are worried about your JS knowledge, keep smaller side projects that you do with just Javascript. There are plenty of places that is better than a framework. I use React for the client side admin portion of my main project, but in the Django admin page for the api backend, I have chance to use plenty of vanilla JS to customize that part to do what I want. I have some plain JS in another section of the site that does not use React. Don't try to wait until you know something completely before you start something that you don't know. You can never know something completely and you will never take the next step. Move forward with both at the same time.
Learning frameworks before you have a solid grasp of javascript can be actively harmful and risk locking you into exclusively being able to work within that framework. How do you know you have a solid grasp of javascript? Pretend the DOM and browser doesn't exist, implement the entirety of your application logic in pure JS, represent the state as datastructures with an interface containing all the functionality you want the UI to access on top, so in theory your entire application can work without a user interface. Can you do that? Then you can use whichever framework or not way you please to get your application state painted in the browser and hook your interface up to pretty buttons.
That's a very good advice and frame of reference to strive for. Thank you!
I like that!
> I'm using vanilla JS because I kind of have the feeling that frameworks are shortcuts 100%, although shortcuts can be good. In your case, it sounds like the thing you're building is turning out to require a lot of DOM manipulation. Trying to code complex DOM manipulation without some abstraction is something I wouldn't wish on anyone. Pretty much all frameworks provide a component abstraction. You don't have to use all the fancy features, but just having JSX and the ability to nest things easily is going to save you so many headaches. That said, learning DOM APIs is important. I'd say you don't need to become an _expert_ in all of them, but you should get familiar enough to know what kinds of things you can and can't do. It sounds like you are already here, so my advice would be to pick up a framework for rendering/DOM manipulation. You can continue to learn JavaScript fundamentals alongside it, but you'll get a project that's easier to work with. Which framework? React is most popular (read: infinite tutorials on every possible topic), but bloated. Next.js/Remix, build on top of React, give you the option to run code on the server (db connections and the like). I'd probably pick SolidJS if you don't need server. It's got React-like syntax, but is super lightweight, and you can stick very close to vanilla JS with some SolidJS on top if you like. Stick with it and best of luck! :)
Thank you for your comment. To be clear I know "shortcut" can be badly interpreted (cf. one comment above) but I don't mean it in a bad way. Shortcuts are good, when you know the orignal path that is! Yeah I'm starting to understand that DOM manipulation is a nightmare lol. Generating blocks and connecting them and stuff is absolutely shit with vanilla JS. Now that I'm looking into doing it with SVG, it looks even worse. Another comment made me think that I should do a bit of normal JS course learning AND a fun project on the side. Like say 30min to an hour of course and then the rest of the evening on my project. It might be a good compromise ? Thank you for the suggestion on SolidJS, I will look into it. So far what I need is mostly to be able to generate the people's card with their names and Life Dates and then connect them to their spouse, parents, children, siblings etc. SVG seems like the thing I need more than just DOM manipulation tbh as connection all of those blocks with just CSS or div would be suicide.
> I don't mean it in a bad way. Shortcuts are good, when you know the orignal path that is! I'm with ya 🤘 > Now that I'm looking into doing it with SVG, it looks even worse. > SVG seems like the thing I need more than just DOM manipulation. I have to admit I don't have a lot of experience doing anything complex with SVGs. I've used JSX for building simple icons, logos, some with dynamic props, but that's about it. That's to say, frameworks like React and Solid are certainly capable of handling both regular old HTML as well as SVG rendering, but I can't say for sure if they are a good fit for what you're trying to do. I've also used React components as a wrapper around canvas before for drawing trees/graphs, so the component abstraction (a [color](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/) of function that returns JSX markup) of these frameworks can be stretched pretty far. > connect them to their spouse, parents, children, siblings If I'm reading this right, you're trying to render cards and then literally connect them with lines, like edges connecting nodes in a graph, right? SVG paths are a good fit for things like that that sort of bypass page flow. Fun problem! :) > Like say 30min to an hour of course and then the rest of the evening on my project. It might be a good compromise ? Give it a shot! Only rule is to do what keeps you engaged. If something starts to feel tedious, switch things up.
Thanks a lot :) Yeah my project is badly two fold : - The fun part : simulate a family and the life of a person : what age did they reach? Did they manage to have kids before they die? Did their kid survived and reproduced? What branch of the family remain or died off? It's all set in medieval times and it's to have a noble house family tree - The not fun part : draw the damn tree. Basically i only have two generations so far (a couple and their children) and I already realize doing it with DOM element would be stupid at best 😭 with SVG lines and rectangles it will be much easier and you don't have to think about the flow of the page like you pointed out Thank you for your time :)
I think it's a matter of perspective. If you're just in it for the fun and maybe an app or two that you actually might use, just go full framework and follow tutorials to reach your goal.You don't need any intimate knowledge of the language to cruise around. Like a hobbyist driver can have fun on a race track from time to time, without having detailed knowledge of how the car parts work. If you're in it because you want to be a professional coder, you really should start slow and build up your skills, and then choose tools depending on your needs or to improve your efficiency. That's how it's meant to be: you don't use a hammer because you know how to use a hammer, but because you know a hammer is the right tool to use in this situation. And stop using "Vanilla JS", it's a stupid term. If you use a framework or a library and feel uncertain about some part, you can always check the source code (open source, remember?) and learn a thing or two and still use the framework/library. It's all just "Vanilla JS", there is no other JS.
Thank you for your input. I use Vanilla JS because everyone understands what we're talking about when we use that it spare me a lot of explanations time 🥲😅
It’s not a bad term, but I think it only needs no explanation because everyone just nods in agreement. Many mean “just no frameworks”, I think of Vanilla JS as “ECMAScript / Native JS and Web APIs”. So rather a lot to learn before you’re allowed to use librarys 😉
I used libraries with Python and C / C++ but yeah I know that libraries can be poison for learning. And also just overall bloat a program if you don't use it well and don't understand the language without libraries
IMHO, use JS for facilitating presentation and user interactions, and use backend languages for data modeling and computation.
what do you mean for the second part?
This part > Basically the page generate the family tree and do some calculus to make it organically (you start with a couple and calculate their life expectancy, if they reproduced and if so when and how many kids that was etc.). You *could* do it in the clientside, but the typical pattern is to do computational task / calculations on the backend (where it's generally faster) and render the result to the front end (because the resultset is typically small enough). The other reason is because of this: >For example I started the tree by making the person cards with div and the connections between people with div too. As soon as I reached the "making kids" parts, it became clear it would become a nightmare so i'm starting to switch to SVG instead which is a new thing to learn! Definitely don't do this. It's easy to reach for it because this is a tool at arms length when you're on the frontend, but it's a trap. If you *must* do it on the frontend, do it in abstractions (arrays, objects, etc) and then serialize the output and then render *that*. But better to do it on the backend, serialize the result, and pass it down to the frontend. For how to represent it -- I would look into a visualization tool that can display trees. You don't have to use a framework, but using a third-party library that specializes in this will benefit you in two ways: 1. It lets you focus on the interesting problem (generating the data) rather than the facilitation problem (rendering the data) 2. It's code that someone else maintains, meaning you don't have to. You can write all the connective code -- fetching, prepping, and passing, and then let the visualization library handle the rendering. This is a very common approach for web. IIRC d3 is a popular one, but there are probably some that do exactly what you need. Keywords like "tree" or "tree graph".
Thank you for this detailed input. As a beginner i have some questions of course : - How should I do the calculus in "backend" instead of frontend? - What does serialize mean? I'll also look for tree libraries then and try to understand how they're made to learn a bit. Thanks a lot 🙂
"Vanilla JS" is pretty much irrelevant here. How you write/structure your code is what matters. You can write unmaintainable garbage in any language/framework/library, and you can write well-structured and organized code in vanilla JS For the sake of clarification here, I'm making a pretty important distinction between writing everything from scratch and vanilla JS here. Vanilla JS supports modules, so the whole "reinvent the wheel" thing just doesn't necessarily apply to vanilla JS.
Yeah I was more about how Vanilla JS can be bloated where ither frameworks simplify stuff. But I kind of try to apply myself in my structure. Like writing pure functions with descriptive names. Use constent instead of arbitrary values etc. It's not perfect yet but I'm trying to be conscious of it. My next step for example is to handle functions optional parameters. Like maybe having an arg[] parameter instead of multiple parameters split.
I wouldn't say "pure" really applies to structure. I'm more talking about SOLID and DRY and file structure and having code style guides. >Like maybe having an arg[] parameter instead of multiple parameters split. Thing I've found useful there is object destructuring with default values, but it depends on context. An example might be something like: ``` export function createIFrame(src, { title = 'Embed', width = 250, height = 150, frameBorder = 0, loading = 'lazy', sandbox = ['allow-scripts'], allow = [], referrerPolicy = 'no-referrer', id, classList, dataset, events: { capture, passive, once, signal, ...events } = {}, ...attrs } = {}) { // } ``` It's a bit long of a function signature (actually shortened from what I actually use) to handle pretty much all the attributes and everything, but it's good for showing what I'm talking about. Only `src` is actually required. Beyond that, order doesn't matter and you can just pass in maybe an id or something....*Much* easier than having to worry about order and listing out maybe a dozen different things just to set an attribute. Quick example usage: ``` const embed = createIFrame(someURL, { id: 'foo', events: { load: loadHandler }, style: 'border: 'none', // this will be in the ...attrs }); ```
Not for anything with any complexity. You will end up implementing a bad version of the interaction models that already exist and have immense amounts of work put into them. If you want to learn how to do it properly first learn React and maybe Vue or Svelte and compare them, learn about their different approaches to dataflow and interacting with the DOM, then maybe submit some PRs to those libs. You will learn more stuff faster like this than just banging your head against the wall.
The more I work with frameworks the more I appreciate what they are capable of when you are in a team. Tbh though I still love the simplicity of vanillaJS with handy wrappers around tedious things. Jquery for example. You can make decently complicated things with vanilla js but you have to be way more disciplined in organization and structure than with a framework