15 ms·

Front-End Developer Handbook 2017

459 points by blueatlas 10y ago

sjcrank 10y ago
This link will get you to the handbook content: https://github.com/FrontendMasters/front-end-handbook-2017/blob/master/SUMMARY.md https://github.com/FrontendMasters/front-end-handbook-2017/b...
iagooar 10y ago
It should be called Front-End Developer Handbook Early 2017. Or even early Feb 2017 ;) Now seriously, how's the front-end progressing currently? Has the pace become a bit more humane?
- hakanito 10y ago
  > JavaScript will settle, and hopefully, CSS will erupt and everyone will cry fatigue until it settles. Sounds pretty accurate. My perception is that a large part of the JS community has started to settle on React with Redux/MobX for state management.. Facebook also really lowered the barrier to entry for React with create-react-app. CSS is still up in the air a little bit, with many different solutions still being used. Sass, CSS-in-JS, CSS Modules+PostCSS and most lately styled-components (which is very promising, but lacks features like universal rendering out of the box).
  - ktRolster 10y ago
    I think WebAssembly is really going to shake things up here in the next few years.
    - flukus 10y ago
      Why? Besides easy deployment (sometimes), what does it offer over desktop applications?
      - ktRolster 10y ago
        Over desktop applications? Ease of deployment, cloud based, etc. Most things have already moved to the web anyway, so it's not really a competitor against desktop applications, it's a competitor to everything that is already in the web.
        k__ 10y ago
        As far as I know it's not suited as target for many mainstream languages. It's more like the NDK in Android. So ppl can write high performance libs in non-gc languages like C or Rust.
  - mxstbr 10y ago
    Just to note this here: SSR support for styled-components is almost finished and will be released after some testing on real projects in a few weeks as v2.
  - thejosh 10y ago
    You just hear more about React because it's the "hot new thing".
    - gspetr 10y ago
      Initial release March 2013; 3 years ago Hot, but not new on a JS timescale.
      - kevindqc 10y ago
        Wow, that's almost 4 years ago! Although it seems like it started becoming popular 1-2 years ago: https://www.google.com/trends/explore?cat=31&q=react https://www.google.com/trends/explore?cat=31&q=react
  - mattmanser 10y ago
    Not sure why you think it's settled, just look at any recent js/react discussion here and search for the word "vue". It's Vue.js everyone's raving about now. React is so 2016. In early 2015 you might have said the same about angular. The other moderately amusing parallel is that it used to be people said angular was for a full project and react you can use a lot or just a bit. Now people are saying react is for a full project and vue can use a lot or just a bit.
  - taude 10y ago
    Not sure how you'd come to the conclusion that "large part of the JS community has started to settle on React", other than confirmation bias of reading Hacker News and a lot of recent discussion about what the new hotness is. I'd rather use a gauge of number of people showing up at Meetups, number of jobs in job searches, etc. At my current guess is that the AngularJS camp is at least 4x the size of the React, and even that number is likely low since Angular is a lot more stabilized in all the enterprise environments.
- tootie 10y ago
  Toolsets change but the core principles are pretty stable. I've been around for all the paradigm shifts. When browsers first had DOM APIs and CSS. That was when FE dev first became a dedicated job. Since then we've just been layering more and more abstraction on the same stuff.
ktRolster 10y ago
Are full-stack developers really as rare as the book says?
- deleted 10y ago
  [deleted]
- flukus 10y ago
  They probably are now that front end tech is churning so much. Being full stack used to be easy, now it's a mess of javascript.
- hakanito 10y ago
  No I think all devs has to be more or less full-stack today.. When I think about a "full-stack dev" I think about someone with T-shaped skills. Aka specialist in one area (web/backend/devops), but knows a little bit about everything. Not an expert but knows enough (or takes the time to learn) about e.g. data structures, time-complexity or even css quirks to make educated decisions and participate in engineering discussions.
  - AtheistOfFail 10y ago
    > T-shaped skills Ahh, the universal sign of someone who worked around IBM.
    - gtufano 10y ago
      I was just asking myself what the T-shaped skills were...
    - rukuu001 10y ago
      No, it's a thing now. Everyone's talking T-shaped people (let alone 'comb-shaped' people)
      - deleted 10y ago
        [deleted]
mrits 10y ago
I made a pretty sophisticated Angular app a few years ago which is still selling and being maintained by other devs on my team. I started helping my friend with a new app and realized I'm already obsolete. Screw frontend development, I'll come back when things settle down.
- sdegutis 10y ago
  People are less and less understanding of the fact that nobody lives in a vacuum and all our actions affect other people. They're stressing individual liberties, which you see in the mainstream political opinion of "if it doesn't directly affect me then why should I care?", and that same guiding principle is also pushing developers to make gigantic changes without any regard to the waves, splashes, or ripples they make.
- k__ 10y ago
  I have the feeling Angular was fad. I met many people who bet on it, but most of them, even the 'fanboys' didn't seem to be 100% convinced of it. "We panicked multiple times, bit it always turned out we were wrong and just didn't do things the Angular-Way" Ember, for example, is kicking it for a much longer time, even with fewer ppl using it.
  - thewhitetulip 10y ago
    I am using Vue, which is much simpler than Angular. With Angular2, I spent a few weeks and still wasn't able to understand how things are working, contrast that with Vue, I was up and running within one week, migrated my html only app to use AJAX in a matter of a week! https://github.com/thewhitetulip/Tasks-vue https://github.com/thewhitetulip/Tasks-vue Vue.JS is great to use!
    - k__ 10y ago
      Same with React. Tiny API, not much concepts. Even Cycle.js just has a few concepts and is even more flexible than React or Vue. Angular 1&2 feels like someone let loose a Java or C# dev onto JavaScript, who tried to apply all the design patterns™
Nimsical 10y ago
It's rather ironic that the front-end developer handbook doesn't support mobile devices. Doesn't inspire confidence.
- kagamine 10y ago
  There is mention of mobile devices as early as page 8. There are 31 uses of the word "mobile" in the document. The document does not tell you how to build a website, it tells you about the tools you can use to do so reading as a series of lists linking to those technologies and a series of graphs. If you want to know about media queries for example, you have to follow the links. It's not meant as a PDF version MDN or W3schools. edit: not usually one to complain about downvotes, but the document is literally what I described it to be. So, why?
  - fancy_pantser 10y ago
    I think he meant that gitbooks doesn't have a responsive layout when you hit the "read" button instead of downloading a PDF, ePub, or mobi. The book's content is unreadable and cut off in my mobile browser when I try to read it that way.
  - tmnvix 10y ago
    I think you have been downvoted because you missed the point of the parent comment. The HTML version of the handbook is not readable on mobile (the table of contents leaves no room for the content).
    - kagamine 10y ago
      Well thanks for telling me at least. I reread OP's comment and I see what was meant now, it wasn't clear to me at the time I commented though.
    - dahauns 10y ago
      Looks fine to me. The TOC is hidden behind the hamburger menu, and the text layouts correctly. Both on FF and Chrome (Android 6)
deleted 10y ago
[deleted]
fpgaminer 10y ago
I did LAMP+HTML+JS+CSS stuff back in the day, but most of my work and hobbies over the past six years has not involved front-end. I only recently got back into the scene. I've dabbled with React and crew in quite a few hobby projects now and, at this point, I just find the whole modern front-end development stack completely wacky. I always liked Javascript as a language, but like everyone else had the scars to show for its thorny bits. Looking at the modern stack from afar left me fantasizing about all the painful points in Javascript being fixed. ES20XX, Babel, webpack, npm. Wow! To be honest, a lot of the modern stack _is_ nice. But for every step forward these tools take, they take two steps back. We have a nice package manager, npm, yay, but what happens when I `npm install -S bootstrap`? Nothing. Oh sure, it installs it, but how do I _use_ it? It's tossed in node_modules, where there's no sane way to reference it. I ran into this problem immediately, on my very first hobby project. It's now two years later, 2017, and it's still a problem that requires googling around, sifting through old answers, and finding the hack that I find least painful. Breaking up libraries into manageable sub-packages. Sounds great. It's fundamental to strong development. But usually you have a master application/library that references all the pieces, if the pieces were meant to be part of a coherent whole. But front-end devs? shrugs You just have to include everything by hand. Has seriously no one looked at their package.json in a simple TODO app and said "Something is wrong here"? How is a 20-30 line list of dependencies normal for the most basic of applications? It isn't. It's isn't maintainable. No one is going to remember all the packages they need to include each time they start a new project. They're doing what I'm doing; copy paste from the last project, like some holy script scrawled by ancient masters from long ago. Fancy new JS language features are nice. `for of`, `for in`, filter, map, etc. But seriously I can't use `<SomeThing onClick={this.handleClick}/>`? I have to use binding magic, special function definitions, etc? Because _nobody_ has to register event handlers, right? Geez. And why did they spec a standard for classes, finally, but not static methods and types!? That had to come in another version later, leaving yet another legacy of out-dated documentation? Webpack, like everything else, is an improvement by the numbers. Writing modular javascript and getting it packed into a bundle is nice. Almost like a real programming language! But why do I have to write a cryptic webpack.config.js for every project? Why do I have to install Babel and webpack separately? Why do I need to install 3 other babel related packages? Why do I need a .babelrc? It's just insane. There should just be one tool, one command. "modernjs build". Done. Break that one tool into sub-libraries/sub-tools underneath, I don't care, but when I'm building fancy Uber-for-breastmilk Web 2.0 SPA, I'd rather focus on UX than spending my evening configuring compilers to what should be their defaults. The most frustrating thing, and a common theme, is the amount of times I need to Google things while developing with the modern stack. "Oh, ummm ... how do I export/import?" "How did I configure webpack last time?" "Errr ... how do you include a bootstrap theme?" "Was it `in` or `of` to iterate over values...?" "How do you filter in place? Oh, you can't ... okay..." A lot of that sounds like basic stuff, like "How do I export/import", but ya know what? The way it's implemented in modern JS is just not intuitive. Call me dumb if you want, but I've dealt with a _lot_ of languages in my time, and JS is the one where I cannot possibly remember the exact magical incantations for specific kinds of exporting and importing. And really, that's how everything is. It's just cryptic and non-intuitive. The underlying concepts of any of these major tools or systems is sound. The implementations are gibberish. As much as I'd like to say "sorry for the rant", I'm not. Something is horribly wrong with developer culture if this abomination is what we've created. There's no excuse for it. I've heard people argue that all of this is just a result of front-end being in-between stages of its life, and that things will eventually settle down and be stable and usable in a few years. But you know what? Rust, a completely new and modern programming language, went from nothing to a thriving ecosystem in just a matter of years. It was driven by Mozilla, hardly the largest company. Meanwhile MASSIVE companies like Facebook, Google, Amazon, etc have given us the "modern front-end". There's no excuse for the ecosystem to be in this state. "But you don't have to use all those libraries and tools!" Of course not. I could just LAMP+HTML+JS+CSS it up like the good ole days. It worked then, it works now. But it frustrates me that there exists tools that _should_ be better. npm _should_ make life easier. ES2017 _should_ make Javascript a better language. I tried out these tools for a reason. Old school development was painful. Javascript with modules and packages, reactive UI, state management, etc. It's all awesome! I'm not messing about with the tools for no reason. Imagine if I sold you an automated potato peeler. "It'll peel the potatoes for you in seconds!" And it does! But turns out you spend more time cleaning it than you spent just peeling potatoes the old fashioned way. That's what the modern front-end tools are like. They take the painful parts of old-school front-end and make them easier, but they add tons of busy-work elsewhere that ends up making things a net negative.
prav 10y ago
I wish there was something similar on Backend development, or better, full-stack development.
carlmungz 10y ago
As a junior dev, that list almost makes me want to run to the hills...where I will presumably stumble upon another similarly monster-like list telling me all the things I need to learn to become [insert job role here].
- douche 10y ago
  Hint: Move to the backend. Building the APIs that crunch SQL into JSON for the react/angular/fad of the week folks to consume is much easier, and the half-life of your framework and language knowledge can be measured in years, not months.
  - NTripleOne 10y ago
    Alternatively, find somewhere to work that doesn't insist on using the latest 'greatest' new fangled bollocks technology simply because it exists.
    - fpig 10y ago
      This is a double-edged sword, though, as it may hurt you once you try to switch jobs again.
  - jumpmancw 10y ago
    Any recommendations on where to start with that? As someone who started with front-end because it was the easiest to jump into right away, and is now already sick of it, I'd appreciate the help transitioning to back-end. I have some PHP experience and a touch of SQL experience.
  - GFischer 10y ago
    The bad thing is that it's much harder (IMO) to find freelance jobs for back-end development (especially for SQL-based stuff and not Node or Rails with Mongo or whatnot). On the other hand, yes, the SQL coursework I did a decade ago is holding up really well :) .
ergo14 10y ago
Just take information there with a grain of salt. The what to expect in 2017 section says that web components will never gain traction where in fact one of the biggest enterprises in their industries adopted them already: Github, Slack, Comcast, USAToday (Ganett), ING, Coca-Cola, Electronic Arts, General Electric, Google, Youtube and others. Just https://www.webcomponents.org/ https://www.webcomponents.org/ reached over 500 reusable elements, just polymer slack channel is now 6,5k users. The current growth and adoption looks very bright, chrome, opera and safari already shipped 1.0 versions of most of the spec (so no polyfills are needed), firefox is close behind and edge is implementing right now. If this is not traction then I'm not sure what is. I'm not even accounting for other libraries/frameworks like x-tags, bosonic, svelte and others.
- GeneralMaximus 10y ago
  Have you used Web Components as part of a large project? What has your experience been? I'd love to start pushing them to my clients, especially non-tech companies who can't afford to rewrite all their code every time a new framework becomes the fad, but I'm still kinda unconvinced. I'd love to read some real-world case studies.
  - ergo14 10y ago
    Well if you want "big" cases you have Google Play Music, Youtube (gaming site, + the main one is being rewritten right now - you can force beta with some cookies), electronic arts sites like battlefield1 and others. Watch polymer summit streams they show some really high profile sites that use webcomponents. Personally I've introduced web components using polymer library in two ways - upgrading legacy jquery based application and when starting a fresh CMS system with admin panel that is 100% SPA built with polymer (kind of like weebly interface - its not public yet). It worked well for both of my cases, It felt quite similar to my previous angular 1.5+ component based approach (so I suppose it would be comparable to react/vue development). Right now you can use polymer-redux or polymer-uniflow if you want to structure big application data flows. I haven't encountered bigger obstacles or problems compared to other solutions I've used in the past. I've integrated 3rd party libs like crossroads-router or quill editor just fine. I looked a bit at Angular 2.x but for me Polymer look way more natural in terms in how applications should be build on the web. What I did miss was a routing element like angular's ui-router (I didn't like `app-route` element)- but this is currently being worked on and there is a POC ui-router port for Polymer already.
Shinchy 10y ago
It's a nice little book. Normally these things can be a bit hit and miss with the way the authors opinion of code structure seeps into them. You often end up with a bit of a 'this is wrong' mentality when in fact there is nothing wrong at all - thankfully they seem to of avoided that with this one.
sapeien 10y ago
The current front-end web stack today is not the answer, I think that is not so controversial except to the most die-hard fanboys. Most of the contents in this handbook are going to be worthless in a year. Most front-end work is repetitive, with some minor variations. Rather than a framework, I think that perhaps an expert system for making web apps that is basically an interface for metaprogramming, would be a vast improvement over the current tech.
- threepipeproblm 10y ago
  This comment makes so much more sense than their "Myth of the Full Stack Developer"
- bigmanwalter 10y ago
  I've been getting into web2py recently. It's a backend framework for python that autogenerates crud forms for you. It'll autogenerate an entire admin backend just from your table definitions in the ORM. I use Pjax to make page loads a bit quicker. Don't miss my front-end SPA framework whatsoever. Especially since my sites are SEO ready out of the box.
- shaki-dora 10y ago
  Let's see, going by the index, which technologies are younger than a year (the logic being "would your statement have made sense a year ago" because I obviously can't prove if a technology will still be relevant a year from now): Internet/web: no Web browsers: no DNS: no HTTP: no Web Hosting: no UI Design: no HTML: no CSS: no SEO: no JavaScript: no DOM, BOM, JQuery: no Web Fonts: no Accessibility: no ... and so on. But maybe you meant just Javascript libraries, which seem to make up just a small part of the content, but ok... Let's use "Module/Package Loading Tools" as a sample, because this thing is really to big to go through everything: Browserify: Started in 2012. So... nope Rollup: Started in 2015. No (but close!) SystemJS: 2013. Nope, sorry Webpack: 2013. Nope And let's arbitrarily add the behemoth: React: 2013. Nope It appears there was an awful lot of new frameworks in 2013 and that let to the impression of framework churn. To perpetuate that narrative four years later seems to be more groupthink than reality.
chrshawkes 10y ago
Some definite bias in this book. "Vue.js continues to gain converts. Deservingly so!" Is that really necessary?
rpcorb 10y ago
I'd argue that front end development tools are complex and varied because the craft itself is complex and varied. Try to strike the optimal balance between usability and fine control. It's not easy. How to welcome newbie developers with intuitive tools while not frustrating experienced ones with blunt instruments. Imagine all the schools of thought for how to best achieve this delicate balance. Not to mention beauty and elegance in design.
- romaniv 10y ago
  This is what J2EE developers said back in the day.
- kbart 10y ago
  Front-end is not fundamentally complex at all, the only complexity comes from ever changing tools and techniques. I occasionally create websites (approx. one or two per year) for my own or family/friends use and every time I have to learn everything anew, because the tools I used a year or even several months back are no longer around or have changed beyond recognition.
thinkxl 10y ago
I see people everywhere complaining about how frontend development is moving too fast, and stories like mrits. In 2011 I was sales manager in Mexico, doing WordPress sites for free on the side just for fun. In 2012 I migrated to the US with my family (legally). Then I worked in maintenance for 6 months until they fired me because I couldn't talk English. After that I decided to try to live from building websites. I started to learn JavaScript and CSS, because already knew some HTML. So I landed some clients as freelancer doing fixes on old sites, updating WordPress. When I landed my first WordPress site from scratch I didn't know how to do it, so I bought a book on the topic and used the gig as practice while reading the book. I was able to maintain my family doing responsive WordPress sites. Then I started to get issues with all the grid frameworks and stuff, it was too complicated to make a simple website responsive. So I started to do what everyone tells you not to do: "don't reinvent the wheel". I got myself to build my own grid, I did it, and I still use it Today. The process was painful because I didn't knew any real CSS so forced myself to learn it, when I got it done I was very confident I could do any layout in CSS. One freelance gig I got was a SEO tool to count the amount of words, paragraphs, syllables, etc. of a given text, it was really exiting, because I knew I had to learn JavaScript to do it. At that time Backbone was really complicated for me, so I did it but really mostly copy/pasting stuff, I was happy with the result but not with the methodology. One thing I really learned from this project, is how to setup my development environment with Grunt. So at this point I knew enough CSS and how to setup task runners. From 2013 to 2015 I did only freelance work, then I got a full-time job at a small advertising agency, doing WordPress sites. I was able to get my paycheck doing stuff that wasn't complicated for me, get a PSD, make it a responsive WordPress site (with the grid I did) and done. So I was able to learn JavaScript on my free time, so I did what worked for me in CSS again, go a reinvent the wheel. I did my own "Backbone"-like framework, and was able to learn about Object-oriented programming and how to do it in JavaScript using prototype inheritance. Then I found out about React, and started using it too, learned about functional programming, pure functions, immutable data, declarative syntax. At this point I was using Gulp, Sass, Babel, NPM, learned how to use the command line too, Vim, Tmux, was using Linux as my primary OS, and other very cool tools. So in 2016 I landed an interview for a company where the job title was frontend developer, so for me was like no more "make my logo bigger" website clients. I got the job, Today I do only JavaScript using React/Redux/React-Router, I learned Vue.js on the side and learned Python too, so now I can do my own backend using Bottle/Flask on my freetime, learned about MongoDB, Postres, SQLite. And these days I'm building my own virtual dom implementation to understand better how it works. And yes, a new JavaScript framework gets released everyday, and yet I try to use as many as I can, spend a couple hours building a todo app, reading the source code to see what I can learn from it, etc. Right now I'm loving preact, and couple days ago found out https://github.com/hyperapp/hyperapp https://github.com/hyperapp/hyperapp which is really cool. The point of my boring story is: - frontend development moves fast, get with it. Don't expect to learn something and keep using the same shit for ever. - learn JavaScript, not frameworks. If you understand the language you are going to be able to understand any framework better - if you want to learn, reinvent the wheel - avoid the hype - if you are freelance and need to make a simple app and you are comfortable with jQuery, go fucking do it in jQuery and don't mind about the new cool stuff yet. - Backbone, Angular, Ember, React, Vue, or Preact? Whatever, when I open the source code of a project built on any of those frameworks I only see JavaScript patterns, that's it. If you get a job and they are using something you don't like or something you don't know, read the documentation, learn the basic idioms and try it. Again, at the end, it's just JavaScript. I mean, I was 29 when I started my journey, no English, no CSS, no JavaScript, no knowledge about software development good practices. Now I'm 33 and very happy with my job as frontend lead developer.

459 points by blueatlas 10y ago

This link will get you to the handbook content: https://github.com/FrontendMasters/front-end-handbook-2017/blob/master/SUMMARY.md https://github.com/FrontendMasters/front-end-handbook-2017/b...

iagooar 10y ago

It should be called Front-End Developer Handbook Early 2017. Or even early Feb 2017 ;) Now seriously, how's the front-end progressing currently? Has the pace become a bit more humane?

hakanito 10y ago
> JavaScript will settle, and hopefully, CSS will erupt and everyone will cry fatigue until it settles. Sounds pretty accurate. My perception is that a large part of the JS community has started to settle on React with Redux/MobX for state management.. Facebook also really lowered the barrier to entry for React with create-react-app. CSS is still up in the air a little bit, with many different solutions still being used. Sass, CSS-in-JS, CSS Modules+PostCSS and most lately styled-components (which is very promising, but lacks features like universal rendering out of the box).
- ktRolster 10y ago
  I think WebAssembly is really going to shake things up here in the next few years.
  - flukus 10y ago
    Why? Besides easy deployment (sometimes), what does it offer over desktop applications?
    - ktRolster 10y ago
      Over desktop applications? Ease of deployment, cloud based, etc. Most things have already moved to the web anyway, so it's not really a competitor against desktop applications, it's a competitor to everything that is already in the web.
      - k__ 10y ago
        As far as I know it's not suited as target for many mainstream languages. It's more like the NDK in Android. So ppl can write high performance libs in non-gc languages like C or Rust.
- mxstbr 10y ago
  Just to note this here: SSR support for styled-components is almost finished and will be released after some testing on real projects in a few weeks as v2.
- thejosh 10y ago
  You just hear more about React because it's the "hot new thing".
  - gspetr 10y ago
    Initial release March 2013; 3 years ago Hot, but not new on a JS timescale.
    - kevindqc 10y ago
      Wow, that's almost 4 years ago! Although it seems like it started becoming popular 1-2 years ago: https://www.google.com/trends/explore?cat=31&q=react https://www.google.com/trends/explore?cat=31&q=react
- mattmanser 10y ago
  Not sure why you think it's settled, just look at any recent js/react discussion here and search for the word "vue". It's Vue.js everyone's raving about now. React is so 2016. In early 2015 you might have said the same about angular. The other moderately amusing parallel is that it used to be people said angular was for a full project and react you can use a lot or just a bit. Now people are saying react is for a full project and vue can use a lot or just a bit.
- taude 10y ago
  Not sure how you'd come to the conclusion that "large part of the JS community has started to settle on React", other than confirmation bias of reading Hacker News and a lot of recent discussion about what the new hotness is. I'd rather use a gauge of number of people showing up at Meetups, number of jobs in job searches, etc. At my current guess is that the AngularJS camp is at least 4x the size of the React, and even that number is likely low since Angular is a lot more stabilized in all the enterprise environments.
tootie 10y ago
Toolsets change but the core principles are pretty stable. I've been around for all the paradigm shifts. When browsers first had DOM APIs and CSS. That was when FE dev first became a dedicated job. Since then we've just been layering more and more abstraction on the same stuff.

ktRolster 10y ago

Are full-stack developers really as rare as the book says?

deleted 10y ago
[deleted]
flukus 10y ago
They probably are now that front end tech is churning so much. Being full stack used to be easy, now it's a mess of javascript.
hakanito 10y ago
No I think all devs has to be more or less full-stack today.. When I think about a "full-stack dev" I think about someone with T-shaped skills. Aka specialist in one area (web/backend/devops), but knows a little bit about everything. Not an expert but knows enough (or takes the time to learn) about e.g. data structures, time-complexity or even css quirks to make educated decisions and participate in engineering discussions.
- AtheistOfFail 10y ago
  > T-shaped skills Ahh, the universal sign of someone who worked around IBM.
  - gtufano 10y ago
    I was just asking myself what the T-shaped skills were...
  - rukuu001 10y ago
    No, it's a thing now. Everyone's talking T-shaped people (let alone 'comb-shaped' people)
    - deleted 10y ago
      [deleted]

mrits 10y ago

I made a pretty sophisticated Angular app a few years ago which is still selling and being maintained by other devs on my team. I started helping my friend with a new app and realized I'm already obsolete. Screw frontend development, I'll come back when things settle down.

sdegutis 10y ago
People are less and less understanding of the fact that nobody lives in a vacuum and all our actions affect other people. They're stressing individual liberties, which you see in the mainstream political opinion of "if it doesn't directly affect me then why should I care?", and that same guiding principle is also pushing developers to make gigantic changes without any regard to the waves, splashes, or ripples they make.
k__ 10y ago
I have the feeling Angular was fad. I met many people who bet on it, but most of them, even the 'fanboys' didn't seem to be 100% convinced of it. "We panicked multiple times, bit it always turned out we were wrong and just didn't do things the Angular-Way" Ember, for example, is kicking it for a much longer time, even with fewer ppl using it.
- thewhitetulip 10y ago
  I am using Vue, which is much simpler than Angular. With Angular2, I spent a few weeks and still wasn't able to understand how things are working, contrast that with Vue, I was up and running within one week, migrated my html only app to use AJAX in a matter of a week! https://github.com/thewhitetulip/Tasks-vue https://github.com/thewhitetulip/Tasks-vue Vue.JS is great to use!
  - k__ 10y ago
    Same with React. Tiny API, not much concepts. Even Cycle.js just has a few concepts and is even more flexible than React or Vue. Angular 1&2 feels like someone let loose a Java or C# dev onto JavaScript, who tried to apply all the design patterns™

Nimsical 10y ago

It's rather ironic that the front-end developer handbook doesn't support mobile devices. Doesn't inspire confidence.

kagamine 10y ago
There is mention of mobile devices as early as page 8. There are 31 uses of the word "mobile" in the document. The document does not tell you how to build a website, it tells you about the tools you can use to do so reading as a series of lists linking to those technologies and a series of graphs. If you want to know about media queries for example, you have to follow the links. It's not meant as a PDF version MDN or W3schools. edit: not usually one to complain about downvotes, but the document is literally what I described it to be. So, why?
- fancy_pantser 10y ago
  I think he meant that gitbooks doesn't have a responsive layout when you hit the "read" button instead of downloading a PDF, ePub, or mobi. The book's content is unreadable and cut off in my mobile browser when I try to read it that way.
- tmnvix 10y ago
  I think you have been downvoted because you missed the point of the parent comment. The HTML version of the handbook is not readable on mobile (the table of contents leaves no room for the content).
  - kagamine 10y ago
    Well thanks for telling me at least. I reread OP's comment and I see what was meant now, it wasn't clear to me at the time I commented though.
  - dahauns 10y ago
    Looks fine to me. The TOC is hidden behind the hamburger menu, and the text layouts correctly. Both on FF and Chrome (Android 6)

deleted 10y ago

[deleted]

fpgaminer 10y ago

I did LAMP+HTML+JS+CSS stuff back in the day, but most of my work and hobbies over the past six years has not involved front-end. I only recently got back into the scene. I've dabbled with React and crew in quite a few hobby projects now and, at this point, I just find the whole modern front-end development stack completely wacky. I always liked Javascript as a language, but like everyone else had the scars to show for its thorny bits. Looking at the modern stack from afar left me fantasizing about all the painful points in Javascript being fixed. ES20XX, Babel, webpack, npm. Wow! To be honest, a lot of the modern stack _is_ nice. But for every step forward these tools take, they take two steps back. We have a nice package manager, npm, yay, but what happens when I `npm install -S bootstrap`? Nothing. Oh sure, it installs it, but how do I _use_ it? It's tossed in node_modules, where there's no sane way to reference it. I ran into this problem immediately, on my very first hobby project. It's now two years later, 2017, and it's still a problem that requires googling around, sifting through old answers, and finding the hack that I find least painful. Breaking up libraries into manageable sub-packages. Sounds great. It's fundamental to strong development. But usually you have a master application/library that references all the pieces, if the pieces were meant to be part of a coherent whole. But front-end devs? shrugs You just have to include everything by hand. Has seriously no one looked at their package.json in a simple TODO app and said "Something is wrong here"? How is a 20-30 line list of dependencies normal for the most basic of applications? It isn't. It's isn't maintainable. No one is going to remember all the packages they need to include each time they start a new project. They're doing what I'm doing; copy paste from the last project, like some holy script scrawled by ancient masters from long ago. Fancy new JS language features are nice. `for of`, `for in`, filter, map, etc. But seriously I can't use `<SomeThing onClick={this.handleClick}/>`? I have to use binding magic, special function definitions, etc? Because _nobody_ has to register event handlers, right? Geez. And why did they spec a standard for classes, finally, but not static methods and types!? That had to come in another version later, leaving yet another legacy of out-dated documentation? Webpack, like everything else, is an improvement by the numbers. Writing modular javascript and getting it packed into a bundle is nice. Almost like a real programming language! But why do I have to write a cryptic webpack.config.js for every project? Why do I have to install Babel and webpack separately? Why do I need to install 3 other babel related packages? Why do I need a .babelrc? It's just insane. There should just be one tool, one command. "modernjs build". Done. Break that one tool into sub-libraries/sub-tools underneath, I don't care, but when I'm building fancy Uber-for-breastmilk Web 2.0 SPA, I'd rather focus on UX than spending my evening configuring compilers to what should be their defaults. The most frustrating thing, and a common theme, is the amount of times I need to Google things while developing with the modern stack. "Oh, ummm ... how do I export/import?" "How did I configure webpack last time?" "Errr ... how do you include a bootstrap theme?" "Was it `in` or `of` to iterate over values...?" "How do you filter in place? Oh, you can't ... okay..." A lot of that sounds like basic stuff, like "How do I export/import", but ya know what? The way it's implemented in modern JS is just not intuitive. Call me dumb if you want, but I've dealt with a _lot_ of languages in my time, and JS is the one where I cannot possibly remember the exact magical incantations for specific kinds of exporting and importing. And really, that's how everything is. It's just cryptic and non-intuitive. The underlying concepts of any of these major tools or systems is sound. The implementations are gibberish. As much as I'd like to say "sorry for the rant", I'm not. Something is horribly wrong with developer culture if this abomination is what we've created. There's no excuse for it. I've heard people argue that all of this is just a result of front-end being in-between stages of its life, and that things will eventually settle down and be stable and usable in a few years. But you know what? Rust, a completely new and modern programming language, went from nothing to a thriving ecosystem in just a matter of years. It was driven by Mozilla, hardly the largest company. Meanwhile MASSIVE companies like Facebook, Google, Amazon, etc have given us the "modern front-end". There's no excuse for the ecosystem to be in this state. "But you don't have to use all those libraries and tools!" Of course not. I could just LAMP+HTML+JS+CSS it up like the good ole days. It worked then, it works now. But it frustrates me that there exists tools that _should_ be better. npm _should_ make life easier. ES2017 _should_ make Javascript a better language. I tried out these tools for a reason. Old school development was painful. Javascript with modules and packages, reactive UI, state management, etc. It's all awesome! I'm not messing about with the tools for no reason. Imagine if I sold you an automated potato peeler. "It'll peel the potatoes for you in seconds!" And it does! But turns out you spend more time cleaning it than you spent just peeling potatoes the old fashioned way. That's what the modern front-end tools are like. They take the painful parts of old-school front-end and make them easier, but they add tons of busy-work elsewhere that ends up making things a net negative.

prav 10y ago

I wish there was something similar on Backend development, or better, full-stack development.

carlmungz 10y ago

As a junior dev, that list almost makes me want to run to the hills...where I will presumably stumble upon another similarly monster-like list telling me all the things I need to learn to become [insert job role here].

douche 10y ago
Hint: Move to the backend. Building the APIs that crunch SQL into JSON for the react/angular/fad of the week folks to consume is much easier, and the half-life of your framework and language knowledge can be measured in years, not months.
- NTripleOne 10y ago
  Alternatively, find somewhere to work that doesn't insist on using the latest 'greatest' new fangled bollocks technology simply because it exists.
  - fpig 10y ago
    This is a double-edged sword, though, as it may hurt you once you try to switch jobs again.
- jumpmancw 10y ago
  Any recommendations on where to start with that? As someone who started with front-end because it was the easiest to jump into right away, and is now already sick of it, I'd appreciate the help transitioning to back-end. I have some PHP experience and a touch of SQL experience.
- GFischer 10y ago
  The bad thing is that it's much harder (IMO) to find freelance jobs for back-end development (especially for SQL-based stuff and not Node or Rails with Mongo or whatnot). On the other hand, yes, the SQL coursework I did a decade ago is holding up really well :) .

ergo14 10y ago

Just take information there with a grain of salt. The what to expect in 2017 section says that web components will never gain traction where in fact one of the biggest enterprises in their industries adopted them already: Github, Slack, Comcast, USAToday (Ganett), ING, Coca-Cola, Electronic Arts, General Electric, Google, Youtube and others. Just https://www.webcomponents.org/ https://www.webcomponents.org/ reached over 500 reusable elements, just polymer slack channel is now 6,5k users. The current growth and adoption looks very bright, chrome, opera and safari already shipped 1.0 versions of most of the spec (so no polyfills are needed), firefox is close behind and edge is implementing right now. If this is not traction then I'm not sure what is. I'm not even accounting for other libraries/frameworks like x-tags, bosonic, svelte and others.

GeneralMaximus 10y ago
Have you used Web Components as part of a large project? What has your experience been? I'd love to start pushing them to my clients, especially non-tech companies who can't afford to rewrite all their code every time a new framework becomes the fad, but I'm still kinda unconvinced. I'd love to read some real-world case studies.
- ergo14 10y ago
  Well if you want "big" cases you have Google Play Music, Youtube (gaming site, + the main one is being rewritten right now - you can force beta with some cookies), electronic arts sites like battlefield1 and others. Watch polymer summit streams they show some really high profile sites that use webcomponents. Personally I've introduced web components using polymer library in two ways - upgrading legacy jquery based application and when starting a fresh CMS system with admin panel that is 100% SPA built with polymer (kind of like weebly interface - its not public yet). It worked well for both of my cases, It felt quite similar to my previous angular 1.5+ component based approach (so I suppose it would be comparable to react/vue development). Right now you can use polymer-redux or polymer-uniflow if you want to structure big application data flows. I haven't encountered bigger obstacles or problems compared to other solutions I've used in the past. I've integrated 3rd party libs like crossroads-router or quill editor just fine. I looked a bit at Angular 2.x but for me Polymer look way more natural in terms in how applications should be build on the web. What I did miss was a routing element like angular's ui-router (I didn't like `app-route` element)- but this is currently being worked on and there is a POC ui-router port for Polymer already.

Shinchy 10y ago

It's a nice little book. Normally these things can be a bit hit and miss with the way the authors opinion of code structure seeps into them. You often end up with a bit of a 'this is wrong' mentality when in fact there is nothing wrong at all - thankfully they seem to of avoided that with this one.

sapeien 10y ago

The current front-end web stack today is not the answer, I think that is not so controversial except to the most die-hard fanboys. Most of the contents in this handbook are going to be worthless in a year. Most front-end work is repetitive, with some minor variations. Rather than a framework, I think that perhaps an expert system for making web apps that is basically an interface for metaprogramming, would be a vast improvement over the current tech.

threepipeproblm 10y ago
This comment makes so much more sense than their "Myth of the Full Stack Developer"
bigmanwalter 10y ago
I've been getting into web2py recently. It's a backend framework for python that autogenerates crud forms for you. It'll autogenerate an entire admin backend just from your table definitions in the ORM. I use Pjax to make page loads a bit quicker. Don't miss my front-end SPA framework whatsoever. Especially since my sites are SEO ready out of the box.
shaki-dora 10y ago
Let's see, going by the index, which technologies are younger than a year (the logic being "would your statement have made sense a year ago" because I obviously can't prove if a technology will still be relevant a year from now): Internet/web: no Web browsers: no DNS: no HTTP: no Web Hosting: no UI Design: no HTML: no CSS: no SEO: no JavaScript: no DOM, BOM, JQuery: no Web Fonts: no Accessibility: no ... and so on. But maybe you meant just Javascript libraries, which seem to make up just a small part of the content, but ok... Let's use "Module/Package Loading Tools" as a sample, because this thing is really to big to go through everything: Browserify: Started in 2012. So... nope Rollup: Started in 2015. No (but close!) SystemJS: 2013. Nope, sorry Webpack: 2013. Nope And let's arbitrarily add the behemoth: React: 2013. Nope It appears there was an awful lot of new frameworks in 2013 and that let to the impression of framework churn. To perpetuate that narrative four years later seems to be more groupthink than reality.

chrshawkes 10y ago

Some definite bias in this book. "Vue.js continues to gain converts. Deservingly so!" Is that really necessary?

rpcorb 10y ago

I'd argue that front end development tools are complex and varied because the craft itself is complex and varied. Try to strike the optimal balance between usability and fine control. It's not easy. How to welcome newbie developers with intuitive tools while not frustrating experienced ones with blunt instruments. Imagine all the schools of thought for how to best achieve this delicate balance. Not to mention beauty and elegance in design.

romaniv 10y ago
This is what J2EE developers said back in the day.
kbart 10y ago
Front-end is not fundamentally complex at all, the only complexity comes from ever changing tools and techniques. I occasionally create websites (approx. one or two per year) for my own or family/friends use and every time I have to learn everything anew, because the tools I used a year or even several months back are no longer around or have changed beyond recognition.

thinkxl 10y ago

I see people everywhere complaining about how frontend development is moving too fast, and stories like mrits. In 2011 I was sales manager in Mexico, doing WordPress sites for free on the side just for fun. In 2012 I migrated to the US with my family (legally). Then I worked in maintenance for 6 months until they fired me because I couldn't talk English. After that I decided to try to live from building websites. I started to learn JavaScript and CSS, because already knew some HTML. So I landed some clients as freelancer doing fixes on old sites, updating WordPress. When I landed my first WordPress site from scratch I didn't know how to do it, so I bought a book on the topic and used the gig as practice while reading the book. I was able to maintain my family doing responsive WordPress sites. Then I started to get issues with all the grid frameworks and stuff, it was too complicated to make a simple website responsive. So I started to do what everyone tells you not to do: "don't reinvent the wheel". I got myself to build my own grid, I did it, and I still use it Today. The process was painful because I didn't knew any real CSS so forced myself to learn it, when I got it done I was very confident I could do any layout in CSS. One freelance gig I got was a SEO tool to count the amount of words, paragraphs, syllables, etc. of a given text, it was really exiting, because I knew I had to learn JavaScript to do it. At that time Backbone was really complicated for me, so I did it but really mostly copy/pasting stuff, I was happy with the result but not with the methodology. One thing I really learned from this project, is how to setup my development environment with Grunt. So at this point I knew enough CSS and how to setup task runners. From 2013 to 2015 I did only freelance work, then I got a full-time job at a small advertising agency, doing WordPress sites. I was able to get my paycheck doing stuff that wasn't complicated for me, get a PSD, make it a responsive WordPress site (with the grid I did) and done. So I was able to learn JavaScript on my free time, so I did what worked for me in CSS again, go a reinvent the wheel. I did my own "Backbone"-like framework, and was able to learn about Object-oriented programming and how to do it in JavaScript using prototype inheritance. Then I found out about React, and started using it too, learned about functional programming, pure functions, immutable data, declarative syntax. At this point I was using Gulp, Sass, Babel, NPM, learned how to use the command line too, Vim, Tmux, was using Linux as my primary OS, and other very cool tools. So in 2016 I landed an interview for a company where the job title was frontend developer, so for me was like no more "make my logo bigger" website clients. I got the job, Today I do only JavaScript using React/Redux/React-Router, I learned Vue.js on the side and learned Python too, so now I can do my own backend using Bottle/Flask on my freetime, learned about MongoDB, Postres, SQLite. And these days I'm building my own virtual dom implementation to understand better how it works. And yes, a new JavaScript framework gets released everyday, and yet I try to use as many as I can, spend a couple hours building a todo app, reading the source code to see what I can learn from it, etc. Right now I'm loving preact, and couple days ago found out https://github.com/hyperapp/hyperapp https://github.com/hyperapp/hyperapp which is really cool. The point of my boring story is: - frontend development moves fast, get with it. Don't expect to learn something and keep using the same shit for ever. - learn JavaScript, not frameworks. If you understand the language you are going to be able to understand any framework better - if you want to learn, reinvent the wheel - avoid the hype - if you are freelance and need to make a simple app and you are comfortable with jQuery, go fucking do it in jQuery and don't mind about the new cool stuff yet. - Backbone, Angular, Ember, React, Vue, or Preact? Whatever, when I open the source code of a project built on any of those frameworks I only see JavaScript patterns, that's it. If you get a job and they are using something you don't like or something you don't know, read the documentation, learn the basic idioms and try it. Again, at the end, it's just JavaScript. I mean, I was 29 when I started my journey, no English, no CSS, no JavaScript, no knowledge about software development good practices. Now I'm 33 and very happy with my job as frontend lead developer.