There is an opportunity to rewrite my company's front-end which is currently using AngularJS.
There are a lot of choices we can make with regards to front-end frameworks, and I was wondering: for people who have evaluated front-end frameworks before, how exactly did you go about it? What did you consider? How did you come up with the advantages/disadvantages, and compare them to other frameworks? etc.
When I was developing a side-project recently called Kushy, I had to tackle this issue. Deciding what server-based language and framework we'd use, as well as the front-end.
I defined what features the Kushy application would have. Then I would research the various options to implement the feature, and see their pros and cons -- particularly at scale. I also researched competitors and what technology they used to solve the problem and why (like Twitter sticking to SQL). Then I launched small-scale experiments using some of the options and testing them out practically (because theory is one thing, diving deeper into docs to find they're garbage is another thing).
Based on my experience with the small-scale experiments, and the research I'd accrued, I'd make a decision.
To give you an example:
We needed a huge database of information, most of it was location based, and much of it was relational. We also needed accurate data, since we'd be dealing with e-commerce and even compliance with local and state governments. This kind of scope led me away from solutions like NoSQL, since they're less accurate and less efficient with relations than a strictly defined SQL database. Although NoSQL may do processes like geolocation more efficiently than SQL, the fact that I might lose any portion of data was unacceptable.
We also needed an API and a frontend for users. I explored using NodeJS as the basis, and frameworks like Express and Passport. Comparing this to how fully-featured Laravel, I ended up going with Laravel instead of Node. It allowed me to more quickly develop what I needed without having to string together my own framework out of several JS libraries (and hope I don't have swiss cheese in my security). I developed a sample API in NodeJS/Express and another in Laravel and quickly fell entranced by the simplicity of the Laravel facades.
I have a whole case study on the project I have to get around to releasing. It details a lot of the decision making behind the stack. But I hope this helps!
Jason Knight
The less code you use, the less there is to break
I have UNIVERSALLY found them ALL to be utter and complete incompetent trash. They appear to be put together for people who know not a blasted thing about HTML, CSS, and JavaScript, BY people who know not a blasted thing about HTML, CSS, and JavaScript!!!
I come to this conclusion based on certain HTML and CSS "good practices" that are UTTERLY AND COMPLETELY MISSING in these dumbass ignorant half-witted frameworks.
1) Do they apply classes in a presentational manner, saying what things look like instead of what they ARE?
The moment you see a class like "w3-red", "text-center" or "xm-s-12" you have COMPLETELY defeated the separation of presentation from content that is the ENTIRE huffing reason HTML and CSS are SEPARATE in the first damned place. It also COMPLETELY undoes some two decades of progress and EVERYTHING HTML 4 Strict was attempting to drive us towards.
If you are going to use classes that way, you might as well go back to writing HTML 3.2 with those FONT, CENTER, ALIGN, BGCOLOR attributes and tables for layout that are clearly so sorely missed by the mouth-breathers!
2) Is it using JavaScript to do CSS or HTML's job?
Classic example of this is hamburger menus and modal dialogs NEITHER of which require JavaScript to work perfectly in IE9/later, and can be coded to gracefully degrade in a useful fashion on older browsers when/if needed. naturally you don't care about hamburger menus on legacy IE for obvious reasons, what mobile devices do you care about running IE8/earlier?.
3) Does it provide proper graceful degradation CSS off / JavaScript off/blocked?
The entire POINT of HTML -- at least for websites -- is to deliver usable content to EVERYONE, not just the perfectly sighted users using screen media user-agents. Screen readers, braille readers, these are all valid targets you should be coding for -- which is why as much as possible in your HTML should be saying that things ARE, NOT what they look like.
As the saying goes:
Remember, search engines don't have eyeballs!
Just like:
... at least when it comes to client side delivery of content and core functionality. It's ok to ENHANCE the page with JavaScript on things like comments or fancy do-dads, but if something essential like a contact form or delivery of important information (like say, bank balances, shopping carts) doesn't work scripting or CSS off, you have failed in your job as a web developer.
Which is why CSR methodology is halfwitted bull for CONTENT!
4) Do the examples clearly show a lack of even the most basic understanding of HTML?
w3.css and bootcrap are both prime examples of this. As I'm always saying if you don't know what's wrong with this: (lifted straight from bootcrap's "pricing" example)
<body> <div class="d-flex flex-column flex-md-row align-items-center p-3 px-md-4 mb-3 bg-white border-bottom box-shadow"> <h5 class="my-0 mr-md-auto font-weight-normal">Company name</h5> <nav class="my-2 my-md-0 mr-md-3"> <a class="p-2 text-dark" href="#">Features</a> <a class="p-2 text-dark" href="#">Enterprise</a> <a class="p-2 text-dark" href="#">Support</a> <a class="p-2 text-dark" href="#">Pricing</a> </nav> <a class="btn btn-outline-primary" href="#">Sign up</a> </div> <div class="pricing-header px-3 py-3 pt-md-5 pb-md-4 mx-auto text-center"> <h1 class="display-4">Pricing</h1>... do the world a favor, back the hell away from the keyboard, and go take up something a bit less detail oriented like macramé!
If you don't know what's wrong with that, endless pointless classes for nothing, presentational classes, and utter complete gibberish semantics since how can you have a H5 without a H4 for it to mark the beginning of a subsection of? NAV does NOT preclude the use of lists for menus so that set of menu anchors is a gibberish run-on sentence to screen and braille readers... if every child inside a parent container is getting the same class, NONE of them need classes... and of course I'm pretty sure that 'Pricing' is not THE heading that everything on every page of the site is a subsection of, aka what an H1 semantically MEANS if you aren't using HTML 5's idiotic pointlessly redundant SECTION tag!
There is ZERO legitimate reason for that to vary significantly from:
<body> <div id="top"> <h1>Company name</h1> <ul id="mainMenu"> <li><a href="#">Features</a></li> <li><a href="#">Enterprise</a></li> <li><a href="#">Support</a></li> <li><a href="#">Pricing</a></li> </ul> </div> <div id="content"> <h2>Pricing</h2>Apart from the incompetence, ignorance, and ineptitude of the people who use, work with, or created bootcrap.
Even just something as simple as these viewport META where the developers screw around telling users "no you can't zoom" or not using media targets on their stylesheet LINK tags shows a failure to even divine HTML's bloody purpose! That should be a instant warning sign that NO, don't use this garbage!
There's a reason I tell people mindlessly singing bootcrap's praises to go find a stick to scrape it off with before tracking it all over the web's carpets.
... and that's really the problem, ALL of the above reduce front end frameworks to flipping the bird at usability, accessibility, and efficiency. It debunks ALL of the nonsensical propaganda like claims about how they are all somehow magically "easier", "simpler", or "makes you more productive" since they make MORE work, not less. At best all they do is shuffle 'bloat' out of the CSS and into the markup -- at worst they make you start out with more code than you should have in total before you even do anything only to have you write as much if not MORE code than you would have if you just used HTML and CSS properly.
But then as a rule of thumb there is ZERO legitimate reason for a normal site template (not counting things like social media plugins) REGARDLESS of how fancy its appearance to have more than 48k of CSS in one file per media target, 96k of JavaScript in one or two files, and twice the total HTML size of the plaintext.
LEARN to use semantic markup -- a sick euphemism for "using HTML properly" that came into being to not offend the mouth-breathers still vomiting up HTML 3.2 and slapping 4 tranny atop it, and now wrap 5 lip-service around the same outdated and outmoded approach to site building '90's style. LEARN to leverage selectors, semantics, and inheritance in your CSS to reduce the overall code size. LEARN about separation of presentation from content, graceful degradation, accessibility minimums as outlined in the WCAG, caching models, handshaking... and VERY quickly you'll realize just how unbelievably and mind-numbingly DUMBASS ALL of these front-end frameworks are!
... and honestly trash like CSS pre-processors aren't far behind on the halfwit scale. HTML/CSS frameworks are somewhere below creationists on the derpitude meter, with LESS/SASS/SCSS style crap landing somewhere between creationists and Peter Griffin.
The ONLY ways you could see a 'benefit' from using any of these front end frameworks is:
Not knowing enough HTML or CSS to even be choosing a framework
Be doing things that have zero blasted business on a website in the first huffing place.
Have drunk so deeply of the propaganda and scam-artist marketspeak double-talk that trying to show reason and facts ends up like trying to convince a cultist to get out before they start handing out the tainted kool-aid.
I have NEVER seen a single website built with ANY of these frameworks -- be they HTML/CSS like bootcap and w3.css, scripting like jQuery or mootools, or server-client setups like react and vue -- that weren't a train wreck of developer ineptitude and ignorance both in terms of the code, and what that code does to users with accessibility needs.
In fact MOST sites slopped together with frameworks end up being such a useless pile of trash you might as well just use the old goatse.cs page as the body background!