Hi, I want to design a web application similar to paint, visio,... the user uses mouse to draw some shapes, connect them, click some buttons to run some software on drawn shapes.... I know basics of HTML, CSS, javascripts. I know C/C++ and Java, I am also familiar with Adobe webdesign tools, dearmweaver, edge,... However I have never done a advanced web application like what I want to do. I only did some simple static web pages. can you guide me what should be starting point to design such an advance server side web app? thanks
That's one hell of an undertaking, I'm impressed! I'd start by ripping apart the existing tools, checking out their technology, working out what has limited them. I imagine there'll be a long trial and error process. The key will be deciding what you need to build it with I suspect.
You can start with server side scripting. There are many tools available for web designing. Learn basic tutorial from the google or you can also see videos.
server side scripting? really? I'd have thought the emphasis would be on client side with the server just needed to save the work.
Would depend on what TYPE of "web application" were's talking about. Many web applications interface to a server for their data and storage. Others are standalone software with no server whatsoever. It's a surprisingly vague term and simply creates more questions than answers... Is it going on a website for realtime access? Is it a standalone / Native? If a "native" app what's your target, iOS, Android, Windows, Linux, OSX? What's your planned distribution model? Is having a required runtime on the client like nw.js (formerly node-webkit) or electron (formerly atom shell) desirable or practical? Though this part: Likely means the OP is NOT as familiar with HTML, CSS or JS as they will need to be for such a job, since the only thing you can learn from Dreamweaver is how NOT to build a website.
That doesn't narrow down the things I outlined... I'm talking the difference between things like Google Docs vs. say... Brackets or Atom. Brackets and Atom are web applications, they were built using HTML, CSS and JS running atop Blink (Google's fork of webkit -- so basically Chromium) -- but they don't have a server involved as they install their own copy of webkit to run locally. Much like how node.js lets you run JavaScript server-side. The lines are blurred and simply saying "web application" could mean any of a dozen different deployment methods; regardless of what the application DOES. I've been helping on a project right now that is going BOTH routes; able to run and save to local storage when offline or be deployed standalone, but ALSO being able to be run in a browser on a website or a mobile device, saving and backing up local data to the server. That's the full gamut of web application possibilities. Saying "Oh it's going to be a paint program" doesn't answer those questions one bit!
Thanks, I know about tools generally, I want to know for a typical 2-D graphical web application, like a 2-D game or 2-D paint...typically which application is used? Should I start implementing everything in low level by Javascript or there are some libraries available? how a typical 2D game is implemented? Thanks alot of your time, Actually I don't want the source code of paint application be visible to users, then it should be a server side application, right?. users can finally just download their output ( like painted picture in special format). Main unclear point for me is, how a graphical web application ( like a 2-D game or 2-D paint) is implemented? by a normal programming tool like VStudio or java and then call it somehow from web application? or by special tools just for web? What if it is only client side? Java is best option? I know how to write a standalone program on my PC, even graphical ones using OpenGL,... But I have no experience in Web programming ( altough I know the tools like java, javascript, html, css, adobe edge,..). I just wanted to start writing it by javascript, but I guess writing a paint by java script is like writing a application by assembly!
Then you do NOT want to make a web application. PERIOD If it's a web application, the user interface and functionality MUST be "client side" -- and that by definition means HTML and Javascript the user WILL be seeing the source of -- PERIOD. That may change in the next few years as the incorrectly named "webAssembly" starts to see support, but that tech is nowhere NEAR ready for prime time. Server-side code cannot draw a user interface, or handle user interactions. That's STRICTLY a client side operation. You want to use not distribute source, you're looking at making a native application or a applet using something like .net or Java -- both of which integrated into a website will result in a lot of users telling you to stick your project in an uncomfortable place. What? You mean like in the back of a Volkswagon? Web technologies are by definition open, and source distributed -- that's why there's a rule that if you don't want your code or content stolen, don't put it online in the first place! Now you CAN use web technologies to build a semi-native application and even have a degree of obfuscation -- Electron for example allows you to distribute as .asar archive files which do a degree of code obfuscation - that is easily reversed :/ There are other methods like minify with rename or intentional obfuscators, but for web applications the only practical languages for the UI is HTML, CSS, and JavaScript, and those are all SOURCE distribution languages... at some point no matter how it's obfuscated or screwed with, the browser will have to turn it back into the source so it can run it. Bottom line, as a web application the codebase is pretty much out there for anyone to dick with -- which is why any server-side code talking to it has to distrust and quadruple check any information you receive from the client. Saying you don't want the code for the user interface to be shared is the same as saying you don't want a web application. That's just not how they work.
Thanks again, Then I conclude if I want a web application, I must have a client side part which is open source anyway (but may I use obfuscation). 1- but what if I want to have a processing engine ( my application is not just a paint, it will run some processing on drawn network)? I guess I can put it on server, then just send user's drawing to server, process it, and return result back? Then I can write it with C++, run it on server and don't give code to user, right? 2-now in client side, I found java to have not that much attractive view. then other than writing low level JavaScript+HTML+CSS, is there any better way to have a drawing tool? or similarly 2-D attractive game? I don't care if user see this code.
Sending something as large to the server would be... problematic. Particularly if it's something the user is drawing. For things like a blur filter you could MAYBE get away with it, but for some other things not so much. Generally speaking there's a reason you don't see web applications used for this stuff, and when you do (google docs for example) their a usability train wreck that's so painfully slow you want to suck the end of a chemical action high velocity lead pellet dispenser as a user. The handshake back and forth between the server and the application, much less the data transfer can be a real headache... unless the user happens to be in the magical fairytale land of endless 1gpbs fiber and the server is only handling five or six clients at a time, realtime image processing can quickly become an outright disaster. There's a REASON things like Photoshop, GIMP, Paint Shop Pro and Pixel are native applications. As to your part 2-, really you're asking for things web languages just aren't meant to do. There are wild claims about things like Canvas and WebGL, but really it's ice-skating uphill at best and in it's infancy. It REALLY sounds like you should be making a native application using something like SDL (or openGL on top of SDL) in a language like C, C++ or Pascal (basically anything that's cross-platform and native), that can then talk to the server for just the stuff you want online. Of course that will mean learning about sockets which can be a royal pain and a giant hurdle.
Actually the amount of data to be passed to server is very small, client doesn't send whole of a picture, just list of objects and connection among them. moreover this will be a academic application running inside university LAN, then we don't care about bandwidth. BTW, thanks, I will really consider writing it by a native programming tool, pulse socket programming. just as final question, do you know or guess how below tools are programmed? https://www.draw.io http://drawisland.com or a simple 2-D game in miniclip.com
Those are all client side javascripted, the only thing the server does is send the code, and handle saves. Nothing is sent server-side in real time, only a complete data set is sent when you "save" to whatever target they are using. (or you choose). Take draw.io, it's got a massive (painfully so) 3.5 megs of scripting in 9 files. The biggest of which providing most of the functionality is this: https://www.draw.io/js/app.min.js Which while whitespace stripped / minified, is still just the code without any real obfuscation. You could easily run that through a beautifier and have legible workable code to play with. Thankfully they're serving that gzipped so it's "only" 512k, but looking at a lot of the flawed methodology in the codebase I'd say 50% or more of it could have been left on the cutting room floor -- but I've been writing software for over three decades, so I have a slightly different view on what "efficient' means. (My first computer had 127 BYTES of RAM free) Though I do see some telltales of one of the oddball "middle language that compiles to JavaScript" in that file... something along the lines of React.js though I don't quite recognize the syntax. Generally I avoid those as why not just write clear legibile JS in the first place? But people seem to LOVE slapping abstraction atop abstraction and framework atop framework so they don't have to actually learn how things REALLY work. The laugh being they sell themselves on the extra work and extra time as less work, saving time and being more productive - I just don't see it.