Learning web development


  • Winner of the 2016 Presidential Election

    I'm sort-of casually looking around for new jobs at the moment, and it seems like everything that's not either an unacceptably long commute or a drop in pay is a web job (asp.net, since I'm mostly looking for C# type roles). So far in my career I've done mostly application development and API type work, because whenever I've dipped my toe in web technologies they seem messy and unintuitive. Starting a webAPI project in Visual Studio gives you multiple folders full of files in various different languages and it's a bit overwhelming

    As a result, I don't really know the first thing about web dev, which technologies are worth learning and which are dead/useless, where to go for learning resources, etc. Any advice welcome, or tell me to fuck off back to desktop apps


  • sockdevs

    The latest trends to appear to be a mix of ASP.NET MVC (which shouldn't faze an app dev), Web API, and whatever the JS API flavour of the day is (Angular seems to be a big one at the moment, but you'll also see Bootstrap, Ember, et al).

    End of the day though, I'd give the same advice as I'd give someone looking into app dev roles; don't be afraid to learn new things. Be flexible and adaptable, and you should be fine ;)



  • I don't really want to get into the merits / demerits of various Web Technologies - not on this forum anyway :stuck_out_tongue:

    I would suggest a middle ground - find a web dev role that has a C type backend (there are some out there and it is not my place to comment on them) and then you can learn on the job without appearing too clueless.

    Also, learn some of the basics about HTML, CSS and JavaScript.

    Please don't use (unless it is your choice) IDE's etc to create Code and Projects - not just yet anyway. As it will totally overwhelm you as you have already experienced. I have found that even with the best of them, a good understanding of what is happening under the hood, can be critical / useful.

    Lastly: Try W3 Schools for simple clear and good tuition (no, I have no connection with them. I have been and still use them as a reference / quick reminder source [that and the appropriate Stackoverflow])

    Oh, yeah. do little projects to get a feel for the code, as it can help you blagg your way through an interview :smiling_imp:



  • There are generally three types of web apps being developed in .NET these days.

    • ASP.NET WebForms
      This is a legacy technology, where they tried to make designing web apps similar to making Visual Basic Windows apps. Not bad for what it is, but requires a LOT of hacking once you are forced to go off the beaten path (and you will be). Can be useful for a quick intranet app, but I wouldn't waste any time learning this in 2015.

    • ASP.NET MVC
      The "main" MS web stack. This creates the sites that work in the standard client / server organization. Each page has templates (written in "razor" language) that are compiled (converted to html) on the server and served with CSS and js that will be executed on current page.

      If you create a new MVC project, you'll see a TON of files, which can be somewhat intimidating at first. But it also allows you to just start changing the existing setup and learn from there. So it could be a good place to start experimenting. If you want a quick no-nonsense intro, I suggest ASPNET MVC Succinctly. It's free.

    • ASP.NET Web API
      This is the new MS web stack, meant to be used as a backend for "single page applications". These apps don't load their pages from server (no "razor"), but generate all the pages in browser. The server is used strictly to serve the initial empty page + a TON of javascripts, and then to provide data through REST methods.

    <!-- -->

    Since these apps have a ton of code that needs to be delivered in one package to the client, you'll usually see some kind of "build system" employed on the server. An utility like "grunt" or "gulp" takes a bunch separate javascript, less or sass files etc. and packages them into a few huge minimized files that can be efficiently served to the client. MVC also does this for "less" templates (if you use them), but it's more integrated into the Visual Studio and you don't have to worry too much about it.

    <!-- -->

    I'm not sure what MS put in their default project template, but I guess a lot of it is just tooling to do this server-side "build" phase. However, you don't need all this to learn an "single-page application" (SPA) framework. Since this is all just standard javascript, you'll usually just start hacking in a single html page, and then tackle a build system and REST backend once you're more comfortable with the idea.

    <!-- -->

    For an overview of javascript SPA frameworks, see here: https://what.thedailywtf.com/t/what-js-mvc-library-is-least-full-of-bullshit/5335/47

    Both MVC and WebAPI are legit technologies to learn. But to dig into either one, you first need to the basics of html, css and javascript. So that's what I suggest you do first.

    Once you get the fundamentals, you'll be better prepared to get into MS specific web stacks.


  • Winner of the 2016 Presidential Election

    @cartman82 said:

    you first need to the basics of html, css and javascript

    I know the very basics of HTML, to the point of being able to build a static webpage. What little I did on that was well before HTML5, so even if I had learned anything more advanced it probably wouldn't be relevant now.

    CSS is firmly in the "magic" pot at the moment. I've played around with Stylish a little bit but mostly copypasta of what other peple have written.

    Javascript I know a bit, but tend to get frustrated whenever I encounter some of its idiosyncrasies.

    @loose said:

    Try W3 Schools for simple clear and good tuition

    I'm sure I'd heard somewhere that W3Schools has a lot of misleading or just plain wrong information. This was a while back, so maybe they've cleaned it up now.

    I guess I need to do the same as I did when getting into C# desktop development: decide on a suitable toy project and do it. I always get bored just running through tutorials, and rarely get much past Hello World



  • If you really understand REST APIs, you could just create one yourself in a couple of .ashx files.

    The Visual Studio WebAPI project, well. They implement a REST API. Kind of. But also a whole lot of shit you don't need or want. And their REST API has severe limitations you wouldn't have if you rolled your own.

    (For example, some features, like auto-hydrate and multipart/form-data file uploads are mutually-incompatible for... uh... reasons? Also if you receive a JSON array, the array has to be all the same type or WebAPI throws a huge howling fit about it. Even though that's perfectly valid REST and perfectly valid JSON.)

    Anyway, point is: I'm not too impressed with WebAPI. WCF is somehow even worse.

    But yeah, the advice is: just sell yourself as a C# back-end/database programmer and try to keep hands-off the front-end JS mess. That's what I'm doing now, and I'm pretty happy about it. Except my commute is unacceptably long. Which is why I'm typing this at 5:26 AM.



  • @Jaloopa said:

    Javascript I know a bit, but tend to get frustrated whenever I encounter some of its idiosyncrasies.

    ... really? Hm.

    I think JavaScript's a pretty damned small, clean, language. Small enough to fit in my head all at one time so I can dedicate my neurons to solving the problem instead of remembering bullshit about the language. The quirks it has are pretty few and far-between, not something I run into often.


  • Winner of the 2016 Presidential Election

    I probably meant DOM, not Javascript :trollface:

    @blakeyrat said:

    the advice is: just sell yourself as a C# back-end/database programmer and try to keep hands-off the front-end JS mess.

    I think that's probably the way to go TBH. I'm quite happy doing back end stuff, and the tech seems a lot more stable than front-end web weirdly named framework of the week



  • @Jaloopa said:

    I know the very basics of HTML, to the point of being able to build a static webpage. What little I did on that was well before HTML5, so even if I had learned anything more advanced it probably wouldn't be relevant now.

    CSS is firmly in the "magic" pot at the moment. I've played around with Stylish a little bit but mostly copypasta of what other peple have written.

    I looked around for something that's beginner level, but doesn't waste your time explaining "this a mouse and this is an icon, and if you press button... etc.".

    This seems pretty brisk and informative: http://learn.shayhowe.com/html-css/building-your-first-web-page/

    @Jaloopa said:

    Javascript I know a bit, but tend to get frustrated whenever I encounter some of its idiosyncrasies.

    This seems pretty quick and to the point: https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript

    Also, MDN is your new best friend, it's a great site for all things javascript.

    I bet you can get decent at this frontend shit in a week or so, it's not too hard.



  • @Jaloopa said:

    I think that's probably the way to go TBH. I'm quite happy doing back end stuff, and the tech seems a lot more stable than front-end web weirdly named framework of the week

    Just fair warning: the best framework out there for back-end REST APIs in C# is WebAPI, and if you're like me, it's gonna piss you off because of all the arbitrary limitations it has. Shockingly, it's also been open sourced. Which probably explains why the latest version is kind of shitty and bad at solving problems. Anyway, you probably won't get a choice to choose your own libraries when you work for someone else, so. WebAPI it is. Ugh.

    And don't worry about CSS, nobody understands CSS. You just need to be able to bullshit past it. (Say stuff like, "we need to increase the specificity of these selectors" and you'll sound like a genius.)



  • @blakeyrat said:

    Say stuff like, "we need to increase the specificity of these selectors" and you'll sound like a genius.

    Hey wait... hmm... but, you mean... ah I see! So that's why my classes were clashing!

    You're a genius, Blakey!



  • @loose said:

    Lastly: Try W3 Schools for simple clear and good tuition (no, I have no connection with them. I have been and still use them as a reference / quick reminder source [that and the appropriate Stackoverflow])

    I've read that they might be better than they once was, but W3Schools is the last place you should be pushing people to learn stuff.



  • @Jaloopa said:

    I'm quite happy doing back end stuff, and the tech seems a lot more stable than front-end web weirdly named framework of the week

    Back end stuff you're generally working on something interesting that isn't working around browser / framework weirdnesses. Of course, I like working around DB weirdness, personally, so maybe I'm biased.



  • @blakeyrat said:

    "we need to increase the specifity of those selector"

    .article.article.article //wouldn't work otherwise
    {
    

    I actually had to do this thing once. The alternative was breaking JQueryUI open.

    I agree with the sentiment towards CSS, but it's still gonna be beneficial to at least know enough of web dev not to throw your hands up when you need to debug something breaking.



  • I recently stumbled across CCSS (and implementation called GSS) - speaks to me more clearly than CSS.

    Basically it's using constraints and an algorithm to determine what should go where. The constraints' importance is determined by order and four optional keywords (!weak, !medium, !strong and !required).

    Example: You have two div boxes, not very practical but shows how it works

    #box1[width] == 200;
    #box1[width] == #box2[width]
    #box1[width] + #box2[width] <= 300;
    

    This will result in two boxes with both of an equal width of 150 - last constraint is most important and thus wins over constraint 1.

    #box1[width] == 200 !strong;
    #box1[width] == #box2[width]
    #box1[width] + #box2[width] <= 300;
    

    First box is 200 wide, second one is 100 wide. First constraint is most important, then comes the third - thus the middle constraint loses

    #box1[width] == 200;
    #box1[width] == #box2[width]
    #box1[width] + #box2[width] <= 300 !weak;
    

    Two boxes with 200 width each.

    I find this approach more pleasing than CSS - plus stuff like Grids is much more easy.

    This here would divide the whole screen into four equally sized boxes:

    "area1...4" {
      width: == ::window[width]/2;
      height: == ::window[height]/2;
    }
    "area1", "area3" {
      left: == 0;
    }
    "area1...2" {
      top: == 0;
      right: == &:next[left];
    }
    "area3...4" {
       top: == "area1"[height]
       right: == &:next[left];
    }
    

    And if an element should go into the first area,simply do:

    #box[left] == "area1"[left];
    #box[top] == "area1"[top];


  • @cartman82 said:

    I bet you can get decent at this frontend shit in a week or so, it's not too hard.

    You can probably expect someone to produce something working, but it won't be decent. And $deity$ help you if you actually expect anyone with less than a year's worth of experience to produce anything good without keeping them on the beaten path of existing CSS or JS frameworks and their tutorials or without continued guidance.

    Venture outside the beaten paths and there are suddenly so many oddities you need to balance with regards to both the CSS and DOM APIs themselves and the quirks and bugs of the various browser implementations that it has probably completely broken lesser men.



  • @blakeyrat said:

    And don't worry about CSS, nobody understands CSS. You just need to be able to bullshit past it. (Say stuff like, "we need to increase the specificity of these selectors" and you'll sound like a genius.)

    CSS selectors and most of the properties themselves actually aren't that hard to understand or keep in check.

    It's when nutjobs that don't know what they're doing start plowing through a nicely organized CSS codebase that nightmares start, because as part of the openness of how you can write rules and how specificity can be abused, shit will quickly snowball out of control to produce even greater shit to the point where you can only 'fix' things within a reasonable timeframe by piling on even more shit.

    If I'd be interviewing and your answer to an interview problem would be to increase the specificity of a set of selectors, you'd better have a damn good argument for wanting to do so, because it'd be almost exclusively the wrong answer.

    Keep selectors shallow. Componentize. Assemble small components to achieve bigger ones. Keep layout and structural components strictly separate from content or content components. (That also means avoiding dependencies such as a content component 'knowing' about physical dimensions of a layout component.)

    Basically: with great power comes great responsibility, and even greater footguns.



  • @blakeyrat said:

    And don't worry about CSS, nobody understands CSS. You just need to be able to bullshit past it.

    One of these days, I was going to sit down and try to learn the particulars. Thanks for saving me some time.



  • @Ragnax said:

    nicely organized CSS codebase

    Such things exist in the wild ?



  • @Ragnax said:

    footguns

    Now I get it. :laughing:



  • @Jarry said:

    Such things exist in the wild ?

    Well, no. Because it is "in the wild". However, there is some very domesticated and well behaved stuff nicely encapsulated within the confines of it's page (and I don't mean by means of inline styling and the like) around.

    Please don't ask for examples, because I am far too modest. :innocent:



  • Make sure you brush up on HTTP if you don't know it already. Symfony has a decent basic introduction, but I'm sure people will have other recommendations.



  • @Ragnax said:

    You can probably expect someone to produce something working, but it won't be decent.

    Yeah, I can cobble something together using my knowledge of HTML and Bootstrap, and while it'll function alright (as alright as you're willing to expect out of an app that doesn't do a whit of AJAX ;)), I make no guarantees as to prettiness.


  • sockdevs

    @tarunik said:

    I make no guarantees as to prettiness.

    Spoken like a true developer :laughing:


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.