There are two questions here. The first question, the subject line, has to do with quality of the code. The second and last question is about employers and what they look for in a candidate.
I think @Travis answers the second question adequately. Employers are certainly looking for a lot of things, including proficiency with the technologies and tools in the business space, but they're also looking for a "fit" within the company. And perhaps even more than that, what they're really looking for is problem solvers. If you lack in a certain language, technology, or framework, but you can show an employer that you have an ability to learn quickly and solve problems, then that's valuable to an employer.
I think employers understand that they're not usually going to get candidates that have every single bullet point on their wish list; but what you're hoping you get is fast learners who are capable and adaptable and can be brought up to speed quickly.
Now, as to the idea of an app being good or bad based on framework usage: here's the bottom line on that one: It depends. Some frameworks are good, and some are bad, and it's only through using them that you will realize how good or bad they are and what barriers they bring or eliminate to a software development project. By the same token, some apps built without frameworks are a mess of spaghetti, but some projects will be just fine. It depends on the people who worked on them.
The larger question, the more concerning question to me, is: Is the app something I can manage and grow and change over time, easily, and with little friction? If the answer to that question is yes, then I don't really care if it used a framework or not.
In my experience, it depends greatly on the language, but some frameworks do a really good job of making apps extensible, easily manageable, and easily changeable as the app grows and evolves. Little friction is experienced when changes need to be made, and in those apps they are a true joy to work on as the age and evolve.
Other apps... you feel as if every line of code that needs to be changed is a major hassle, and with each and every moment you spend in the code you wish for a chance to rewrite it from the ground up.
The trick is to write lots of code, learn, work with other programmers, talk, experience, and gather up a library of thoughts and lessons learned. Aim to make code that is friction-free and is easy for anyone who comes after you to adapt and change. To me, these are the noble goals of our profession.