Sign in to follow this  
Dezachu

Web App Development?

Recommended Posts

Hey guys,

 

I've been a C++ programmer for 3 years now. Dabbled in C#/Unity and Python and recently I was tinkering with an API using C++, cURL and Jsoncpp. One of the apps I've made using said API is pretty good, but it has no place as an executable - why would you use an executable you have to download when you can do the same operation on a website?

 

My knowledge of web development/web app development general is extremely limited. I know a little bit of HTML/CSS and practically nothing else. I've heard of terms such as GET, POST etc but only have a super vague idea of where to start. I'd like some advice on where I should begin if I want to create an app on a website. Would HTML/JS do the job? Do I need to look into PHP? MySQL won't be needed as the API returns all data in Json. 

 

TL;DR Wanting to start developing basic apps to plop on a website, any good resources/tutorials/advice for this?

 

 

Thanks smile.png

 

EDIT: I'm aware this isn't strictly game related, but the API is for a game if that helps! The app I'm thinking of is interactive either way and I've been on these boards for a fair while - probably the best place to ask.

Edited by Dezachu

Share this post


Link to post
Share on other sites

When you say an "app" on a website, that's not enough information.  Are you talking about a game, or a business app on the website, or are you talking about having a client program that performs tasks on a website, like a multiplayer game?

 

Either way, the first thing you need to do is decide on all the technology you need.  Long ago there wasn't a name for all this stuff, but now this collection of software is called a "technology stack."  This could include the language, web server, database, and javascript libraries used for the client web pages.  

 

So this puts you in a strange place right from the start.  I've never done anything like this, and I have no idea what to do, and you want me to pick specific technologies from thousands to perform the specific parts I don't even know I need?  Yep.  This is probably what prompted the question.

 

All of this stuff basically does the same stuff, it just trades one thing for another.  It is just like different languages, IDEs, and libraries do the same things but just in different ways.  You just have to pick one and use it, and then if you get a lot of experience you can choose different stuff.

 

For now, if you are trying to make a client program that talks to a web server, the prototype to make to learn about this stuff is a chat program.

If you are trying to make a webapp, then you want to start simple and make a fake online store with products in a database, and walk the user through putting stuff in a cart and checking out.

 

With a little more information I think we can point you in the right direction.

Share this post


Link to post
Share on other sites


why would you use an executable you have to download when you can do the same operation on a website?

 

because bandwidth costs money?

 

because networked apps are inherently slower than non-networked apps running on the local machine?

 

because you don't want to have to connect every time you want to run the app?

 

there are only two commodities in life: time, and money. using a web app can cost you more in both.

 

That being said, the "suite of tools" or "technology stack" required will depend on the nature of the app.  more detail is required.  there's a big difference between writing say an MMORPG and a perl shopping cart script for a secure order form.  Other folks on the forum here are working on the former, and i've done the latter.  So you are correct in guessing that there may be some guidance available from the forum members here on gamedev.

Share this post


Link to post
Share on other sites

There are a lot of reasons why you may want to provide an executable instead of a web app:

- Web applications have a lot of the source public (HTML and JS are visible on any browser). Even with technics of obfuscation everything that's happening on the client's PC can be seen, on an executable it's harder for the average user and even advances user won't see the code you wrote, only the assembly generated. This can lead to security issues, so you need to be more carefull in a web application.

- Browsers are different, something may work in some browser and not in another, even following the standards. Some browsers support WebGL and some not, for example, but it goes to even the basic stuff (like setting the border size of a button).

- Web pages have some limitations. On the client's PC you have a sandboxed environment for security reasons, you can't access the file system unless the user allows it and even there you may encounter some problems accessing to other external devices.

- JavaScript is a non-typed language, for C++ developers it could be a hard transition. It's not a hard language, but the way you code it's really different (imagine using A LOT of function pointers in C++ and ignore some things you know about classes).

 

There are probably more, but I can't think more right now.

 

You'll learn most things creating web apps, so don't worry if you don't know the difference between GET and POST right now.

 

When I started making web apps I used PHP with CodeIgniter for the web services and HTML/CSS/Jquery for the client side. PHP is the language, CodeIgniter is a PHP framework that already manages a lot of things, HTML and CSS are the standards for presentation and JQuery is a framework based on JavaScript.

 

I've never used other frameworks but there are a lot. I've read that CodeIgniter is kind of outdated now and the "new thing" is Laravel, so maybe you can start with that for the web server. Other PHP frameworks will also work, but I've read that CodeIgniter is one of the simplest for a begginer.

 

Going out of PHP (it's a really old language, even though it's still being updated) the most popular option currently seems to be Ruby on Rails (Ruby is the language, Rails is a framework). I've done some simple test with it an it looks really powerfull and easy to code.

 

It's not clear what you wan't to do with your web app/game, but if you're C++ API does not listen and respond to HTTP requests you'll also need a web server (and you probably would, since making an app that does that is not trivial, and you won't find a web hosting that supports your custom web server). For a PHP web server you should use Apache (I always use xampp, it sets up an environment with Apache, MySQL and more). I'm not sure what web servers you need for other languages. Once you have the web services you can execute your C++ executable (http://php.net/manual/es/function.exec.php) and send to the client the json your c++ code generated.

 

If you want to make a browser game you can find several JS frameworks for games, look at Phaser for example.

Share this post


Link to post
Share on other sites

I'd disagree in a web app taking more time (for the user, at least!). Downloading an app, potentially having to install some stuff for it, running it etc - why would you do this when you can enter a URL and have the app sat there in front of you?

 

I'll be a bit more specific - I want to access an API to return some information in Json based on the input of the user which will be two usernames. Grab some data, do some checks, inform the player of whether or not the first name has played with the second name recently. It's not complex at all - I thought it'd be a soft introduction to the myriad of web tech smile.png

 

If I create a website for myself I'd like to attempt to create other programs that utilise databases. In terms of games on said site.. It's unlikely!

 

Thanks for all your help so far.

 

EDIT: @Diego, thanks for the more in-depth analysis too. I've tinkered with JS before and the function pointer thing is a bit of a 'that's crazy!' thing at first but it's all good now tongue.png I've also heard about RoR a few times over the last few weeks - best give it a look. Thanks again.

Edited by Dezachu

Share this post


Link to post
Share on other sites

I don't know what all the grief about bandwidth and web apps being slow is coming from.  This is how the modern world works.  If you want to bank you use a web app.  If you want to sell stocks and shares, web app.  If you want to book a holiday, web app.  Pretty much any coperate software that interacts with a back end database, web app.

 

 

The modern way of doing this would be to use some kind of framework such as RoR or cakePHP to build out a restful API.  The frontend would obviously be done in Javascript (or some fancy new language that compiles to JavaScript).

Share this post


Link to post
Share on other sites


The modern way of doing this would be to use some kind of framework such as RoR or cakePHP to build out a restful API.  The frontend would obviously be done in Javascript (or some fancy new language that compiles to JavaScript).

 

+1  

 

For what you want to do, whether you use a web page with Javascript or a C++ app, the easiest way for the server to provide the functionality is a simple Restful service that consumes and produces some JSON.  The client needs an HTTP library to send the Get, Post, Put, and Delete messages, and the server needs to consume them and return the requested data.

 

At this point the server code depends completely on the language/web server you are using.  

Share this post


Link to post
Share on other sites

 


The modern way of doing this would be to use some kind of framework such as RoR or cakePHP to build out a restful API.  The frontend would obviously be done in Javascript (or some fancy new language that compiles to JavaScript).

 

+1  

 

For what you want to do, whether you use a web page with Javascript or a C++ app, the easiest way for the server to provide the functionality is a simple Restful service that consumes and produces some JSON.  The client needs an HTTP library to send the Get, Post, Put, and Delete messages, and the server needs to consume them and return the requested data.

 

At this point the server code depends completely on the language/web server you are using.  

 

 

 

That kind of site makes me sad. Or angry.

 

All errors are unrecoverable. There is usually no way to resubmit. You cannot bookmark, or at least bookmark easily. Back button is broken.

 

Prime example hit my team today.  We were editing a bug in Jira (a common bug tracking database that relies in the above-mentioned heavily scripted system). Multiple people were involved in researching it. It took about a half hour, maybe 45 minutes, to figure out and update the details.  Hit submit.  The form vanished and several seconds later there was a popup, "Error communicating with the server."  There was no way to resubmit. Opened the page in Chrome's development window while praying it was just inside a hidden element. Nope, it was inside a now-deleted dynamically created JavaScript powered div.

 

While those JS-powered pages can look pretty slick, they are filled with assumptions that fail horribly in the real world.

 

Another example, the entire HealthCare.gov site. Everything scripted. Under load people get errors similar to the ones above with no way to resubmit on errors, no way to bookmark their progress, no way to handle anything outside the ideal perfect flow. If there are any errors, any busy servers, and dropped connections, their fancy JavaScript power pages fail spectacularly.

Share this post


Link to post
Share on other sites

I highly recommend you have a look at Dart.

 

It's really easy to get into if you have experience with languages like Java and C#. The syntax is similar to those languages.

 

It has a really powerful HTML manipulation system which works really really well. It's like vanilla JavaScript but actually usable.

 

It compiles to JavaScript as well so it's guaranteed to run in any modern browser.

 

http://dartlang.org

Share this post


Link to post
Share on other sites

Why not get any of the opensource content managenent systems out there (drupal comes to mind, there must be a ton of others) that you can install and will actually already work as the basics of your website, that you can then reskin with your own templates (HTML, Javascript and XML involved, or, in some cases, you get a nice shiny web interface if your reskin is lightweight), and for which you can then write plugins (PHP or whatever kind of language the CMS supports) that will implement your actual web applications functionality?

 

I guess 80% of what you need you will get out of the box from a cms like drupal, or some already existing extensions or plugins. The rest will still need your work, but at least you don't have to write basic stuff.

 

 

List of available CMS:

 

http://en.wikipedia.org/wiki/List_of_content_management_systems

Edited by Gian-Reto

Share this post


Link to post
Share on other sites


That kind of site makes me sad. Or angry.

 

I'm not talking about a webapp in a web pages that does this.  You are right, this is a terrible way.  I'm talking about a client app that talks to a server without any web pages involved.  I guess I misunderstood what the OP was trying to do.  I've done many clients that talk to servers with Rest and it works great.

Share this post


Link to post
Share on other sites

Why would you use an executable you have to download when you can do the same operation on a website?


If the web site supports the same things, then go for it. Otherwise, the reason is because you *can't* do all operations on a website.

The opinionated answer is because web technology is absolutely terrible in comparison to native app technology. As web technology advances, almost consistently poor design decisions are being made from an engineering point of view. Of course, if you're not an engineer, you may not care. From what I've seen, the vast majority of people working on new web technology are not engineers and don't care about designing new systems well.

If you're thinking of learning PHP, STOP. RIGHT. NOW. Pick a language that doesn't suck. Use Java or C#, or even C++. PHP is the language of choice for developing unmaintainable codebases. You don't want to start down that path. Edited by Nypyren

Share this post


Link to post
Share on other sites
I'm not going to tell you what to do.

I am going to tell you what not to do.

PHP.

F$/$&;$&; PHP.

People that say programming language don't matter, haven't met PHP. It's a language that never should have been made popular because of its popularity alone. It is complete crap.

Share this post


Link to post
Share on other sites
Ok I changed my mind and I'm going to tell you what to do as well.

If you just want a simple REST based app to return some JSON, why not, you know, go with the J from JSON.


Node.js is the current sexy, ( it used to be RoR, but that's like sooo 2012 now... ), it's well support, easily deployed and is about the easiest way on earth to serve JSON. Using Express, you can self host an HTTP server in a few lines of code and you could do what you are talking about in about 20 lines total.

The downside is callback hell... You'll see. :). Thinking asynchronously takes a bit of brain bending.

Oh yeah, and it's not @&$:)ing PHP. I've actually done a few kinda tutorials using NOde.js if you are interested.

Share this post


Link to post
Share on other sites

That kind of site makes me sad. Or angry.

 

All errors are unrecoverable. There is usually no way to resubmit. You cannot bookmark, or at least bookmark easily. Back button is broken.

 

Prime example hit my team today.  We were editing a bug in Jira (a common bug tracking database that relies in the above-mentioned heavily scripted system). Multiple people were involved in researching it. It took about a half hour, maybe 45 minutes, to figure out and update the details.  Hit submit.  The form vanished and several seconds later there was a popup, "Error communicating with the server."  There was no way to resubmit. Opened the page in Chrome's development window while praying it was just inside a hidden element. Nope, it was inside a now-deleted dynamically created JavaScript powered div.

 

While those JS-powered pages can look pretty slick, they are filled with assumptions that fail horribly in the real world.

 

Another example, the entire HealthCare.gov site. Everything scripted. Under load people get errors similar to the ones above with no way to resubmit on errors, no way to bookmark their progress, no way to handle anything outside the ideal perfect flow. If there are any errors, any busy servers, and dropped connections, their fancy JavaScript power pages fail spectacularly.

 

 

I should point out that you can make a heavily scripted app that has a lot of dynamic content and many states or "pages" on a single url, without causing those kinds of problems for the user. It just takes some additional code. In your Jira example Atlassian could have stored the content it was trying to ajax to the server and recreated that div with the same content if there was a problem. The back button and refresh cause page loads the states in javascript, but HTML 5 makes it quite easy to store client side information you can use to rebuild the page state. We need better javascript frameworks that can take care of these details for web apps.

Share this post


Link to post
Share on other sites

Ok I changed my mind and I'm going to tell you what to do as well.

If you just want a simple REST based app to return some JSON, why not, you know, go with the J from JSON.


Node.js is the current sexy, ( it used to be RoR, but that's like sooo 2012 now... ), it's well support, easily deployed and is about the easiest way on earth to serve JSON. Using Express, you can self host an HTTP server in a few lines of code and you could do what you are talking about in about 20 lines total.

The downside is callback hell... You'll see. smile.png. Thinking asynchronously takes a bit of brain bending.

Oh yeah, and it's not @&$:)ing PHP. I've actually done a few kinda tutorials using NOde.js if you are interested.

 

This.

 

Sounds like you haven't done much web dev in the past (I was in your same situation before). For a web app, you have two different parts of your app: back-end and front-end. HTML,CSS,JavaScript (traditionally), that's all front-end. It's what the browser directly interacts with/displays. This is how you make everything look pretty. When you want to start working with databases, server-side things, etc. you need the back-end solution. The first/most common way to do this used to be PHP, but PHP sucks and is going out of style, so as others said, don't learn it.

 

Now, there are basically two options for back-end. There's Ruby on Rails and Node.js. However, these two are kind of like comparing apples and oranges. Ruby on Rails (well, the "Rails" part) is a complete, opinionated (this means that your development practices, conventions, etc. are set up for you) framework for back-end web development. This means it provides you with a lot of "sensible" (no, really, they are) presets and tools to get you started. (Ruby is the programming language it is built on, which is one of the important things about it.)

 

Node.js is just a platform built on Chrome's JavaScript runtime for easily building network applications. It is just the bare bones. In order to compare it to Rails, you must add on several other things to form a framework "stack." Popular ones include Sails, Meteor, and some others but my personal choice for Node would be MEAN.io for various reasons. This is really based on what you like and what you want to do.

 

So, which to choose? Rails is more mature, has more robust addons/plugins and resources, but is somewhat less scalable (this doesn't affect until you get REALLY big) and is opinionated which could be a good or bad thing. Node is slightly faster, more scalable (again, only affects when you get REALLY big) and more customizable, but is less mature and doesn't have as good of resources and is harder to get set up (the tradeoff of having more customizability). It's considered the "cutting edge" and more and more people are migrating to it, but it's still quite young and Rails is still going strong.

 

I think the biggest deciding factor right now (in my opinion) is the language you use. Node is nice for some because it uses JavaScript which is the same language that you will be using for front end development. However, I personally don't like JS too much and would much rather use Ruby & CoffeScript (which compiles into JS so you still need to know it but that's a whole different conversation). Coming from your background (which was somewhat similar to mine) I think Ruby might "click" better. I really think Ruby is a joy to use, but you're free to make your own judgement, obviously.

Edited by termhn

Share this post


Link to post
Share on other sites

Most concerns in this thread can be solved with current technologies.

 

because you don't want to have to connect every time you want to run the app?

 

 

http://en.wikipedia.org/wiki/Cache_manifest_in_HTML5

http://caniuse.com/#feat=offline-apps

 

JavaScript is a non-typed language

 

 

http://en.wikipedia.org/wiki/TypeScript

 

 

 

You cannot bookmark, or at least bookmark easily. Back button is broken

 

http://diveintohtml5.info/history.html

http://caniuse.com/#feat=history

 

 

Developing web apps is still somewhat tedious. But the tools are becoming better and browser support for new features is becoming more widespread.

The big advantage is that you host your application in a central place and you can push updates automatically to any user.

 

I'd say, go for it.

 

As a C++ programmer you will probably need some time to adjust your way of thinking to this new environment. (I know, I did)

But once you have figured out how things work you will have a blast.

You will have a hard time though if you must support old browsers.

 

 

As for PHP:

 

"I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way."

 

- Rasmus Lerdorf, Founder of the PHP language

Share this post


Link to post
Share on other sites

 

"I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way."

 

- Rasmus Lerdorf, Founder of the PHP language

 

 

 

This can't be real, right? blink.png

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this