4 ms·

Personally, I would never use a framework anymore for the frontend. I did some simple projects in vanillajs and the sheer simplicity of it and being able to und

• onion2k 6y ago
  I wrote an article on my learnings on using vanilla js to create spa. If anyone wants to read it, its here https://dev.to/rishavs/making-a-single-page-app-in-ye-good-o.. https://dev.to/rishavs/making-a-single-page-app-in-ye-good-o.... This is a good example of why a vanilla JS app is much simpler than a framework driven app. Because you've only done the absolute minimum, and it wouldn't work for even a moderately complex real world project. There's no security considerations. There's no state management. There are no tests. There's no performance improvements like memoization or a VDOM. Even simple things like managing constants isn't done well (eg you've hardcoded the API address in to the getPost function). There's no error handling, so if an API call to fetch a post fails nothing will happen except you'll get a JS error in the console to say 'post.id' not found when PostShow tries to expand out the template string. Making a simple app in vanilla JS by ignoring everything that makes a fast, robust app hard to build is easy. That's not what most developers are trying to do when they use a framework though. People reach for frameworks so they can implement the hard things without having to build them from the ground up. No doubt you could implement all of those things, but by the end of it you'd probably have implemented something very similar to React. It's not unreasonable for people who want those things in their apps to just use React in the first place.
  • brabel 6y ago
    > There's no performance improvements like memoization or a VDOM. VDOM is only a performance improvement if you already bought into a specific version of the reactive architecture (namely, the declarative one, pioneered by Elm and popularized by React). Otherwise VDOM is an overhead both in performance and in complexity. Svelte has shown it's possible to do away with that overhead and still keep a nice, declarative API (which is much faster than any VDOM-based solution as it doesn't pay the cost of having a mirror of the DOM in memory + having to run a diff algorithm on every change). Older frameworks also were able to get by with no VDOM by manually binding different parts of the DOM, which can be done well, but admittedly may result in difficult-to-read code.
  • rishav_sharan 6y ago
    Thats quite a collection of nitpicks and I don't think they are all fair; > There's no state management. But there is state management via variables in every view. The state management is about decoupling views and data. in case you want a full featured redux like state manager, i don't even see its point. > There are no tests. Its an article. adding basic api tests is a trivial task. There are no tests as that wasn't what I wanted to show case. > There's no performance improvements like memoization or a VDOM. Using VDOM has no performance improvement unless you need to rerender the entire dom very fast which is where memoization and VDOM are superior. This is a simple event based html/js app. user clicks on something, DOM is rendered. thats it. why the hell would I want to rerender the DOM every time for no use. This is like saying vanillajs is bad because I didn't write my code in typescript and convert to webassembly to drive web components in my html. I did none of those things because they are not needed... > Even simple things like managing constants isn't done well (eg you've hardcoded the API address in to the getPost function). I am not sure what the problem is here... Would it be better if I abstract it to a module where I maintain the map between the api and the function? > There's no error handling, so if an API call to fetch a post fails nothing will happen except you'll get a JS error in the console to say 'post.id' not found when PostShow tries to expand out the template string. yep. its a hook. This is a simple article on how things can be achieved. expecation is that when people can show the error message in the console, they can easily consume it in the html as well, if they so desire. In my other project, where I am using the same error hook, i don't post it to a console but to an notifications div on top of the, page. > No doubt you could implement all of those things, but by the end of it you'd probably have implemented something very similar to React. It's not unreasonable for people who want those things in their apps to just use React in the first place. And my argument is that all of us don't really need all those things so why use the full react/vue ecosystem? just a 100 lines of vanillajs would suffice. Anyway, the point of the article was to show a different way of doing things. i don't expect everyone to agree with it and its fine. each to his own. I personally don't like using frameworks when i can do the same stuff by myself with minimal effort.
• yoz-y 6y ago
  > Like most, I started with React/Vue etc and realized that I was trying to learn a whole language and ecosystem on top of JS and that was why i always found frontends to be so complex. This is intriguing because as someone who started with vanilla JS long time ago I lived through the period when jQuery was seen as the breath of fresh air and React was welcomed as a great alternative to the tangled mess of bespoke code with callbacks all around. One problem that makes deciding what to use is evaluating the size to which a project will grow. For a one pager or a very simple web app a framework (be it front or backend) is often an overkill. But maintaining a large app that does not use one is quite hellish.