I would say, eschew any fancy front end framework. Build an HTML form. They're tab-able by default. You can even tab to a button and hit enter to press it from the keyboard.
Separate out the UI and business logic, and you can probably port most of it to a backend MVC (where view means a template, meaning HTML) framework in VisualBasic. Once it is cleaned up, you can do a feature-by-feature rewrite in your backend language of choice (I'd likely recommend Django if you can go Python, but SparkJava might be more prudent for the kind of big freaking Enterprise that chooses to do stuff in VB).
Edit: after seeing https://news.ycombinator.com/item?id=14787139 I agree that you'll probably need handsontable or something like it. Simplicity is your friend; overengineering is unfortunately a common tendency among developers of all stripes, although the web kind especially.
> why are you building this in house?
This is an existing desktop application built years ago (10+) and went through many updates over the years.
Lot of business specific customisations are also in. Hence, can't ditch it and go for a generic solution at this stage.
Have to ask, why are you building this in house? Most accounting packages (quicken/quickbooks/sage) have this built in already and your accounting/bookkeeping people would already be familiar with it.
Or, if you're a smaller shop, maybe something like stripe? Or even a Google Doc/Excel. They have a bunch of easy to use templates these days.
If you really have/want to build it, this architecture is simple enough that i don't think its really stack dependent. MEAN would handle front end and a diverse invoice structure; Django/Postgress have some great admin-form features and handle multi-table queries gracefully; and .NET with windows forms would make short work of a desktop UI. Just go with what you know and focus on speed.
Thanks for your comments.
> If this is a hobby project
No. It's a production live project. But, there is no urgent timeline as of now. I am not in a hurry to move.
> if you're used to the ease of VB
Yes. But, not looking a close experience in web tech. I am familiar with web tech to some extent. But, the grid thing is a little bit tricky for me.
Thanks for sharing Anvil - Will look at your solution.
So, the first question to ask is: "Do I need the full-fat web development stack?"
If this is a hobby project, and the goal is to learn all five languages and 3-4 frameworks needed to create a traditional JS+API+DB web app, then go to town! Everything you want to do (eg keyboard-driven layout) is possible on the modern Web; you'll just need to read a lot of documentation. (And you will have quite a valuable skill-set at the end of it).
But if you just want to get something done (and especially if you're used to the ease of VB), be warned that the web is a exhausting many-tentacled pile of technologies. You might want to look at a simpler approach. I'm biased - I'm cofounder of a tool that aims to bring the VB experience to web apps (visual UI design, everything in one language [Python] etc - check it out at https://anvil.works). If you don't want to tangle with the web, something like Anvil, or building a native desktop application, are still possible routes.
> But be aware - study the depth of some of these plugins. Invoice entry screens are fraught with all sorts of things like real time validation (e.g. will you allow a user to specify a quantity of an item greater than what is in stock? Can you calculate tax amounts on the fly line by line? Can the user change the pricing of the item on the fly and are there rules that have to be adhered to in order to prevent fraud) etc.
Yes. You hit the nail on it's head. All of these apply in this case.
For example, our HR app (which is built on Bootstrap + jQuery) has a button for 'Add Employee' on the main employee list, but we have also linked the '+' hotkey to that button so the user does not have to revert to the mouse to add the next employee when doing batch entry.
Within that, there are plenty of grid style entry plugins (mentioned elsewhere in this thread) that you can add on to do things like the invoice screen etc.
But be aware - study the depth of some of these plugins. Invoice entry screens are fraught with all sorts of things like real time validation (e.g. will you allow a user to specify a quantity of an item greater than what is in stock? Can you calculate tax amounts on the fly line by line? Can the user change the pricing of the item on the fly and are there rules that have to be adhered to in order to prevent fraud) etc.
Yes, I've developed invoicing type apps many times before. It certainly has some 'gotchas' that can trip you up, and the UI is certainly a lot more complex that it first appears as you have to adhere to strict accounting principles in the back end.
If you're interested in building it as a web app but want a keyboard-accessible grid / spreadsheet-like interface, then you have a few options.
One of the most fully-featured JS libraries is Handsontable. It looks very flexible. They have some demos on their website to play with: https://handsontable.com/examples.html?headers
(Bonus: If you're using react, there's already a react component for using Handsontable: https://github.com/handsontable/react-handsontable )
> None of the web style solutions seem to be suitable for a keyboard based (tabbing style) grid to represent an itemized billing.
I suggest you to build your own keyboard listener extension, frontend frameworks are don't really have built in support for this since it's too specific. You can very easily listen to all keyboard events with vanilla JS and trigger actions accordingly.
Take a look at Angular 4, it has all the event handlers you need in the templates/view modules.
Angular is more like a full feature framework with some enterprise feel to it.
If you want a modular system with craftmanship level attention to detail (you can build your stack how you like it), then try React or Vue.js.
Fwiw, I built a very-very similar application recently using Angular (1.5) and it wasn't a great experience.
I originally used Angular because of all the enterprise components available (like JSON-Schema form elements and custom tables) but pretty much all of them ended up having some behavior that wasn't quite what we needed. Which resulted in tons of wasted time writing code around them, then forking and modifying them, then eventually just scrapping them and rewriting the parts of the app that used them. So I'd personally recommend not going with existing large table/form components. I also found myself working around some of the "Angular way" of doing things as the number of inputs and calculated outputs got larger, with most of the time savers up front (two way binding, etc) requiring major refactoring to get decent performance.
If I was doing it again I'd probably use react/redux/redux-thunk, just for more control over how the application's structured and how I'm connecting the inputs to the business logic.
Like, I recently found https://nadbm.github.io/react-datasheet/ and was pleasantly surprised how small and reasonable the codebase looked. Though I'd still just use it as a start/inspiration for your own custom table components instead of actually pulling it in as a dependency. And they give an example where they're constantly reloading the whole state of the table on change (I think intentionally just to keep the demo simple), but there's definitely better ways to deal with mass input. Just my 2 cents, good luck!
Edit: I originally recommended checking out redux-inputs for mass input, but it has an open issue* that was exactly the kind of thing I ran into with the form/table libraries that started the vicious cycle - I guess the moral is at least when you write your own way of doing this kind of thing you get to choose your battles.
Check out ERPNext (http://erpnext.com/). It is a modern open-source ERP solution built in Python, has commercial support and an active community.
There is also Eto (https://github.com/picoe/Eto), a cross-platform C# GUI toolkit on which the excellent Manager accounting software (http://www.manager.io/) is built.
Thanks. Would explore this option.
It's not keyboard short-cuts, but the ease of showing a let's say 10 by 8 cell grid and entering data by moving up, down, side - left and right. etc.,
Can't edit this comment anymore. Hence, posting as a reply.
Looks like UWP is more specific to Windows. When moving away from VB, I was thinking of more decoupling from any specific lock-down, in case this can be productized later.
WPF was really good at this. I haven't used it in many years though.
+1 If time is an issue I would first migrate to a C# (or even VB.NET) based desktop app, and then later (if needed) add a web front end with ASP.NET
Would you consider migration to a (C#) .NET based solution with either a web-based or WPF / UWP front-end? I can't imagine keyboard shortcuts being an issue with either one of these choices.
I would stay away from JS fancy stuff. Stick to the proven Java/C#/RoR stack.
> currently desktop or web based
currently desktop based. Want to move to web based.
Assuming you're using a local SQL Server instance, you can put that online and build out an API and front end independently. Put some serious thought into a C# API and JS front-end. When done right, you can rewrite either of them without impacting the other.
If it's already in Visual Basic the default for "modern stack" would be a C# API back end and whatever JS front end you want. This would also be crazy easy to host online if that's what you wanted to do.
This has to benefit of being able to use the exact same database and update the schema over time with your API, completely independent of the front end.
You don't specify whether your app is currently desktop or web based. Hitting the enter key has been the standard way to submit HTML forms since the very early days of the internet. Why would you need a special library to support that?
Since you're asking about C/Qt I'm assuming the current app is desktop based? Having just completed a client project migrating a large desktop-based application to the web (C# API, Angular front-end), work flows are going to have to change to at least some degree. It is very rare to be able to cleanly, easily port 100% of the desktop experience to the web. If that's a deal breaker, make sure it's not worth it to stick with the desktop. You can still separate your concerns and provide a modern experience.
If you used strictly Visual Basic and still utilise .net, have you ever tried to use PowerApps from Microsoft. It is like ready to use tool to create custom applications without much of programming and maybe it is worth of trying for you instead of any new frameworks?
Sounds like you can use all sorts of different tech but web2py might be easy - the default forms are tabable, it's quite quick, easy, relatively secure and doesn't need updating all the time. Against it's not so modern and makes it hard to do stuff like chat messaging.
If you like to try React, checkout the open source book The Road to learn React . Not sure what kind of payment gateway you are using, but after your first application is up and running, you could add Stripe to it .
-  https://www.robinwieruch.de/the-road-to-learn-react/
-  https://www.robinwieruch.de/react-express-stripe-payment/
-  https://stripe.com/
Personally, I would choose Spring Boot + Angular 4 for a project like this. Lots of functionality automatically configured "out of the box" (DB access, security, JSON object mapping) and a rich set of UI components available with Angular such as Prime-NG (https://www.primefaces.org/primeng/#/)
As I spent years working on billing for a world leading telcoms company I have to ask
What do you mean by "billing application" your q implies you want to input transactions into some accounting (presumably double entry) system?
Does not your Accounts receivable have a web frontend or an API? do you really need to build your own accounts receivable / invoicing system
Instead of writing your own invoicing application, what about writing a custom front end to an existing web-based app (using existing API)?
That way you can focus on the specific UI you need and not mess with recreating everything else. Your UI doesn't need to be browser-based.
I don't have a specific solution for you, but you can narrow down your search by taking into account whether something(be it a framework or component of a framework) is focused on accessibility.
Maybe libraries like Developer Express would work for you. They have pretty sophisticated grids and other UI controls that are close to a desktop look and feel.