Building web sites



  • I've never made a website before (well, except for a website for my mom's dog kennel back in middle school (Frontpage)).  I have a bunch of photos that I want to put on a website in a kind of gallery.  I know I could use any number of places that offer this kind of service, but I want to learn how to build web pages, so this is a good first project I think.  

     So the question is, what tools would you guys suggest I start with to help me build the website.  I am very knowledgable with Perl, but obviously not the web aspects of it.  I'm thinking I'll either build the site with Perl or .NET, but I just don't know how to go about setting up the layout and all that shit.

     Is there another language you guys would recommend I learn (Ruby maybe?).   I'll probably start adding features to the website after I get it up (comments, ratings, dynamic upload, etc.).




  • Well I would say PHP, but i'm biased like that. Besides all the things people can mention why it sucks, it actually works really well and is easy to learn. PHP 5.3 even got released recently which added GOTO  ( and namespaces.but goto is much more important).

    If you already know perl you might want to look at mod_parrot. it's the apache module for perl. (of course you can use cgi-bin stuff, but that's not very modern anymore. )

    If you've never done anything web, the biggest difference to know about is 'state'. We don't have it. Each and every request is as new and exciting as the last one.



  • @stratos said:

    If you've never done anything web, the biggest difference to know about is 'state'. We don't have it. Each and every request is as new and exciting as the last one.

     

    I think there is such a thing as a "session."  no?



  • Well I myself would recommend Asp.Net/C# 2.0 as a good start off. But it all depends on how much you know of the basic technologies involved: xhtml, css, js sql, etc... And I don't mean the basics of the basics but the reality behind div vs tables,using js without breaking the site for non-js users, css pattern matching and selector syntax. I'm not great when it comes to the presentation layer myself so I usually get a static prototype working before beginning any business logic. This also helps with visualizing what you actually need to get working dynamically instead of jumping the gun and going all enterprisey with too much dynamic workings going on.

    If your interested in going the Asp.Net route, C# is very easy to learn, especially if your familiar with the basics of c++. Asp.Net is even easier to learn after that. I would warn you that if you wish to learn to do this correctly there is an awful lot of reading to do just to get much of the basics. I've gone through Profession C# 3rd edition, Asp.Net 2.0 Wrox Box ( 6k pages in total, probably a bit overkill for just getting a simple gallery up and running ). I've also heard from others that Total Training has a DVD out with a good kick start into Asp.Net, this maybe all you need to get started but I haven't seen this myself so I can't propperly comment.



  • @tster said:

    @stratos said:
    If you've never done anything web, the biggest difference to know about is 'state'. We don't have it. Each and every request is as new and exciting as the last one.
    I think there is such a thing as a "session."  no?
    Totally, and the session is simple enough to create and access in all languages I've used.  They require the client to have cookies enabled, but these days, not having cookies enabled is like not having javascript enabled.



  • @Hitsuji said:

    Well I myself would recommend Asp.Net/C# 2.0 as a good start off. But it all depends on how much you know of the basic technologies involved: xhtml, css, js sql, etc...

     

    I know .NET (C#), SQL.  I sort of know JS.  I know a little about HTML.  I know shit about xhtml, css.  

    I'm going to skip JS and CSS at least for the initial version. Maybe I'll put in some JS later if I feel like I need it.  Is CSS something that I can retrofit into an existing site, or does it pretty much have to be designed with it from the beginning?

     



  • @tster said:

    I'm going to skip JS and CSS at least for the initial version. Maybe I'll put in some JS later if I feel like I need it.  Is CSS something that I can retrofit into an existing site, or does it pretty much have to be designed with it from the beginning?

    Depending on how you build it, you could easily wind up having to rewrite the HTML to support CSS (Especially if you did an oldschool-style table layout). Plus coding in XHTML/CSS is much easier than oldschool HTML so I'd seriously recommend giving it a go right off the bat. Really as far as CSS goes to make 99% of sites you only need to know a small subset of CSS. So long as you understand float, padding, margin, background, some ofthe font stuff and the different behaviour of inline (eg: span) and block (eg: div) elements you can go a long way without anything else.

    Just in case you don't have it btw, I highly recommend getting firebug addon for firefox, makes bug-fixing in HTML tons easier.

    As far as the back-end language, it's largely personal opinion. I'd base the choice off what you know and what your hosting is (If it's a pure MS system with MSSQL database etc I'd definitely go the .NET approach, if you're looking more at a linux/apache style setup then there's a fair bit of overhead to getting mono etc working so I'd steer clear and lean more to the perl/php options).



  • @stratos said:

    PHP 5.3 even got released recently which added GOTO  ( and namespaces.but goto is much more important).

    Are you serious? I don't really know any PHP so I can't tell if you're joking. Is PHP so fucked up that adding goto is actually an improvement? Wouldn't it be more sane to add better structured flow control statements so that goto is not necessary?


  • Discourse touched me in a no-no place

    @gremlin said:

    Wouldn't it be more sane to add better structured flow control statements so that goto is not necessary?
    Depends. http://kerneltrap.org/node/553/2131



  • @gremlin said:

    Is PHP so fucked up that adding goto is actually an improvement?
    I can't think of any PHP code I've written or seen that could be improved through liberal use of GOTO.

    @gremlin said:

    Wouldn't it be more sane to add better structured flow control statements so that goto is not necessary?
    It's not necessary, but they're giving noob programmers another tool which which to dig their own grave, I guess.  

    With the addition of GOTO to PHP, Swampy can finally make that mashup he's always dreamed of.



  • @gremlin said:

    @stratos said:

    PHP 5.3 even got released recently which added GOTO  ( and namespaces.but goto is much more important).

    Are you serious? I don't really know any PHP so I can't tell if you're joking. Is PHP so fucked up that adding goto is actually an improvement? Wouldn't it be more sane to add better structured flow control statements so that goto is not necessary?

     

    I'm not joking, goto was added http://nl2.php.net/goto

    However it certainly wasn't the big improvement everyone was waiting on, there are far more interesting things to 5.3 then that, like for instance the namespaces i've mentioned. I don't follow the php developers mailinglists so I am not sure why goto got added, but i'm sure there is a 1000+ post flamewar about it on the lists. It got implemented in the most sane way you can implement goto though. Personally I've never needed it in any language besides pascal in school or something, but I am convinced there was a reasonable reason to include it.

    Besides, we won't see bad php code written with goto's for another few years and before that time people are managing to write bad php code just fine with the current stuff, so meh.



  • @belgariontheking said:

    @gremlin said:
    Is PHP so fucked up that adding goto is actually an improvement?
    I can't think of any PHP code I've written or seen that could be improved through liberal use of GOTO.
    Liberal use of goto is likely not going to be an improvement, as SSDS demonstrates.  If statetments, loops, break, and continue are all expressive forms of goto, so I'd favor them over goto whenever reasonable.   But proper use of gotos can avoid a great deal of arrow code.



  • @belgariontheking said:

    @tster said:

    @stratos said:
    If you've never done anything web, the biggest difference to know about is 'state'. We don't have it. Each and every request is as new and exciting as the last one.
    I think there is such a thing as a "session."  no?
    Totally, and the session is simple enough to create and access in all languages I've used.  They require the client to have cookies enabled, but these days, not having cookies enabled is like not having javascript enabled.

    Excuse me while I have a rant now.

    The whole 'state thing' really shits me.  On one hand, we have "oooh - it's uber-scalable because it's stateless".  On the other hand, you cannot do anything useful without state!!!.  So what we've ended up with is something that should be scalable (and may well be) but is actually unnecessarily hard to do so properly.  When we do get state of any significance it's nothing more than a big, fuck-off bucket of stuff with no context.  You have to manage it like global variables back in the good old days.  To boot, in some cases every bit of state is treated like a string or other typeless object no matter what it actually is.  It really is completely fucked up because most state management is a complete shithouse compromise of either stateless or stateful whichever perspective you are coming from.  Throw this lot at a bunch of typically sub-standard developers [citation - thedailywtf.com] who don't even understand the basics, throw in some SQL injection, some stupid, cheap management and I'm surprised how much does actually work.

    /rant (sort of)



  • @LoztInSpace said:

    Excuse me while I have a rant now.

    The whole 'state thing' really shits me.  On one hand, we have "oooh - it's uber-scalable because it's stateless".  On the other hand, you cannot do anything useful without state!!!.  So what we've ended up with is something that should be scalable (and may well be) but is actually unnecessarily hard to do so properly.  When we do get state of any significance it's nothing more than a big, fuck-off bucket of stuff with no context.  You have to manage it like global variables back in the good old days.  To boot, in some cases every bit of state is treated like a string or other typeless object no matter what it actually is.  It really is completely fucked up because most state management is a complete shithouse compromise of either stateless or stateful whichever perspective you are coming from.  Throw this lot at a bunch of typically sub-standard developers [citation - thedailywtf.com] who don't even understand the basics, throw in some SQL injection, some stupid, cheap management and I'm surprised how much does actually work.

    /rant (sort of)

     

    yes, umm rant, sure, but don't go projecting your (assumed) inabilities  on the rest of us. When you are developing for web you should know when to use use state (via cookies or sessions) and when to keep it stateless. This isn't magic and this isn't hard, it also certainly doesn't contribute to it being "fucked up".  I'm also pretty sure that you can throw anything to bad developers and they have the ability to make it worse.

     

    @LoztInSpace said:

    "you cannot do anything useful without state!!!."

    Except of course almost everything. Every picture you request from a website is stateless, css stateless, js files stateless. REST based API's  also do indeed scale extreemly well because they are stateless and leverage this fact with HTTP to making caching strategies easy to implement.

     




  • @LoztInSpace said:

    Excuse me while I have a rant now.
    Hear Hear.@LoztInSpace said:
    big, fuck-off bucket
    Bonus points for reminding me of Eddie Izzard, the only other person I've ever heard use that phrase:

    @Eddie Izzard said:

    Everyone had beards, big fuck-off beards in the Old Testament.



  • @stratos said:

    Except of course almost everything. Every picture you request from a website is stateless, css stateless, js files stateless. REST based API's  also do indeed scale extreemly well because they are stateless and leverage this fact with HTTP to making caching strategies easy to implement.

    If you're only talking about pictures and styling then we have different ideas of what makes a useful app.  Of course these things are stateless but they contribute nothing to the overall function if they are simply served up without reference to the context (which to be fair is often the case, but this is not what I am talking about - the difference between a web application and a web site).

    I know what you mean about the restful thing though and for simple cases it can work.  I have never seen a decent session that combines state with context, strong typing and state integrty.



  •  @LoztInSpace said:

    @stratos said:

    Except of course almost everything. Every picture you request from a website is stateless, css stateless, js files stateless. REST based API's  also do indeed scale extreemly well because they are stateless and leverage this fact with HTTP to making caching strategies easy to implement.

    If you're only talking about pictures and styling then we have different ideas of what makes a useful app.  Of course these things are stateless but they contribute nothing to the overall function if they are simply served up without reference to the context (which to be fair is often the case, but this is not what I am talking about - the difference between a web application and a web site).

    I know what you mean about the restful thing though and for simple cases it can work.  I have never seen a decent session that combines state with context, strong typing and state integrty.

    <another useless rant>

    I think one of the underlying problems of all this is, that too many people forgot what HTTP was originally designed for. After all, it stands for "Hypertext transfer protocol". Retrieval of static documents - URL in, stuff out. And it really excels at that, with the whole caching infrastructure and content negiotation framework. Ok, then came POST, but if we only look at simple query-response operations, thaere is not that much difference.

    Basically, I think, what HTTP is really useful for is getting static documents and doing dynamic processing where you just need to fill ot ONE form, press return and get the response back.

    Contrast that with todays "Web 2.0" usage, where a lot of really clever people developed many sophisticated hacks that give HTTP almost all the features of an only modestly broken TCP implementation - on top of TCP. That set of hacks - among many other things - is then subsequently called "the next step in the evolution of computer science".

    I mean, of course ajax is cool and everything, but I think for the complex interactions of many of todays web applications, we really need a protocol which has actual state instead of bending HTTP even after it broke.

     



  • @LoztInSpace said:

    @stratos said:

    Except of course almost everything. Every picture you request from a website is stateless, css stateless, js files stateless. REST based API's  also do indeed scale extreemly well because they are stateless and leverage this fact with HTTP to making caching strategies easy to implement.

    If you're only talking about pictures and styling then we have different ideas of what makes a useful app.  Of course these things are stateless but they contribute nothing to the overall function if they are simply served up without reference to the context (which to be fair is often the case, but this is not what I am talking about - the difference between a web application and a web site).

    I know what you mean about the restful thing though and for simple cases it can work.  I have never seen a decent session that combines state with context, strong typing and state integrty.

     

    Indeed we do have a different idea of what makes a useful app. I'm uncertain how you even come to the conclusion that they somehow are not part of an application. Sure there are applications that don't have a human interface and for those having pictures and markup are not all that important. However many web applications do get used by humans, and humans tend to be appreciative of a good interface. Which doesn't necessarily mean WEB 2.0, JS rich AJAX filled RIA stuff. A few pictures some HTML/CSS will be fine in most cases. Also there really isn't a difference between a web app and a web site. It's just some silly classification we slap on arbitrarily. 

    Also the whole trick to REST is to make it simple, that's actually the tricky part about it. 

    It is also not weird that you've never seen a application that tries to store both state and context of a request, it would be an abomination that needs to be cleansed with fire. HTTP is stateless, your browser expects it to be, we can retain state data in sessions, and like I said I am pretty sure there are solutions out there that let you store complex types. But storing context is insane, I can't even envision that working without some bootstrap procedure that actually handles the http request. It will also break just about everything about the browser, the back button really doesn't care that you are trying to retain some sort of context. 

    If you want an application that retains state and context, use javascript, flash, silverlight or flex or whatever and push HTTP back down the line. But for server side it is just folly.

    --edit-

    @PSWorx said:

    <another useless rant>

    I think one of the underlying problems of all this is, that too many people forgot what HTTP was originally designed for. After all, it stands for "Hypertext transfer protocol". Retrieval of static documents - URL in, stuff out. And it really excels at that, with the whole caching infrastructure and content negiotation framework. Ok, then came POST, but if we only look at simple query-response operations, thaere is not that much difference.

    Basically, I think, what HTTP is really useful for is getting static documents and doing dynamic processing where you just need to fill ot ONE form, press return and get the response back.

    Contrast that with todays "Web 2.0" usage, where a lot of really clever people developed many sophisticated hacks that give HTTP almost all the features of an only modestly broken TCP implementation - on top of TCP. That set of hacks - among many other things - is then subsequently called "the next step in the evolution of computer science".

    I mean, of course ajax is cool and everything, but I think for the complex interactions of many of todays web applications, we really need a protocol which has actual state instead of bending HTTP even after it broke.

     

    Less disagreeable this time :P I actually agree with you for the most part. But i don't see ajax as 'hacks' around the limitations of HTTP. When used correctly it just pulls a piece of your application to the client side. Nothing inherintly wrong with that, you just have to watch your step and be careful not to go overboard and be careful as not to break the browser (as in back button/history/etc..).

    Stuff like gmail/google calander or even lesser known applications out there that let you draw stuff. They all put those dynamic interactions into the client side, because HTTP simply doesn't allow one to do that. However, after that, they use HTTP to get/store/update/delete the created or modified "entities". Which of course is, as you pointed out, just what HTTP is good at. 

    We don't need a new protocoll, wat we need is better education for webdevelopers on HTTP. What it can and can't do, and why stuff like javascript and other client side languages actually exist and how to use those to create the complex interactions we sometimes want. Also it wouldn't hurt if browsers actually implemented ALL the HTTP actions, instead of just GET and POST.

    Of course I won't say there are no abominations to man out there, there are massive amounts of developers who don't get it who create the most horrible applications known to man. But I dare to say that is surely not just a web thing, it's just that they are far more easier to find on the web.

     



  • For some reason I can hear violins softly crescendoing in the background of the seond part of Stratos' post; while the camera slowly zooms out to reveal a grand panorama.



  • @stratos said:

    If you already know perl you might want to look at mod_parrot. it's the apache module for perl. (of course you can use cgi-bin stuff, but that's not very modern anymore. )

    For those using Perl6, mod_parrot's the way to go.  On the other hand, many people still use perl5, which still uses mod_perl.  There's also a host of templating systems and other useful software for mod_perl.



  • @PSWorx said:

     @LoztInSpace said:

    @stratos said:

    Except of course almost everything. Every picture you request from a website is stateless, css stateless, js files stateless. REST based API's  also do indeed scale extreemly well because they are stateless and leverage this fact with HTTP to making caching strategies easy to implement.

    If you're only talking about pictures and styling then we have different ideas of what makes a useful app.  Of course these things are stateless but they contribute nothing to the overall function if they are simply served up without reference to the context (which to be fair is often the case, but this is not what I am talking about - the difference between a web application and a web site).

    I know what you mean about the restful thing though and for simple cases it can work.  I have never seen a decent session that combines state with context, strong typing and state integrty.

    <another useless rant>

    I think one of the underlying problems of all this is, that too many people forgot what HTTP was originally designed for. After all, it stands for "Hypertext transfer protocol". Retrieval of static documents - URL in, stuff out. And it really excels at that, with the whole caching infrastructure and content negiotation framework. Ok, then came POST, but if we only look at simple query-response operations, thaere is not that much difference.

    Basically, I think, what HTTP is really useful for is getting static documents and doing dynamic processing where you just need to fill ot ONE form, press return and get the response back.

    Contrast that with todays "Web 2.0" usage, where a lot of really clever people developed many sophisticated hacks that give HTTP almost all the features of an only modestly broken TCP implementation - on top of TCP. That set of hacks - among many other things - is then subsequently called "the next step in the evolution of computer science".

    I mean, of course ajax is cool and everything, but I think for the complex interactions of many of todays web applications, we really need a protocol which has actual state instead of bending HTTP even after it broke.

     

    Very similar views to my own.  I wish I could be arsed to do something about it or had the influence to make it worth having a crack at something better that might be widely adopted.



  • @belgariontheking said:

    @tster said:

    @stratos said:
    If you've never done anything web, the biggest difference to know about is 'state'. We don't have it. Each and every request is as new and exciting as the last one.
    I think there is such a thing as a "session."  no?
    Totally, and the session is simple enough to create and access in all languages I've used.  They require the client to have cookies enabled, but these days, not having cookies enabled is like not having javascript enabled.

     

     "Session" and "State" are not really the same thing at all.  I'll give you an example.

     Say you have an application where you will open two windows or the same type, one for Person A's information and one for Person B's information.  If you are doing so in a standard application, you would generally maintain those two objects independently, each would have its own state.  If you were to do the same thing in a web page, you would use the session to store information... but that's shared.  To handle each window independently, you would need to store some kind of indentfier for each page in the session.  The difference is that your state isn't connected to the object it is controlling, you have no way of knowing when the page closes, so you keep that "state" information in memory.  In a large application, this is a bad thing... I am working on a portal where the "state" for a single page of data can run to several megabytes and we expect users to open a minimum of 20 pages in a session.  This quickly becomes untenable.

    Interestingly enough, ASP.NET tries to solve this issue by storing the state in a hidden field in the it returns to the server. Needless to say, this doesn't quite do it for us either. The only way our application works is by regenerating the data each time, precisely because we cannot manage state.


Log in to reply