Web Application VS Windows Application
-
ah i see, so there are rules, can you please give me any guide how to start a project using document DB from A to Z, because really i'm lost in this stage, document DB is new for me and i do not know where i should start,
you can imagine someone hear something for the first time and he is ignorant of the steps he should follow -
before with relational DB, we establish the conceptual model that include all entities of the whole project and the relation between them (one to many or many to many) then based on the entities we create tables and start developing the app based on the model, but now i'm lost with this new methodology of DB,
between us i really found this document DB very useful and easy but i'm still unable to put my feet on the right way -
@IT-ADMIN said:
between us i really found this document DB very useful and easy but i'm still unable to put my feet on the right way
I think that you are overthinking it. Try taking the data that you have and instead of thinking of a place for each "type" of data, make a single document for a single user/person and put all of the necessary data into that document. The data remains related by the nature of existing within a single document. If you look at the data that you have in a relational design, you can assemble a document by doing a join on it. Instead of data all over to assemble to a user, start with the data in one place.
And try not starting with the database, start with the application. You don't need to design the database at this stage.
-
@IT-ADMIN it's been a few months. Any follow up on your development project?
-
Pinging against in case this got missed @IT-ADMIN
-
Long thread for me to go through on my phone.. But another option since you mentioned vb.net that may have already been mentioned is to publish it as a clickonce application. I use that on a project and it works well.
In my case Click once does not need administrator right to "install" and handles updates automatically.
-
Desktop apps have their place, this is silly.
A native desktop app can better utilize hardware, take advantage of native OS abilities that chromeless frameworks can't.Native apps can be built in lower-level languages and be built to be much more solid, speedy, use fewer resources, take less RAM without all the middlemen fluff.
I'm all for web apps, they are cool and all, but they depend on a browser and a tab being open. They have limited abilities, they can't even put an icon in the system tray, or startup with Windows. They are not as easy to control via OS security policies.
Maybe I just have bad luck, but I ALWAYS try to find services that give native desktop apps. If not native, then at least full featured frameworks that can use native OS features.
I rarely touch Office online because it's just slow, herky jerky, buggy, crashy. I absolutely hate interfaces that aren't very responsive.I agree with Scott that IF the app can be a web app, go for it. But there are also times when you might want native OS features, lower level language that compiles with fewer dependencies, smaller size, greater efficiency, and so forth.
Apps can be built to self-update, most desktop apps do. I've never had to do anything fancy to get Slack to update, it just updates itself. Slack isn't native, it's a framework, just using it as an example.
I think when the OP talked about Windows apps being "buttons and boxes" or whatever, he probably just means that there is a drag-n-drop interface for common .NET form controls. You just place all the controls where you want and program from there. Things like minimize/max/close, resize-able borders and control menus are all sort of automatic.
But with web apps, form libraries are not as popular, and there aren't any really good drag-n-drop designers for creating UI FROM such things anyway.
Much time has to be spent designing the UI, even if you do use a library (you have to learn the library!), or even a CSS framework like Bootstrap or Foundation, you still have to code and try to keep straight the rows and columns and how you want things to respond and slide around responsively.In any case. Desktop apps definitely have their place. I use desktop email, desktop photo editing, desktop file and information management tools, chat, backup apps, file sync, document readers, DB management tools, remote control tools, FTP, text editors/IDEs, and 3 dozen others that are just way more better suited to native.
Native apps always have the option of avoiding updates. Or lets say an update ruins things, you can usually reinstall a previous good version. With web apps, if they screw up and something breaks, you have no options but complete down time waiting for fixes or trying to fix it yourself depending on where the problem lies.
And of course, browser tabs are, for the most part, sandboxed, so there are already limitations regarding file system. Try auto-connecting to files over the local network from a web app. Web apps don't have unlimited power, if they did, we would be right back to having huge malware issues. Malware has made web apps more limited and locked down. Native apps are still the way to go if you need power and greater control of OS abilities and features.This web versus native argument can go forever, but just like most things in life, you pick the best tool for the job. If a web app will do it, always go web app. They are typically easy to set up and maintain. If you want native OS features or require to greatest efficiency, security, or OS-level features, then obviously native.
If you want to do both, as is popular these days, look into crossover frameworks like Meteor, Electron, or Cordova for mobile as well.I believe cross-platform frameworks are going to be huge for some time to come, but there will always be a special place in my heart for a native app that can fully utilize system tray, startup, notifications, file system, and full system power.
Yes frameworks can do some of this, but they have to come with a lot of middlemen architecture, bloating the apps RAM use probably 3 to 5 times more than would be necessary with native programming.Anyway, I've rambled on long enough.
-
@guyinpv said in Web Application VS Windows Application:
Desktop apps have their place, this is silly.
A native desktop app can better utilize hardware, take advantage of native OS abilities that chromeless frameworks can't.Native apps can be built in lower-level languages and be built to be much more solid, speedy, use fewer resources, take less RAM without all the middlemen fluff.
CAN be, yes. But very rarely do any of those things matter, especially for business apps. Those are things that apply very commonly to video games, and once in a great while to business apps (CAD for example) but almost never.
-
@guyinpv said in Web Application VS Windows Application:
I'm all for web apps, they are cool and all, but they depend on a browser and a tab being open. They have limited abilities, they can't even put an icon in the system tray, or startup with Windows.
I have web apps that can do all of those things.
-
@guyinpv said in Web Application VS Windows Application:
They are not as easy to control via OS security policies.
I'd argue that that is almost always a good thing. OS policies are the wrong place for the majority of app management. It's similar to relying on the LAN for security, it was necessary long ago but mostly crufty today. You can move security into the central app for better control.
-
@guyinpv said in Web Application VS Windows Application:
I rarely touch Office online because it's just slow, herky jerky, buggy, crashy. I absolutely hate interfaces that aren't very responsive.
I actually have the opposite experience, even with MS Office. Neither experience is great, but it's often better online. But a lot of that is because it's a web app even when running locally. Like many modern apps are. It's become common to make things that look like native apps but are actually web apps.
-
@guyinpv said in Web Application VS Windows Application:
Native apps always have the option of avoiding updates. Or lets say an update ruins things, you can usually reinstall a previous good version. With web apps, if they screw up and something breaks, you have no options but complete down time waiting for fixes or trying to fix it yourself depending on where the problem lies.
What business application doesn't have this dependency though? How many business apps do you encounter that has no need to talk to a central server? They exist, CAD, video editing, etc. But most business functions are networked and having a native fat client dependency only makes them more fragile rather than less.
-
@guyinpv said in Web Application VS Windows Application:
If you want native OS features or require to greatest efficiency, security, or OS-level features, then obviously native.
Partially this is true. But web apps have nearly unlimited access to native features today, including OS level features, are often super efficient (often better than native because of better coding) and I'd argue that security is backwards, native apps have the biggest security challenges.
-
@guyinpv said in Web Application VS Windows Application:
If you want to do both, as is popular these days, look into crossover frameworks like Meteor, Electron, or Cordova for mobile as well.
Just web apps running locally
It's not really a crossover. You can do all of the same stuff without those frameworks using web apps. The web server can be local. -
@scottalanmiller said in Web Application VS Windows Application:
@guyinpv said in Web Application VS Windows Application:
Native apps always have the option of avoiding updates. Or lets say an update ruins things, you can usually reinstall a previous good version. With web apps, if they screw up and something breaks, you have no options but complete down time waiting for fixes or trying to fix it yourself depending on where the problem lies.
What business application doesn't have this dependency though? How many business apps do you encounter that has no need to talk to a central server? They exist, CAD, video editing, etc. But most business functions are networked and having a native fat client dependency only makes them more fragile rather than less.
sure, this is an issue of the central component fails, but that seems to be a less likely place for things to break. if you compare how often Outlook breaks compared to Exchange, Outlook breaks significantly more often. Also, when Outlook breaks, it generally only takes down one user, not the entire office.
-
@Dashrender said in Web Application VS Windows Application:
@scottalanmiller said in Web Application VS Windows Application:
@guyinpv said in Web Application VS Windows Application:
Native apps always have the option of avoiding updates. Or lets say an update ruins things, you can usually reinstall a previous good version. With web apps, if they screw up and something breaks, you have no options but complete down time waiting for fixes or trying to fix it yourself depending on where the problem lies.
What business application doesn't have this dependency though? How many business apps do you encounter that has no need to talk to a central server? They exist, CAD, video editing, etc. But most business functions are networked and having a native fat client dependency only makes them more fragile rather than less.
sure, this is an issue of the central component fails, but that seems to be a less likely place for things to break. if you compare how often Outlook breaks compared to Exchange, Outlook breaks significantly more often. Also, when Outlook breaks, it generally only takes down one user, not the entire office.
Right, but it is still extra risk. The choices are, in that example, require only Exchange or both Exchange and Outlook. Outlook doesn't reduce the risk, it increases it.
-
@scottalanmiller said in Web Application VS Windows Application:
@guyinpv said in Web Application VS Windows Application:
If you want to do both, as is popular these days, look into crossover frameworks like Meteor, Electron, or Cordova for mobile as well.
Just web apps running locally
It's not really a crossover. You can do all of the same stuff without those frameworks using web apps. The web server can be local.What do you mean by "web apps" then? Cause I'm just referring to websites, essentially.
And I've never seen a web page able to put itself into system startup, maintain account auth auto-login, have a system tray icon and use native notifications and access deeply into the file system. I don't think Greenshot can work as a web app. I don't know how well web apps can create system-wide keyboard shortcuts as well.
One thing I hate is how bloated these "websites in a frame" apps are. Programs that should normal take 30 or 40MB have to take 180MB just for all the fluff.
I don't really buy it that you have the opposite experience with web interfaces, that they are MORE solid than native desktop. How can that be? It's dependent not only on the speed of the app server, but also the browser, and your ISP bandwidth, etc, things a native app may not have to deal with.
Heck just using my online Outlook mail (actually Hotmail) is buggy. Often it won't delete as fast as I can go through messages. The interface dies and says I should reload the page. I run Sweep and it takes 15 seconds to find and delete 8 messages, etc.
My Yahoo mail is even worse, often parts of the entire UI just go blank. Or something refreshes the page and I'm in a different part of the screen or another folder, etc.
Even though the web app has certain control over the keyboard, there have been times when I'm typing and hit <backspace> only to have the entire page go back in browser history!But again, I'm not saying websites or web apps or whatever you want to call them, are wrong or bad or insecure or any of that. It's just that native code has many advantages. Look at Steve Gibson, the dude still programs in freaking assembly. Creates Windows apps that are single EXEs less than a megabyte that take almost no RAM at all. Removing all that fluff can have its advantages. Especially for little utility apps with simple purposes.
-
LOL I love the Steve Gibson example. The size of his apps has as much to do with no fluff assembly as they do to the lack of complex functionality. Don't get me wrong, I like much of what he says, but definitely not all - I don't worship at the alter of Steve Gibson like Leo seems to at times.
I agree that web apps never seem as fast as native apps. But Outlook is now a Web app, it just happens to be running on a web server inside your computer, not on the other side of your internet connection. It can have as much local control as you want to allow it to have. I'm willing to bet that someone could get a version of Greenshot to work in that type of environment, but it still would be tied to Windows machines, so probably isn't worth the effort.
-
Well I use Thunderbird
-
@guyinpv said in Web Application VS Windows Application:
Well I use Thunderbird
I really don't like POP3 or IMAP - I use activesync where ever possible.
