Web App Development?

Started by
17 comments, last by JonathanLyons 9 years, 6 months ago


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.

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

Advertisement

Cheers for the advice all, much appreciated.

Stumbled across this article during my travels - http://www.leonardteo.com/2012/07/ruby-on-rails-vs-php-the-good-the-bad/

Was a good read and led me to have a mess around with PHP. Looking alright so far; good fun too!

BSc Computer Games Programming (De Montfort University) Graduate

Worked on Angry Birds Go! at Exient Ltd

Co-founder of Stormburst Studios

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.
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.
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.

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.

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.

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

"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

This topic is closed to new replies.

Advertisement