I like frontend when using no frameworks. I also like when websites use no frameworks and don't write unnecessary code. So that I can use it even if my mobile internet speed gets locked at 16K and from the consumer perspective I think especially in Europe developers should consider this. Moreover I think it's generally more fun to just write your own site from scratch, it will take longer but it will allow one to be more creative and the whole experience will be more fulfilling.

Welcome to devRant! Have a ++

@saintograph thank you :)

Welcome!

Not using frameworks will teach you a lot about what and where to use certain things. It’s a great knowledge base to have.

But when you get to a place where time is $$$ (maybe not like a recent rant) and you have deadlines to stick too, frameworks solve a lot of your problems.

Ps: Achievement Unlocked 10++

whhhhaaaaatt? ok for ur hobby/learning yes i encourage this because i love coders who know what they do instad of stackoverflowing functions in libs. but once you get in production gl with that. make whole app using vanilla js. that means handling singletons/events/view change bining /....../..././././. on ur own. Making every component unittestable. Then putting everything togethet and e2e test whole thing. Font mind ur own polyfills to support older browsers.
Ok lets focus static pages instead of apps. Here you have problem with browser support at first hand. so solution is to use base plain js and work with that. then using ur polyfills. then using ur css really carefully alongside creating ur own css framework that will handle viewports and adapting to it. because in this days the nonresponsive pages arent acceptable.
Now when your boss gives you 2/3 weeks to create webpage/app please tell me how you gonna do all from scratch..

@ljiech good point, I haven't worked in production yet.

Fuckin' right man. To paraphrase motherfuckingwebsite.com, loading "3Lbs of jQuery to change the background colour of a div" is stupid.

@lijech not that I disagree with you in anyway, there is no way to roll your own site 100 from scratch in a production environment...Not sure I'd want to if I could either. But from a strictly roll your own js only stand point 90% of the things you mentioned could be handled on the server side (primarily building the views and pages)Then the only js calls needed would be to load the new views from the server and inject them into the site...Plus a few lines here and there that wouldn't need server interaction...Like closing a collapseable div. No real need for a ton of pollyfills ( unless your target is IE 7 and down?). The only thing it couldn't really handle would be responsive CSS which isn't js.... So you could use a lib and that might be better since you could point that to a CDN... Assuming your site isn't serving from a CDN already. Plus idk if a CSS framework from scratch would be all that more smaller or more performance than an existing one.

And as for frameworks on the backend are you sure you do but your input sanitisation correctly etc? So you just invented your own routing-, translation-, ...system. Isn't that nice. I will bet you A. It has been done before and a lot better. B. You wasted a shitload of time reimplementing common things.

Just make sure you get a good components based framework. That way you can choose the parts you need without adding to much bloat.

@pain0486 what i mentioned from js standpoint was the app way. Starting point for what i wrote was that you serve data from a REST service. Because its a standard nowdays because then you can implement same service for nativr apps. And because if its a REST service app you can give the rendering part to the js because requesting jsons and creating views from js reduces the size of responses and automatically makes app lots faster than serving views from server. Idd you can still serve views from server. And for the polyfill part.. there is a lot missing from IE 9 even.. which you cant just skip because lots od state companies have it as a standard on their "high tech" "machines" ( pls detect sarcasm) I dont even think promises are supported out of the box.. or even Object,.. dont know every because i boilerplate template that get rid of this annoyances...

I see your point still mostly the same applies. If you load your framework from a popular CDN you might cut down on some of the loading time. However experience has thought me that controlling bloat on the backend is very important. The more you have the more dependencies you have and have to maintain. Also some resources might not be as liberal as you think. We have some serious listing issues as our redundant storage has extreme HA guarantees but at a cost of performance. The more files it has to plow trough the worse it becomes

@ljiech totally agree. I get where your coming from just wanted to mention that a server could do those things and js wouldn't be required. However from an app standpoint with 1+ clients (native, web .. ect) then yes a restful would be best. We used to do a back end that talked to an API. Introducing a framework js there would have been pointless because the server was doing everything. But then we switched to jwt for security (as opposed to a custom header that gets encrypted on the back end to send to the API) and that allowed us to have just the back end API. Frontend is 100% html and js 😄🙌. As for supporting IE 9.... MS only supports 11 on...If MS won't support it then I sure as hell won't... And that was my argument for my boss that allowed us to say no to IE 10 and down 😀.