Help me build my own mental model for front end web development
July 5, 2015 12:36 PM
A couple of months ago, I started an internship doing front end web development, an area of programming I had almost no experience in, for a small startup. I crammed in some basics beforehand, and I've learned a lot, piecemeal, on the job, but I feel my work is lacking because I don't have an unbroken foundation of theory for scaffolding. I've said as much to the big boss, and asked to take a week to just bone up on fundamentals, which he's generously granted. What resources should I be aware of?
I normally work 15 hours a week and spend 15 on my own projects, so I've got about 30 hours to do this. As I learn, I'd like to write up a document and/or build a flowchart that I hope will serve me as a consistent model for best practices in the future.
I'm aware of bento.io and this list of interview questions that might prove useful in identifying gaps, and there's a responsive web design course that covers some advanced CSS techniques that will be handy (I've found CSS particularly problematic). What else is there?
What's your mental model look like for this kind of dev?
I know not everyone is crazy about the learning-through-theory approach, but it works well for me.
I normally work 15 hours a week and spend 15 on my own projects, so I've got about 30 hours to do this. As I learn, I'd like to write up a document and/or build a flowchart that I hope will serve me as a consistent model for best practices in the future.
I'm aware of bento.io and this list of interview questions that might prove useful in identifying gaps, and there's a responsive web design course that covers some advanced CSS techniques that will be handy (I've found CSS particularly problematic). What else is there?
What's your mental model look like for this kind of dev?
I know not everyone is crazy about the learning-through-theory approach, but it works well for me.
cpounds list is pretty good. I would add a couple of things:
Learn the basics of setting up a web server on your local machine or in a cloud environment. Learn how to use SSH, and get at least a little bit familiar with the command line and Linux environment.
HTTP: you can pick up most of this along the way just by poking around with the tools, but it's good to know what a HTTP request looks like, and what the various requests are (GET, PUT, POST, DELETE, OPTIONS, etc). It's also helpful to have a good understanding of what the various headers are
REST: there is a convention in webdev for mapping HTTP requests onto operations on data. It gets quite complex, but the basics are relatively straightforward. Understanding RESTful resources and CRUD operations is very helpful for building APIs and interacting with them. The wikipedia page is a good place to start.
What is your basic level of programming knowledge outside of webdev? Total noob? Or some prior experience? Web dev can be tricky stuff to learn because there are so many interacting technology layers.
posted by arxeef at 1:31 PM on July 5, 2015
Learn the basics of setting up a web server on your local machine or in a cloud environment. Learn how to use SSH, and get at least a little bit familiar with the command line and Linux environment.
HTTP: you can pick up most of this along the way just by poking around with the tools, but it's good to know what a HTTP request looks like, and what the various requests are (GET, PUT, POST, DELETE, OPTIONS, etc). It's also helpful to have a good understanding of what the various headers are
REST: there is a convention in webdev for mapping HTTP requests onto operations on data. It gets quite complex, but the basics are relatively straightforward. Understanding RESTful resources and CRUD operations is very helpful for building APIs and interacting with them. The wikipedia page is a good place to start.
What is your basic level of programming knowledge outside of webdev? Total noob? Or some prior experience? Web dev can be tricky stuff to learn because there are so many interacting technology layers.
posted by arxeef at 1:31 PM on July 5, 2015
generally, every javascript framework is going to assume you have a preferred 'right' methodology (front-end-dev-paradigm). extjs encapsulates dom in the types. jquery wants you to structure the dom and hang shit off of it - as does angular. backbone crams a bunch of ui behavior in the css. 'mvc' is all the rage - buzzword wise, but the mvc part of this, however, is still true. it's pretty much a free-for-all out there.
the million dollar question: can a company be profitable with any of these? a blend? weird one-off implementations? yep.
the thousand dollar question: can a dev make a living with any of these? a blend? weird one-off implementations? yep.
but it's a better living if you know the whys as well as the hows. my recommendation: pick an easy-but-consistent-framework, say 'angular'. work the shit out of their examples until you really grok wtf is going on. then try the same bit in jquery. do a nice crud data app.
watch the breakdown of core web - this is the mental map that counts:
data containers: json/xml/plain text
style: css
document structure (the dom): html
client-side behavior: javascript
move-shit-around: http get/post/put/delete via forms or XmlHttpRequest (ajax)
where is each element of this responsibility breakdown taking place in the specific framework?
the next 'mental mapping' is going to be at the pattern level.( i loathe using the term pattern in this context - what the kiddies call patterns are really framework-imposed conventions to support messaging and event-wiring.). each of these frameworks has *conventions* about what sort of objects do the m and the v and the c. or the m-v-v-m. or whatever. so figure out the conventions that are in play.
be careful when everything gets bullshitty - when implementers try to overlap responsibilities: put style in html, put behavior in css, pretend a json object is an oop 'object' when it's really just a filled data structure (associative array), put state/comm in html (web sockets, eww)...
posted by j_curiouser at 1:41 PM on July 5, 2015
the million dollar question: can a company be profitable with any of these? a blend? weird one-off implementations? yep.
the thousand dollar question: can a dev make a living with any of these? a blend? weird one-off implementations? yep.
but it's a better living if you know the whys as well as the hows. my recommendation: pick an easy-but-consistent-framework, say 'angular'. work the shit out of their examples until you really grok wtf is going on. then try the same bit in jquery. do a nice crud data app.
watch the breakdown of core web - this is the mental map that counts:
data containers: json/xml/plain text
style: css
document structure (the dom): html
client-side behavior: javascript
move-shit-around: http get/post/put/delete via forms or XmlHttpRequest (ajax)
where is each element of this responsibility breakdown taking place in the specific framework?
the next 'mental mapping' is going to be at the pattern level.( i loathe using the term pattern in this context - what the kiddies call patterns are really framework-imposed conventions to support messaging and event-wiring.). each of these frameworks has *conventions* about what sort of objects do the m and the v and the c. or the m-v-v-m. or whatever. so figure out the conventions that are in play.
be careful when everything gets bullshitty - when implementers try to overlap responsibilities: put style in html, put behavior in css, pretend a json object is an oop 'object' when it's really just a filled data structure (associative array), put state/comm in html (web sockets, eww)...
posted by j_curiouser at 1:41 PM on July 5, 2015
arxeef:
I do know the basics of HTTP queries, using RESTful APIs, and the Linux command line. I also have some knowledge of C, Python, git, and so on. What I didn't know before starting this job was any more than the barest basics of JS/CSS/HTML. I now know a bit of those technologies, and have built and modified complex webpages with them, but it's all piecemeal. I can also use a few libraries and frameworks (jQuery, LESS, Bootstrap, et cetera) I've become familiar with on the job. Overall, I still know less than your average CS starting sophomore in terms of things like OOP.
I tried to edit the before-the-jump portion of my post to make it shorter and I think I left out or underemphasized some important parts. What I really, really, really want out of this week is a document I build myself, derived from resources I find elsewhere, that lays out a conceptual model of/approach to front end web development decisions. Examples of things I hope to include: MVC architecture, elements vs. pseudo-elements and when to use each, the document object model and CSS box model, style guidelines for CSS/HTML/JS.
posted by dee lee at 1:55 PM on July 5, 2015
I do know the basics of HTTP queries, using RESTful APIs, and the Linux command line. I also have some knowledge of C, Python, git, and so on. What I didn't know before starting this job was any more than the barest basics of JS/CSS/HTML. I now know a bit of those technologies, and have built and modified complex webpages with them, but it's all piecemeal. I can also use a few libraries and frameworks (jQuery, LESS, Bootstrap, et cetera) I've become familiar with on the job. Overall, I still know less than your average CS starting sophomore in terms of things like OOP.
I tried to edit the before-the-jump portion of my post to make it shorter and I think I left out or underemphasized some important parts. What I really, really, really want out of this week is a document I build myself, derived from resources I find elsewhere, that lays out a conceptual model of/approach to front end web development decisions. Examples of things I hope to include: MVC architecture, elements vs. pseudo-elements and when to use each, the document object model and CSS box model, style guidelines for CSS/HTML/JS.
posted by dee lee at 1:55 PM on July 5, 2015
This article on Style Guides was praised on BoingBoing and it seemed to me that it might be interesting to you in a meta sort of way.
posted by cleroy at 5:42 PM on July 5, 2015
posted by cleroy at 5:42 PM on July 5, 2015
I'm not sure I understand the question completely. I've been a front-end developer since the late 90s and the 'mental model' seems to be always changing.
Phase 1: whatever you can do to make it work, do it.
Phase 2: HTML4, css stylesheets, 'semantic web', complete separation of content, style, and interactivity
Phase 3: 'responsive web', device independence, frameworks, SASS, LESS
Now it seems there is talk of doing away with CSS and replacing it with using javascript to write inline styles - see this discussion.
For resources on theory and keeping up to date, I like CSS Tricks and Smashing Magazine.
I've also used Codecademy, which seems to be similar to bento.io.
posted by maggiemaggie at 2:05 PM on July 6, 2015
Phase 1: whatever you can do to make it work, do it.
Phase 2: HTML4, css stylesheets, 'semantic web', complete separation of content, style, and interactivity
Phase 3: 'responsive web', device independence, frameworks, SASS, LESS
Now it seems there is talk of doing away with CSS and replacing it with using javascript to write inline styles - see this discussion.
For resources on theory and keeping up to date, I like CSS Tricks and Smashing Magazine.
I've also used Codecademy, which seems to be similar to bento.io.
posted by maggiemaggie at 2:05 PM on July 6, 2015
a consistent model for best practices
The problem is that this doesn't really exist. As another person who has been doing web development--and inevitably, unfortunately, that includes front-end web development--since the late 90s, I agree with what maggiemaggie wrote: "the 'mental model' seems to be always changing."
It sounds like you want a mix of solid references for high-level architectural patterns (MVC, MVVM, Flux, etc.), and some more basic references for CSS, HTML and whatnot.
For the latter, MDN is my general go-to. I also like the CSS Tricks site that maggiemaggie referenced for specific CSS techniques. caniuse.com is quite handy for figuring out what is possible cross-browser.
But once you start talking about larger architectural patterns, I really don't know what to say. I mean, the differences between using Flux/React vs. Angular vs. Ember vs. some "low-level" jQuery-hacked together thing vs. a so-called "isomorphic" app with Node vs. Meteor vs. Om/Reagent + ClojureScript vs. Backbone + CoffeeScript...I mean, I'm just scratching the surface, the variability on the front-end is astounding. I don't know how you'd put together something that encapsulated, as you wrote, "a conceptual model of/approach to front end web development decisions." As far as I can tell--and I've been doing this professionally for more than a decade--no such thing exists and it's a free-for-all out there, with people making decisions based on what they are familiar with, how comfortable they are with new tech, what their backend architecture is, what their product requires, what the person they ate lunch with on Tuesday told them about, etc.
So I think either what you are looking for is too broad or you're going to have to be far more specific about what you mean when you are talking about a "a conceptual model of/approach to front end web development decisions." I mean, this is a field of people making shit up as they go along, with a passion for forgetting history over and over.
not bitter or burnt out at all, no
posted by dubitable at 4:26 AM on July 7, 2015
The problem is that this doesn't really exist. As another person who has been doing web development--and inevitably, unfortunately, that includes front-end web development--since the late 90s, I agree with what maggiemaggie wrote: "the 'mental model' seems to be always changing."
It sounds like you want a mix of solid references for high-level architectural patterns (MVC, MVVM, Flux, etc.), and some more basic references for CSS, HTML and whatnot.
For the latter, MDN is my general go-to. I also like the CSS Tricks site that maggiemaggie referenced for specific CSS techniques. caniuse.com is quite handy for figuring out what is possible cross-browser.
But once you start talking about larger architectural patterns, I really don't know what to say. I mean, the differences between using Flux/React vs. Angular vs. Ember vs. some "low-level" jQuery-hacked together thing vs. a so-called "isomorphic" app with Node vs. Meteor vs. Om/Reagent + ClojureScript vs. Backbone + CoffeeScript...I mean, I'm just scratching the surface, the variability on the front-end is astounding. I don't know how you'd put together something that encapsulated, as you wrote, "a conceptual model of/approach to front end web development decisions." As far as I can tell--and I've been doing this professionally for more than a decade--no such thing exists and it's a free-for-all out there, with people making decisions based on what they are familiar with, how comfortable they are with new tech, what their backend architecture is, what their product requires, what the person they ate lunch with on Tuesday told them about, etc.
So I think either what you are looking for is too broad or you're going to have to be far more specific about what you mean when you are talking about a "a conceptual model of/approach to front end web development decisions." I mean, this is a field of people making shit up as they go along, with a passion for forgetting history over and over.
not bitter or burnt out at all, no
posted by dubitable at 4:26 AM on July 7, 2015
For example, j_curiouser wrote at the end of their post,
put state/comm in html (web sockets, eww)...
I disagree with the implication that WebSockets are somehow a "bad" thing, and obviously many other people do too--they wouldn't exist in the spec or be implemented in browsers otherwise. Furthermore, the core architecture of the web app I'm currently working on relies on them, they are incredibly useful for us and solve a ton of problems. But j_curiouser, obviously someone experienced at web development based on the rest of their post (and I really don't mean that sarcastically), thinks they are "eww."
Q.E.D. There I leave you to contemplate the problem with coming up with a unified theory of front-end web development.
posted by dubitable at 4:37 AM on July 7, 2015
put state/comm in html (web sockets, eww)...
I disagree with the implication that WebSockets are somehow a "bad" thing, and obviously many other people do too--they wouldn't exist in the spec or be implemented in browsers otherwise. Furthermore, the core architecture of the web app I'm currently working on relies on them, they are incredibly useful for us and solve a ton of problems. But j_curiouser, obviously someone experienced at web development based on the rest of their post (and I really don't mean that sarcastically), thinks they are "eww."
Q.E.D. There I leave you to contemplate the problem with coming up with a unified theory of front-end web development.
posted by dubitable at 4:37 AM on July 7, 2015
managing state in a stateless ecology is hard (ish). that's why technology implementers put together abstractions like 'viewstate' in aspnet webforms.
managing asynchronicity is hard (ish). that's why javascript framework implementers tackled XmlHttpRequest early - abstracting with wrapper types and special language like 'promise' from angular.
http is stateless and asynchronous - persisted connections are not possible, so web dev can be hard (ish). that's why WebSockets (tcp/ip request can block). WebSockets change the fundamental definition of a web browser (web means http).
the browsers have compatibility issues (less so now, but still some): event bubbling v. capture, CSS impl...so web dev can be hard (ish). frameworks abstract incompatabilities.
Q.E.D. There I leave you to contemplate the problem with coming up with a unified theory of front-end web development.
You said a mouthful.
The unification is that "Everyone has to know what the questions are - data, style, comm, behavior, structure, async, state, browsers, etc. *AND* everyone has to have at least one answer."
If you know the tradeoffs of your fave abstractions, you are less susceptible to dogma.
posted by j_curiouser at 4:44 PM on July 7, 2015
managing asynchronicity is hard (ish). that's why javascript framework implementers tackled XmlHttpRequest early - abstracting with wrapper types and special language like 'promise' from angular.
http is stateless and asynchronous - persisted connections are not possible, so web dev can be hard (ish). that's why WebSockets (tcp/ip request can block). WebSockets change the fundamental definition of a web browser (web means http).
the browsers have compatibility issues (less so now, but still some): event bubbling v. capture, CSS impl...so web dev can be hard (ish). frameworks abstract incompatabilities.
Q.E.D. There I leave you to contemplate the problem with coming up with a unified theory of front-end web development.
You said a mouthful.
The unification is that "Everyone has to know what the questions are - data, style, comm, behavior, structure, async, state, browsers, etc. *AND* everyone has to have at least one answer."
If you know the tradeoffs of your fave abstractions, you are less susceptible to dogma.
posted by j_curiouser at 4:44 PM on July 7, 2015
« Older How to buy the empty lot next door to extend my... | Cardigan I saw on BuzzFeed vid: how do I find it... Newer »
This thread is closed to new comments.
posted by cpound at 1:04 PM on July 5, 2015