Web Programming vs Desktop Programming

[cwblanch]

First I want to apologize if I used Desktop Programming wrong. That's just how I've read it referred to.

I know there are probably a ton of posts in various places about this, but I just want peoples opinions about it.

I've been teaching myself programming, python specifically, but I've found a site that teaches web programming. And the site is teamtreehouse. I've read a bit about it and it seems good. But I want to know if I learn web programming will I further my general knowledge about programming? Because I've read that learning one language will make the next one easier to grasp.
But I've also read that web programming, HTML and CSS for example, isn't actual programming and won't do anything for programming knowledge.
BUT JavaScript is a web language that is applicable. I don't know!

OR should I learn both at the same time?? I've also read people saying that you shouldn't learn more than one at the same time.

I'm sorry about the rambling questions, but this is what comes of reading tons of posts about these topics and not knowing where to go with it.

Thank you!

[ofnuts]

Writing HTML/CSS is a form of programming. You have to produce text and make sure the computer understands it correctly to execute what you want it to do. Like in more "standard" programming, there are several ways to achieve the results, but some a more efficient/maintainable that others.

Spreadsheets and word processors are also a form of programming (even if the computer under M$ control can sometimes behave like a raving psycho instead of a gentle and logically-minded machine).

[SeijiSensei]

Web programming often means building applications that rely on server-side processing, typically in conjunction with an SQL database. This site is written in PHP and uses such a database, probably MySQL. HTML is a "markup language," with embedded codes to create links, add italics, etc. CSS is a method to create a stylesheet that attaches particular attributes to HTML tags.

You can view the HTML "source code" for rendered pages in most browsers. In Firefox, you right-click on the page and choose "View Source." Try that for this site. You'll see a "meta" tag in the header for this site that links to this CSS stylesheet.

Web programming is much more limited than programming in general, because you are constrained to use a browser as the application's interface. However you can still write scripts in PHP that can be run the command line, just like any other programming language. I write such scripts from time to time because I am very familiar with the language, and because PHP has a lot of built-in functions for complex tasks like managing connections to an IMAP mail server.

[Lars Noodén]

Also, web services are stateless. Each time a link is selected, a new connection is made afresh. On the server side, your application has to do all kinds of tricks to pretend otherwise.

I'd give desktop programming a try first. Since you are using Python you could look at Qt or PyQt.

http://www.cs.usfca.edu/~afedosov/qttut/

[SeijiSensei]

Also, web services are stateless. Each time a link is selected, a new connection is made afresh. On the server side, your application has to do all kinds of tricks to pretend otherwise.

Well, really just one trick, using sessions. I can't remember the last time I developed a site that didn't use sessions to track users across pages.

[Lars Noodén]

Yes, there are of course libraries to handle sessions.

I had hoped however that HTTP 2 would be stateful, but it seems that control of the WWW has become too politically charged for technical discussions to percolate up in the overal plans.

[edouardtavinor]

Well, really just one trick, using sessions. I can't remember the last time I developed a site that didn't use sessions to track users across pages.

I feel I should mention a few things here.
1/ In europe using cookies to store a session id is illegal unless you ask for consent from the visitor.
2/ Don't worry about backend programming. Keep your data in flat files on the server and fetch it once. Then store it in the indexeddb in your browser.
3/ Don't use JavaScript. It's an unintuitive language that will bite you at some stage. Instead, have a look at Dart, for example.

Happy coding!

[SeijiSensei]

Just because the EU requires that you state that you use session cookies doesn't make them any less valuable. They are not the same as "tracking cookies" like the ones advertisers use. Session cookies only persist until they reach their expiration (typically four hours on sites I design) or you close your browser. They are designed to track a user while interacting with the site. It is not illegal to use cookies on sites hosted within the EU if the user is informed about them up front as, for instance, on the Economist home page.

As for storing data in a browser, I can't begin to think about how to do that nor would I want to. My sessions often contain a dozen or more PHP arrays, some quite large, along with a variety of other variables that contain information I only want to retrieve once from the database per session. Any site that uses logins like this one is going to be using session cookies as well. I count five such cookies for this site. I also use MD5 strings as session identifiers to make them impossible to guess. (The FTD florist site once used cookies identified by a simple incrementing integer. It made it possible to see other people's transactions simply by guessing a different number.) It is entirely possible to use session cookies and not violate user's privacy in any meaningful way.

[Vaphell]

I also use MD5 strings as session identifiers to make them impossible to guess. (The FTD florist site once used cookies identified by a simple incrementing integer. It made it possible to see other people's transactions simply by guessing a different number.)

flowers? that's nothing, i recall reading about the bank that had the same issue
That said, i hope your raw session ids are really long so they don't sit together with their hash in some rainbow table yet, 'md5' and 'impossible' in 1 sentence... that does not compute

[edouardtavinor]

Just because the EU requires that you state that you use session cookies doesn't make them any less valuable. They are not the same as "tracking cookies" like the ones advertisers use. Session cookies only persist until they reach their expiration (typically four hours on sites I design) or you close your browser. They are designed to track a user while interacting with the site. It is not illegal to use cookies on sites hosted within the EU if the user is informed about them up front as, for instance, on the Economist home page.

As for storing data in a browser, I can't begin to think about how to do that nor would I want to. My sessions often contain a dozen or more PHP arrays, some quite large, along with a variety of other variables that contain information I only want to retrieve once from the database per session. Any site that uses logins like this one is going to be using session cookies as well. I count five such cookies for this site. I also use MD5 strings as session identifiers to make them impossible to guess. (The FTD florist site once used cookies identified by a simple incrementing integer. It made it possible to see other people's transactions simply by guessing a different number.) It is entirely possible to use session cookies and not violate user's privacy in any meaningful way.

The difference between the intention of a session cookie and a tracking cookie makes no difference to the law. The law demands that you get the consent of the person visiting the site.

To store information in the browser, html5 offers 2 possibilities: local storage and an indexed database in the browser. This allows you to write complex applications which run in the browser without needing a server to do anything but deliver the information the first time you load it. You don't need a session, you don't need a database on the server, you don't need php. You just deliver html, css and javascript files, and the javacript file loads the data you need using ajax from flat files also stored on the server. After that the application can run offline without an internet connection, like gmail, google docs etc.

By the way, for those who insist on doing it the old way, the solution to setting cookies in the browser is to pass the sessionid as a parameter with every request.