Should I also abandon other frameworks, as Materializecss, PureCSS and Tailwind?
Absolutely. Front-end frameworks are universally bloated inept trash that makes you write twice or more the HTML necessary to do the job by slopping endless pointless classes at things that don't need classes, presentational classes defeating the entire reason certain tags and attributes were deprecated two decades ago, and actively encourage NOT using HTML properly. (Aka that sick euphemism "semantic markup")
They make wild claims -- glittering generalities as it were -- about being "simpler" or "easier" or "makes you more productive" when that's 100% grade A bunko. They then card stack examples with some of the most poorly written HTML possible to perpetuate their LIES.
How starting out with two times or more the CSS (or scripting) than an entire web page has any right to have in total code (HTML+CSS+JS) before you even write a single line of your own code and content, to then write two to ten times the total markup than you need, with often as much CSS as you'd have WITHOUT the framework if you customize the appearance to be anything more than a sleazy cookie-cutter, whilst adding more stuff on top you have to learn is somehow magically "easier" I'll never understand.
HTML/CSS frameworks are universally inept incompetent half-witted idiotic GARBAGE. Not one of them is worth a flying purple fish. There's a reason I call the big one "bootcrap"; and frequently tell people to go find a stick to scrape it off with before tracking it all over their website's carpets.
The screwed up part being bootcrap is one of the BETTER ones -- you want to see the pinnacle of developer ineptitude in action dragging practices back to the worst of the mid 1990's, check out W3Fools mouth-breathingly dumbass "w3.css" -- only further proving those sleazy dirtbags using a name similar to W3C to dupe beginners who don't know any better are unqualified to even have a website about web development! You get into doing crap like class="w3-red w3-border w3-center" you might as well go back to using the HTML 3.2 without CSS using those presentational tags and attributes that they clearly miss so much!
JavaScript frameworks are typically no better as once they grow 'big enough' to be a 'framework' instead of a 'library' they instantly seem to break good practices, and fill websites with useless slow nonsense... as it seems you're fully aware given what you said about issues with scripting. It's actually quite refreshing to come across someone who actually understands the issues I'm always talking about with how not everyone can afford the latest high-tech to support these overweight "JS for nothing" solutions. Not everybody is running around with a 4ghz threadripper and 32 gigs of RAM.
As I've said hundreds of times the past decade plus, the only things I've ever seen done with jQuery fall squarely into one of three categories:
Stuff that would be simpler and less code without the framework.
Stuff that's HTML or CSS' job.
Stuff that has ZERO damned business on a website in the first place.
What about Laravel, Textpattern and Wordpress?
Server-side frameworks are a mixed bag. On the whole to me at least the better ones (Laravel for example) feel like outdated relics. Since PHP 5.x introduced PDO the notion of needing a 'framework' for simple tasks simply reeks of failing to keep one's skill set up to date. Whilst in their case YES they do often let you speed up development and appear to be easier, they often leave the people using them flat footed on deployment.
This is a common issue with frameworks across the board as people dive for them before they know enough of the underlying language to:
Know if the framework is actually any good
Fix things when they go wrong.
Others... well, like turdpress for example. SIGH the "out of the box" template is a laundry list of how NOT to write HTML, how NOT to use classes, how NOT to use CSS, how NOT to include style or scripting, and as such most every off the shelf template for them are equally poorly made.
That above example I used from bootcrap? There's a turdpress equivalent. (283 bytes)
<div class="menu-bar">
<ul class="menu">
<div class="menu-main-container"><ul id="menu-main" class="menu"><li id="menu-item-191" class="menu-item menu-item-type-post_type menu-item-object-page current-menu-item page_item page-item-189 current_page_item menu-item-191">
Which in 99% of cases is doing the job of: (43 bytes)
<ul id="mainMenu">
<li class="current">
... and that's before we talk about it slopping static style into the markup, endless pointless separate JavaScript's for f* knows what, resulting in pages that unless you're on that magical combination of system, browser, and high speed connection can result in page loads measured in minutes, not seconds.
And that's BEFORE we talk about the security woes under the hood with the "insecure by design" practices of endless separate entry vectors and 100% grade A derpitude like putting the SQL login information into DEFINE and not restricting the scope of the connection. Means that ANY code elevation ANYWHERE has the keys to the kingdom. They didn't even TRY to isolate anything.
However turdpress IS easy for people who know nothing about websites to set up and use; unfortunately that's ALL that can be said good about it and its kine. This makes it cute for making a blog for grandma but anyone suggesting you use it for a business is a sleazy dirtbag scam artist saddling you up to take you for a ride. Universally it is bloated, slow, has accessibility woes out the yazoo, double that for security risks, a general lack of even attempting to use HTML properly,etc, etc... "For people who know nothing about websites BY people who know nothing about websites" is not a recipe for success.
It's free and it's "easy" -- the problem is the result is EXACTLY what you should expect from free and easy.If you're doing it for WORK, there's a reason it's called WORK and not "Happy Happy Fun-time!"
You take the sleazy "easy" shortcut don't be shocked when the result is incompetent bloated slow loading trash!
I think much of it comes from the death of "code size targets". There was a time where every developer worth a damn knew in general how big the code should be before they even start writing a single line of it. For example as a rule of thumb when it comes to a HTML template there is really little reason for a page to exceed this calculation:
2048 + plaintext 1.5 + number of CONTENT media elements 256 + number of form elements 128 + anchors 128
CONTENT media elements are things like images and videos that are not part of the template. If they're part of the template they have NO business in your HTML. That's CSS' job.
If your HTML exceeds that calculation in size, it's a bloated train wreck of how NOT to write a website. THIS is why I cringe when I see turdpress+bootcrap combined together to sleaze out 100k of HTML to deliver 4k of plaintext and not even a dozen content images and two dozen links -- 12k of HTML's freaking job!
Same for the style where you'll see all these slopped together train wrecks using 20k of <style> in the markup (where it has ZERO blasted business), and 200 to 500k of external stylesheets spanning dozens of separate files doing the JOB of 48k or less in ONE file.
Or the JavaScript where you'll see MEGABYTES of garbage BEFORE we even talk about social media plugins (themselves a bit of a mess) on websites that often do not warrant the presence of 48k or less in scripting for the template in one or two files.
You'll notice I mention the number of files -- that too is important for speed and the number one place people cock up!
When serving a website a browser (typically) can only make eight connections at one time to transfer separate files in parallel. Each file past that first eight has a significant overhead to it. This is called "handshaking" as the browser says "do you have the file", the server says "yes I have the file here's the date info", the browser replies "ok, I don't have that cached, send it to me", server replies "ok, here it comes" and THEN the actual block packets start.
But because they are served in parallel that overhead is reduced somewhat. In THEORY the overhead is basically the 'ping time' to the server times five, but in practice due to the simultaneous nature we 'ballpark' the transfer of each file past the first eight as 200ms under ideal conditions and a full second or more for worst-case.
As such a page built from 24 separate files will pay an extra 3.2 seconds on average -- (24 - 8) * 0.2 -- for a cache-empty first-load in "handshaking" under ideal conditions. Under crappy connection conditions suddenly that's 16 seconds of overhead! This is why pages built from 100 separate files can take over a minute to load.
This handshaking overhead can be further exacerbated by the connection limit on EITHER end being starved out. You can only have so many connections through a computer, or a router, or a switch along the route at once, so if other people or other services and so forth are using it as well, it can increase that overhead many-fold. Be it at home with wifey watching netflix and pooky torre... creatively acquiring movies and games, or if you're leeching off a public connection at the local coffee house that two dozen other people are trying to use, or on the hosting where high levels of traffic are flat out choking things out.
Which is why techniques to reduce the number of separate files are so popular -- the incorrectly named CSS sprites, transferring icons inside fonts, and of course the simple practice of combining down as many of your scripts and stylesheets into single files as you can get away with.
Which is why as a rule of thumb my base template NEVER has more than one stylesheet per media target, two separate scripts, and eight template images -- the code COMBINED not being allowed to exceed 72k (again not counting content) and the images combined not being allowed to exceed 64k.
Again not counting social media plugins, things like disqus, or the CONTENT.
If you start practicing code targets your speed and efficiency improves many-fold. There is simply no reason for the MASSIVE train wrecks people vomit up using front-end frameworks and outdated practice apart from outright ineptitude either on their part, or on the part of those they are learning from.
It sounds like you're having speed issues, those frameworks are a very likely cause.
to repeat the codes, for example, repeating nav and footer parts in every new page created
That's what PHP is for. You don't have to compromise your HTML, CSS, or client-side scripting quality to do that. NOR should you 'need' any framework given the relative simplicity of such a task. PHP was CREATED to be glue... adhesive between markup and database, cement betwixt template and content, and a traffic cop for the flow of information.
I'm just often surprised how ridiculously convoluted and overthought the solutions many alleged "experts" come up with in using it -- and that people then just blindly copypasta.