4 ms·

I build the frontend of all my projects with plain HTML/CSS/JS. Every time I talk to developers who use frontend frameworks, I challenge them and say: Let's si

by TekMol 4y ago

I build the frontend of all my projects with plain HTML/CSS/JS. Every time I talk to developers who use frontend frameworks, I challenge them and say: Let's sit down and build the same application. You build it with React or whatever, I build it with plain JS. Let's see which one is leaner and more logical. Every time the answer is the same: The benefit of a frontend framework will not become visible in a small app. Only in a big app. Then I ask: Ok, where is the cut off? What is the smallest app, where React will shine? And I never get an answer. When I see React examples like this calculator ... https://github.com/ahfarmer/calculator https://github.com/ahfarmer/calculator ... which use 70 files (without dependencies!) to build something one could do in a single HTML file, I am afraid that those "big" apps the React proponents talk about will be very big when implemented with React.

confidantlake 4y ago
Can you build Microsoft word or google maps or any of the 100s of other moderately complex web apps without a framework?
- PaulDavisThe1st 4y ago
  parent has already essentially admitted that the answer is no. they asked "where is the cut-off?"
- busymom0 4y ago
  Obviously not Microsoft word but I built my resume builder using vanilla JS, html and css: https://resumetopdf.com/ https://resumetopdf.com/
  - frumper 4y ago
    That's a nice looking project
- wiredearp 4y ago
  The top complex component in Word is the text editor while the tricky component in Maps is the map. Neither of those can be made with the frameworks we're dealing with here, so that is a go. We can make the traditional UI with a simple view library like lit-html [1] and we'll want to keep some state around, but most state managers can be rigged to Vanilla. I'd totally prefer Web Components to any popular framework for the particular apps you suggest. [1] https://lit.dev/docs/libraries/standalone-templates/ https://lit.dev/docs/libraries/standalone-templates/
- pier25 4y ago
  Yes it's possible, the problem is dev time. Of course some sort of framework will naturally occur as a project grows.
- Existenceblinks 4y ago
  Funny thing is the two should be built with vanilla js and canvas. No popular framework is going to do better.
  - potatoz2 4y ago
    The inaccessible to non-sighted users, non-computer interpretable canvas? The one where we’d need to reinvent text flowing, resizability, the box model, etc? That’s what you think we should use to build our Web apps?
    - Existenceblinks 4y ago
      Yes, in order to be best it needs to re-invent those wheels. Otherwise, vanilla js with DOM nodes is in the same league as ReactDOM.
Jabbles 4y ago
Another way to ask the question is how small are your projects? How many engineering-years do you put in each of them? If the cutoff is something like 10 years, what would your response be?
- ozim 4y ago
  Parent poster is aiming at calculator app as "something people do in react and should be complex" - calculator app is still graduate level thing of limited scope and quite well defined. I assume he have not seen any project that grows for 5+ years has 20 dev working on it (20 because of team rotation maybe 3-5 working at the same time).
naet 4y ago
I use both frameworks and non frameworks on different sites, some extremely large and some small. You can shoot yourself in the foot with either and I wouldn't make a blanket statement that one way is better than the other. I don't like the trend of using React to build a brochure level website with near zero ui interactions or api calls, it usually ends up bloated and a pain to try to split code, reduce bundle size, etc. for no real gains. On the other hand, when I work on a complex stock brokerage dashboard with tons of data, tons of fancy ui that needs frequent updating, and a massive internal state with tons of user data and stock data (also being frequently updated), React is a pretty good choice. One of my other sites is a legacy property with all UI powered by a single 6000 line jQuery and javascript file. It's very easy to break something without realizing trying to make changes there, so people keep adding new stuff at the bottom to minimize potential breaking changes. Definitely not the ideal vanilla JS setup but it isn't a good fit for the organization's needs. At the end of the day, react is javascript and you can make any react site with plain javascript... but it is sometimes a useful abstraction for highly complex environments with many people working on them.
ozim 4y ago
*Imagine that the biggest body of water you’ve ever seen is a dinky little pond and you think, “Yep, that’s about as much water as there can be! There’s nothing deeper or wider than this. Seeing water that stretches onward to the horizon, water that can turn into tidal waves, water that hides giant whales and creatures that have never seen the sun, that’s just a bunch of tall tales.” And maybe you can be happy sitting next to your pond, so long as you never see an ocean. Maybe when you meet people who tell you about the magnificent oceans they’ve seen, you figure they’re just exaggerating what it’s like to see a pond. “Ah yes, I remember seeing my first pond,” you chuckle. But somewhere deep in your brain, there’s a little twinge of doubt.*
ffhhj 4y ago
In my day job I work with frameworks, and do vanilla development for all of my personal projects. But then I realize that in the end I'm just building my own frameworks (DB, states, UI), that I might use or fragment and reuse in other projects, because it all becomes boilerplate, and the top level logic is what's different and actually matters.
pier25 4y ago
> Let's see which one is leaner and more logical. Leaner, yeah, I'm certain a vanilla app will produce less KBs. What about dev time? I've been writing JS since the late 90s and I'd never use vanilla for anything other than trivial projects, quick tests, etc. More logical, that is 100% subjective. > Ok, where is the cut off? What is the smallest app, where React will shine? And I never get an answer. Of course you won't. It's an impossible question. Could you say with certainty at which point it's better to use or not use a framework? (any framework with any language) You can't. Once you're deep into the swamp you may realize you should have used a framework... but it's often not obvious a priori. > which use 70 files (without dependencies!) Honestly that's kinda ridiculous. You could build a calculator with a single file and a couple of components. This is not a problem with using React or any other of the modern libs but with that particular programmer.
- culi 4y ago
  > Honestly that's kinda ridiculous. You could build a calculator with a single file and a couple of components. This is not a problem with using React or any other of the modern libs but with that particular programmer. Yeah I'm trying to figure out how someone could possibly reach this number of files if you're not counting dependencies... If I make the app with the explicit goal of having as many files as possible I can think of: ~6 config files and dotfiles. Maybe make it TypeScript so we have a tsconfig.json as well and maybe we'll have a README and LICENSE as well for good measure In our public folder we'll have the index.html, a _redirects, robots.txt, a favicon, logos of different sizes, a manifest just in case, a sitemap because why not. Maybe a dozen files in total? But for the actual source files? index.tsx and App.tsx (I usually make these two the same file). Maybe we're keeping our jsx and css in different files so let's just double the number of components by 2. I'm struggling to think of why this might have to be more than one component but let's just say it's 2. So 4 files in total. Let's even say there's a custom hook for some reason so that gives us another file. That's like 7 files for the source code if we really stretch things out. Maybe you're one of those people that likes to have separate files for your routing or maybe you have some Layout.tsx business going on. Still can't imagine it stretching passed 10 files. I'm up to 28 with a ton of rounding up...
potatoz2 4y ago
The benefit of React is that it’s declarative. Vanilla JS is imperative/procedural. If you build anything semi-complicated, you’ll build your own declarative framework.

by TekMol 4y ago

confidantlake 4y ago

Can you build Microsoft word or google maps or any of the 100s of other moderately complex web apps without a framework?

PaulDavisThe1st 4y ago
parent has already essentially admitted that the answer is no. they asked "where is the cut-off?"
busymom0 4y ago
Obviously not Microsoft word but I built my resume builder using vanilla JS, html and css: https://resumetopdf.com/ https://resumetopdf.com/
- frumper 4y ago
  That's a nice looking project
wiredearp 4y ago
The top complex component in Word is the text editor while the tricky component in Maps is the map. Neither of those can be made with the frameworks we're dealing with here, so that is a go. We can make the traditional UI with a simple view library like lit-html [1] and we'll want to keep some state around, but most state managers can be rigged to Vanilla. I'd totally prefer Web Components to any popular framework for the particular apps you suggest. [1] https://lit.dev/docs/libraries/standalone-templates/ https://lit.dev/docs/libraries/standalone-templates/
pier25 4y ago
Yes it's possible, the problem is dev time. Of course some sort of framework will naturally occur as a project grows.
Existenceblinks 4y ago
Funny thing is the two should be built with vanilla js and canvas. No popular framework is going to do better.
- potatoz2 4y ago
  The inaccessible to non-sighted users, non-computer interpretable canvas? The one where we’d need to reinvent text flowing, resizability, the box model, etc? That’s what you think we should use to build our Web apps?
  - Existenceblinks 4y ago
    Yes, in order to be best it needs to re-invent those wheels. Otherwise, vanilla js with DOM nodes is in the same league as ReactDOM.

Jabbles 4y ago

Another way to ask the question is how small are your projects? How many engineering-years do you put in each of them? If the cutoff is something like 10 years, what would your response be?

ozim 4y ago
Parent poster is aiming at calculator app as "something people do in react and should be complex" - calculator app is still graduate level thing of limited scope and quite well defined. I assume he have not seen any project that grows for 5+ years has 20 dev working on it (20 because of team rotation maybe 3-5 working at the same time).

naet 4y ago

I use both frameworks and non frameworks on different sites, some extremely large and some small. You can shoot yourself in the foot with either and I wouldn't make a blanket statement that one way is better than the other. I don't like the trend of using React to build a brochure level website with near zero ui interactions or api calls, it usually ends up bloated and a pain to try to split code, reduce bundle size, etc. for no real gains. On the other hand, when I work on a complex stock brokerage dashboard with tons of data, tons of fancy ui that needs frequent updating, and a massive internal state with tons of user data and stock data (also being frequently updated), React is a pretty good choice. One of my other sites is a legacy property with all UI powered by a single 6000 line jQuery and javascript file. It's very easy to break something without realizing trying to make changes there, so people keep adding new stuff at the bottom to minimize potential breaking changes. Definitely not the ideal vanilla JS setup but it isn't a good fit for the organization's needs. At the end of the day, react is javascript and you can make any react site with plain javascript... but it is sometimes a useful abstraction for highly complex environments with many people working on them.

ozim 4y ago

*Imagine that the biggest body of water you’ve ever seen is a dinky little pond and you think, “Yep, that’s about as much water as there can be! There’s nothing deeper or wider than this. Seeing water that stretches onward to the horizon, water that can turn into tidal waves, water that hides giant whales and creatures that have never seen the sun, that’s just a bunch of tall tales.” And maybe you can be happy sitting next to your pond, so long as you never see an ocean. Maybe when you meet people who tell you about the magnificent oceans they’ve seen, you figure they’re just exaggerating what it’s like to see a pond. “Ah yes, I remember seeing my first pond,” you chuckle. But somewhere deep in your brain, there’s a little twinge of doubt.*

ffhhj 4y ago

In my day job I work with frameworks, and do vanilla development for all of my personal projects. But then I realize that in the end I'm just building my own frameworks (DB, states, UI), that I might use or fragment and reuse in other projects, because it all becomes boilerplate, and the top level logic is what's different and actually matters.

pier25 4y ago

> Let's see which one is leaner and more logical. Leaner, yeah, I'm certain a vanilla app will produce less KBs. What about dev time? I've been writing JS since the late 90s and I'd never use vanilla for anything other than trivial projects, quick tests, etc. More logical, that is 100% subjective. > Ok, where is the cut off? What is the smallest app, where React will shine? And I never get an answer. Of course you won't. It's an impossible question. Could you say with certainty at which point it's better to use or not use a framework? (any framework with any language) You can't. Once you're deep into the swamp you may realize you should have used a framework... but it's often not obvious a priori. > which use 70 files (without dependencies!) Honestly that's kinda ridiculous. You could build a calculator with a single file and a couple of components. This is not a problem with using React or any other of the modern libs but with that particular programmer.

culi 4y ago
> Honestly that's kinda ridiculous. You could build a calculator with a single file and a couple of components. This is not a problem with using React or any other of the modern libs but with that particular programmer. Yeah I'm trying to figure out how someone could possibly reach this number of files if you're not counting dependencies... If I make the app with the explicit goal of having as many files as possible I can think of: ~6 config files and dotfiles. Maybe make it TypeScript so we have a tsconfig.json as well and maybe we'll have a README and LICENSE as well for good measure In our public folder we'll have the index.html, a _redirects, robots.txt, a favicon, logos of different sizes, a manifest just in case, a sitemap because why not. Maybe a dozen files in total? But for the actual source files? index.tsx and App.tsx (I usually make these two the same file). Maybe we're keeping our jsx and css in different files so let's just double the number of components by 2. I'm struggling to think of why this might have to be more than one component but let's just say it's 2. So 4 files in total. Let's even say there's a custom hook for some reason so that gives us another file. That's like 7 files for the source code if we really stretch things out. Maybe you're one of those people that likes to have separate files for your routing or maybe you have some Layout.tsx business going on. Still can't imagine it stretching passed 10 files. I'm up to 28 with a ton of rounding up...

potatoz2 4y ago

The benefit of React is that it’s declarative. Vanilla JS is imperative/procedural. If you build anything semi-complicated, you’ll build your own declarative framework.