Noya looks great, so this isn't a criticism of them, that said:
> keeping design consistent from wireframe to mock-up to finished product is a challenge [...] this will allow me to mock-up exactly what I want and pass it off to dev in one process [...] I use figma, balsamiq, photoshop and have tried probably every other wire framing tool out there.
If you have a team of developers and they're not able to deliver to a specification, the problem is with the developers, not the tools you're using. Code generation does not replace developers, it's an augmentation at best, and so if you're running into these challenges with your current tooling then you're going to run into them with Noya (or any other tool that does not replace your developers).
You should either replace your developers with developers who can deliver to a specification, or change your approach to business (by not building software any more). I'll bet that the problem you've described here is not your only problem with the developers, rather it's one symptom of the problem.
Code is the easy part of software engineering, any competent developer can churn out code faster than it can be specified. The hard part of building software is translating a business need into a specification. Prototyping tools (like Figma) are very helpful upstream because they help the business provide a much more robust specification -- if you're building a prototype in Figma of how a user interacts with a page, you won't forget to explain what a specific button does.
If you're already doing all of that work to provide developers with a pixel-perfect rendition of what you want, and they're still not delivering it, just giving them a bunch of code instead to represent that design is not going to solve the problem.
A helpful model for evaluating the development work of developers is to think of it like construction workers: if a construction worker is given a plan for a square 250 sqft bedroom, and they build a 100 sqft shed instead, and you had clearly communicated that you wanted a 250 sqft bedroom, you would not think the input was the problem. You'd start to question the workers. Just because you can't write code, does not mean you need to allow developers to get away with churning out things that aren't what you've asked for.
I broadly that this sounds like a people problem rather than a tooling problem, but I would add:
>If you have a team of developers and they're not able to deliver to a specification, the problem is with the developers, not the tools you're using.
Or the problem lies in the designers providing the specification, which is also a situation I've seen a few times. A good design specification isn't just providing a view of the overall layout, it's also providing the pieces that went into that design: the visual components, the guidelines used for layouts, a list of colours and distances used, etc.
Simply providing a "pixel perfect" version will not get you good results, because that's essentially a lossy translation of the designer's intent. To implement that intent, you need information then just, for example, how big each button needs to be, you need to know how big a button can be, how small it can shrink to, what should happen with oversized or undersized text, how it will be positioned in its containers etc. Partly that's because intent is often a clearer way to communicate things than results, but mainly it's because there's no such thing as a pixel-perfect render target. Browser sizes can change, phones can be rotated, and people will insist on all sorts of different resolutions. It's only by describing intent (this element should fill the space, this point should be equidistant between these two points, etc) that you can adequately support all these situations.
That said, I broadly agree with you that this sounds more like a people problem than a technology problem.
> keeping design consistent from wireframe to mock-up to finished product is a challenge [...] this will allow me to mock-up exactly what I want and pass it off to dev in one process [...] I use figma, balsamiq, photoshop and have tried probably every other wire framing tool out there.
If you have a team of developers and they're not able to deliver to a specification, the problem is with the developers, not the tools you're using. Code generation does not replace developers, it's an augmentation at best, and so if you're running into these challenges with your current tooling then you're going to run into them with Noya (or any other tool that does not replace your developers).
You should either replace your developers with developers who can deliver to a specification, or change your approach to business (by not building software any more). I'll bet that the problem you've described here is not your only problem with the developers, rather it's one symptom of the problem.
Code is the easy part of software engineering, any competent developer can churn out code faster than it can be specified. The hard part of building software is translating a business need into a specification. Prototyping tools (like Figma) are very helpful upstream because they help the business provide a much more robust specification -- if you're building a prototype in Figma of how a user interacts with a page, you won't forget to explain what a specific button does.
If you're already doing all of that work to provide developers with a pixel-perfect rendition of what you want, and they're still not delivering it, just giving them a bunch of code instead to represent that design is not going to solve the problem.
A helpful model for evaluating the development work of developers is to think of it like construction workers: if a construction worker is given a plan for a square 250 sqft bedroom, and they build a 100 sqft shed instead, and you had clearly communicated that you wanted a 250 sqft bedroom, you would not think the input was the problem. You'd start to question the workers. Just because you can't write code, does not mean you need to allow developers to get away with churning out things that aren't what you've asked for.