You failed to interpret the page author's 100% custom scrollbar (on the left edge of the screen) as an indicator that there was more content? That's ... odd.
He clearly had your interests in mind when implementing that, since browser vendors just think about themselves with their annoying scrollbars that look the same on every page, even. Simplistic fools.
There's basically enough truth to it that you can't just refute-by-reality, but not enough to make statements like this acceptable by my standards. It's vague enough that it's not actually a useful statement for anyone taking it literally.
You can cater to the variety of platforms your users want to use whilst at the same time having useful and meaningful conversations with friends and family about what the best browser is for them. You don't annoy your users by trying to 'educate' them, but collectively we see a move forward.
The two are not mutually exclusive as you seem to imply.
> Your users do not NEED to be educated by you.
I think educating clients and users is actually crucial.
For a lot of users browser was conscious choice, but there is big group that don't even know that there are different/newer browsers.
First group can ignore advice but second group might benefit a lot.
>It is not your business what browser they use.
It absolutely is.
Silly car metaphor: I'm taking my car to a service station. I expect mechanic to tell me that oil I'm using is not the optimal one. Whether or not I take his advice is my business. But informing me about substandard oil is very much his business.
Also - If all of my users used modern browsers, I could save money by not spending time on ensuring my site performs well on old buggy browsers.
"Without JavaScript or CSS, or without mobile Webkit, my site may not look pretty but will still be functional."
There goes backbone.js and other javascript MVC patterns.
This is something I'm still unsure about.
What do (you) people think of keeping your "data out of the DOM"?
This rubs me the wrong way for some reason. Maybe it just sounds really pretentious(?) In the end front-end (or any other) development exists to create services for the users, not for it's own sake as a philosophy or something.
"I will learn at the root, not the abstraction:
JAVASCRIPT BEFORE JQUERY"
I'm not sure why one high-end abstraction finds favour over another slightly higher high-end abstraction, but this sure sounds a lot like the people who insist that you can't be a good programmer unless you've learned some kind of assembler.
On the "shoulders of giants" means we don't need to know javascript as well as jQuery. It means we don't have to know assembler as well as pascal. It means that we don't need to learn IP when we can just learn TCP/IP, and we don't need to learn TCP/IP when we can just use REST over HTTP.
Learning at the root goes a lot further down than you want to go, need to go or are capable of going.
> On the "shoulders of giants" means we don't need to know javascript as well as jQuery.
Not necessarily. I like to view it this way: When you are learning a new language (English, German, Chinese, whatever), in day to day conversations it is useful to know some expressions, idioms, or terms, but you should also know where they come from and how to explain them, and not just how to use them.
Learning what "I'm pissed" means in British english is quite nice but if you say that to an American and responds "Who pissed you?", how are going to teach this person of the use of the word "pissed" in this context?
Similarly, a jQuery-only developer will find it difficult to understand and explain what he meant to do with some piece of code, let's say $.each. A "native speaker", ie. a javascript developer, may be able to offer some advice or corrections, like "you could use Array.forEach in this scenario". (Granted this particular example may not be so good due but you get the point).
There's always a tradeoff between knowing what something like "each" does and having that extra architectural clutter being a cognitive drag. I can see the point being made, and there are obviously going to be situations where getting closer to the metal is important, but getting closer to the metal isn't always a good thing.
Sometimes, knowing things closer to the metal isn't good either. It took me ages to unlearn certain practices and just accept the garbage collector would do its job and I no longer need to think about unallocating memory.
Like all things, this one isn't black and white and it's open to subjectivity. For me though, I feel that the negative side of having knowledge of lower levels of your architectural stack is a hindrance more than it is not.
> this sure sounds a lot like the people who insist that you can't be a good programmer unless you've learned some kind of assembler.
This isn't a very good analogy. JavaScript is a high level language, and jQuery is just a library with features that make it a high level DSL. But when you "write jQuery" you're really writing JavaScript, not some other language, so I don't think the analogy with languages compiled to assembly really makes sense. That being said, I do think that knowing some assembly will not hurt you writing C, and likely will help. Similarly, understanding some of how JS is implemented in browsers won't hurt, and might help you write JS.
It's true that there's almost no limit to how deep the rabbit hole goes. Someone building web apps probably doesn't need to have a degree in electrical engineering, but I don't think this kind of slippery slope argument defends someone using jQuery without knowing JavaScript.
In a grandchild comment you wrote:
> It took me ages to unlearn certain practices and just accept the garbage collector would do its job and I no longer need to think about unallocating memory.
You don't need to explicitly think about unallocating memory, but that doesn't mean your knowledge of manual memory management isn't useful. You do need to be aware of how the GC works if you're working with one. You can still have memory leaks, so how could you possibly debug them if you think the GC is magic?
There's this meme that is floated around HN and elsewhere, that the title "software engineer" is just puffery, because we aren't "real" engineers. I try to avoid this discussion because I think it's mostly stupid, but I can't help touch on it here given the title of this manifesto. I just don't think anyone could seriously call themselves a "front end engineer" if they refuse to learn JavaScript, claiming it's not necessary to use jQuery. Given that the author thinks this title is appropriate, I think the assertion about learning JavaScript is perfectly acceptable.
I'd be interested to hear more about what you think though, and about how the negatives to understanding lower levels of the stack outweigh the benefits. In my (limited) experience, some or more understanding of one or even two "levels down the stack" has never been a net-negative.
99% of devs building the popular sites on the Internet have never needed to think about GC beyond maybe the vaguest terms of "if you keep too many references to too big things your app will slog." 0.5% write tools, libraries, and compilers that worry about this, and 0.5% debug extreme cases in their apps.
I think you're wrong, and I don't know what the point of making up numbers is. It might be your experience that you've been able to treat garbage collection as magic, and that's nice, but it's not been mine. I was speaking generally, about all programmers, not just web developers.
My point was that if you don't have any understanding of how garbage collection works, you simply don't have all possible tools at your disposal when you need to debug a memory leak. I'm not suggesting every programmer needs to have spent years hacking on garbage collectors and studied all of the literature, just that having some familiarity with the tools available to you is important.
And this was just one example meant to support my main argument that gaining understanding below the level of abstraction you are working at is not a bad thing.
I don't think the assembler analogy holds with jQuery vs. JavaScript/DOM.
There's a reason why an event handler has a DOM element and not a jQuery object as its `this` keyword. At the time jQuery was designed, we thought everyone understood the DOM well enough to use it directly. Yes you can take the DOM element and wrap it in a jQuery object, but it's not always appropriate.
For example, `this.checked` is about 100 times faster, much prettier, and shorter to type than `$(this).is(":checked")` [1]. No amount of optimization inside jQuery will really change that performance gap.
Sometimes people get a misguided belief that every access to every JavaScript object should be through jQuery. Then we get reports that `$(window).attr("location")` don't work. [2] So yeah, learn JavaScript and the DOM.
jQuery abstracts the DOM, not JS, so this item doesn't make sense. Much like the DOM doesn't make sense cross-browser. Does OP also bugger himself about the difference between VGA and DVI when designing his UI?
So just put this in a full static page. Why the scrolling? And also color/font choice is quite terrible. No responsiveness for small screens. Apparently, he didn't follow his own advice.
I was going to observe that you can (in Firefox, at least) turn off the custom stylesheet, and it becomes much more readable. But if you scroll all the way to the end, it jumps around and doesn't actually let you scroll to the end (perhaps due to its JS). There's definitely something weird on that page.
I'd expect an article titled Front-end engineer's manifesto to have better UI than this. First thing I assumed was that I could use up, down in my keypad to navigate through slides. Then right, left. Figured scrolling is okay.
The sidebar that's supposed to show me how far I've read isn't apparent. The font choices and responsiveness coud be better.
Reinventing scrolling isn't good. I'd have been fine if it worked for me on Chrome, it got stuck in page 4 and 5 and I had to press j/k few times to get moving again. If there's a tool that takes care of kind of stuff and frees you to do important stuff, why not use it? On that point, checkout impress.js for this kind of stuff.
Just some great writing on this idea of being a "balanced" human, and how that influences, informs, and improves your skills. His skills were as a samurai, but the principles apply pretty universally. I got a lot out of the book, you can find it free on iBooks, Kindle, etc.
> Without JavaScript or CSS [...] my site may not look pretty but will still be functional.
For what reason exactly? Of course there are cases where it makes sense to follow this rule, maybe even the majority, but having it as #2 in your manifesto will severely limit what you can accomplish on the web.
I'm a successful front-end developer and I really don't care about any of this stuff.
This is one of the last manifesto's I'd personally subscribe to.
In fact, I feel sad for anyone who takes front-end development this seriously. This is a field that exists because of fragmentation and the strange place that the web has arrived at.
On the whole, we aren't solving interesting problems. We are building what someone else has designed and then patching that build across devices and browsers. Sometimes there are fun problems to solve while doing that, but its nothing compared to what we could be doing as programmers.
I get paid well to make applications work cross device and cross browser, and I have an extremely flexible work environment. That is why I work hard. Not because Tom from Oklahoma is going to have a slightly better day because he doesn't have to figure out how to get on with his life when the site I'm working on doesn't break on his particular device or browser.
Here's a manifesto: do your job, do it well. Some tools/ideologies will work better for you than they do for others. Strive for perfection, accept reality.
Progressive enhancement is the main reason HTML-based apps can't compete with native apps. Progressive enhancement is synonymous with not pushing things forward.
I know of at least one stealth startup who have built up a javascript library that is indistinguishably performant with native apps, but that performance comes at the cost of progressive enhancement. It's a tradeoff worth making.
I believe in an open web too, but one that is as powerful as native apps, not a crippled second-rate one that loses users and developers to proprietary platforms. Any browser feature that developers find useful and actively adopt will quickly be incorporated into the remaining browsers.
"I’ve been reluctant to share the slides because I certainly don’t want developers to take them as dogmatic truth. Rather, I’d love for people to see a forest using trees they’ve planted themselves."
Certainly scrolling could be improved. I'll definitely look into improving the performance. I honestly had no idea this slide deck would get this much attention.
42 comments
[ 4.6 ms ] story [ 96.6 ms ] threadHe clearly had your interests in mind when implementing that, since browser vendors just think about themselves with their annoying scrollbars that look the same on every page, even. Simplistic fools.
I thought this was debunked?
See: http://www.psychologytoday.com/blog/brain-myths/201206/why-t...
and
"Most importantly and above all, I will put the needs of the USER FIRST over my own needs as a developer."
So please do, put the needs of your USERS first. Your users do not NEED to be educated by you. It is not your business what browser they use.
You can cater to the variety of platforms your users want to use whilst at the same time having useful and meaningful conversations with friends and family about what the best browser is for them. You don't annoy your users by trying to 'educate' them, but collectively we see a move forward.
> Your users do not NEED to be educated by you.
I think educating clients and users is actually crucial. For a lot of users browser was conscious choice, but there is big group that don't even know that there are different/newer browsers. First group can ignore advice but second group might benefit a lot.
>It is not your business what browser they use.
It absolutely is.
Silly car metaphor: I'm taking my car to a service station. I expect mechanic to tell me that oil I'm using is not the optimal one. Whether or not I take his advice is my business. But informing me about substandard oil is very much his business.
Also - If all of my users used modern browsers, I could save money by not spending time on ensuring my site performs well on old buggy browsers.
What do (you) people think of keeping your "data out of the DOM"?
And the scrolling is annoying.
I'm not sure why one high-end abstraction finds favour over another slightly higher high-end abstraction, but this sure sounds a lot like the people who insist that you can't be a good programmer unless you've learned some kind of assembler.
On the "shoulders of giants" means we don't need to know javascript as well as jQuery. It means we don't have to know assembler as well as pascal. It means that we don't need to learn IP when we can just learn TCP/IP, and we don't need to learn TCP/IP when we can just use REST over HTTP.
Learning at the root goes a lot further down than you want to go, need to go or are capable of going.
Not necessarily. I like to view it this way: When you are learning a new language (English, German, Chinese, whatever), in day to day conversations it is useful to know some expressions, idioms, or terms, but you should also know where they come from and how to explain them, and not just how to use them.
Learning what "I'm pissed" means in British english is quite nice but if you say that to an American and responds "Who pissed you?", how are going to teach this person of the use of the word "pissed" in this context?
Similarly, a jQuery-only developer will find it difficult to understand and explain what he meant to do with some piece of code, let's say $.each. A "native speaker", ie. a javascript developer, may be able to offer some advice or corrections, like "you could use Array.forEach in this scenario". (Granted this particular example may not be so good due but you get the point).
Sometimes, knowing things closer to the metal isn't good either. It took me ages to unlearn certain practices and just accept the garbage collector would do its job and I no longer need to think about unallocating memory.
Like all things, this one isn't black and white and it's open to subjectivity. For me though, I feel that the negative side of having knowledge of lower levels of your architectural stack is a hindrance more than it is not.
> this sure sounds a lot like the people who insist that you can't be a good programmer unless you've learned some kind of assembler.
This isn't a very good analogy. JavaScript is a high level language, and jQuery is just a library with features that make it a high level DSL. But when you "write jQuery" you're really writing JavaScript, not some other language, so I don't think the analogy with languages compiled to assembly really makes sense. That being said, I do think that knowing some assembly will not hurt you writing C, and likely will help. Similarly, understanding some of how JS is implemented in browsers won't hurt, and might help you write JS.
It's true that there's almost no limit to how deep the rabbit hole goes. Someone building web apps probably doesn't need to have a degree in electrical engineering, but I don't think this kind of slippery slope argument defends someone using jQuery without knowing JavaScript.
In a grandchild comment you wrote:
> It took me ages to unlearn certain practices and just accept the garbage collector would do its job and I no longer need to think about unallocating memory.
You don't need to explicitly think about unallocating memory, but that doesn't mean your knowledge of manual memory management isn't useful. You do need to be aware of how the GC works if you're working with one. You can still have memory leaks, so how could you possibly debug them if you think the GC is magic?
There's this meme that is floated around HN and elsewhere, that the title "software engineer" is just puffery, because we aren't "real" engineers. I try to avoid this discussion because I think it's mostly stupid, but I can't help touch on it here given the title of this manifesto. I just don't think anyone could seriously call themselves a "front end engineer" if they refuse to learn JavaScript, claiming it's not necessary to use jQuery. Given that the author thinks this title is appropriate, I think the assertion about learning JavaScript is perfectly acceptable.
I'd be interested to hear more about what you think though, and about how the negatives to understanding lower levels of the stack outweigh the benefits. In my (limited) experience, some or more understanding of one or even two "levels down the stack" has never been a net-negative.
Numbers made up, of course.
My point was that if you don't have any understanding of how garbage collection works, you simply don't have all possible tools at your disposal when you need to debug a memory leak. I'm not suggesting every programmer needs to have spent years hacking on garbage collectors and studied all of the literature, just that having some familiarity with the tools available to you is important.
And this was just one example meant to support my main argument that gaining understanding below the level of abstraction you are working at is not a bad thing.
There's a reason why an event handler has a DOM element and not a jQuery object as its `this` keyword. At the time jQuery was designed, we thought everyone understood the DOM well enough to use it directly. Yes you can take the DOM element and wrap it in a jQuery object, but it's not always appropriate.
For example, `this.checked` is about 100 times faster, much prettier, and shorter to type than `$(this).is(":checked")` [1]. No amount of optimization inside jQuery will really change that performance gap.
Sometimes people get a misguided belief that every access to every JavaScript object should be through jQuery. Then we get reports that `$(window).attr("location")` don't work. [2] So yeah, learn JavaScript and the DOM.
[1] http://jsperf.com/bens-test [2] http://bugs.jquery.com/ticket/7607
So just put this in a full static page. Why the scrolling? And also color/font choice is quite terrible. No responsiveness for small screens. Apparently, he didn't follow his own advice.
Just some great writing on this idea of being a "balanced" human, and how that influences, informs, and improves your skills. His skills were as a samurai, but the principles apply pretty universally. I got a lot out of the book, you can find it free on iBooks, Kindle, etc.
EDIT wow, I actually didn't find a free version on Kindle, but here's a few formats for free from Archive.org -> http://archive.org/details/MiyamotoMusashi-BookOfFiveRingsgo...
For what reason exactly? Of course there are cases where it makes sense to follow this rule, maybe even the majority, but having it as #2 in your manifesto will severely limit what you can accomplish on the web.
random HTTP connection problem may occur, while loading CSS/JS files,
etc.
This is one of the last manifesto's I'd personally subscribe to.
In fact, I feel sad for anyone who takes front-end development this seriously. This is a field that exists because of fragmentation and the strange place that the web has arrived at.
On the whole, we aren't solving interesting problems. We are building what someone else has designed and then patching that build across devices and browsers. Sometimes there are fun problems to solve while doing that, but its nothing compared to what we could be doing as programmers.
I get paid well to make applications work cross device and cross browser, and I have an extremely flexible work environment. That is why I work hard. Not because Tom from Oklahoma is going to have a slightly better day because he doesn't have to figure out how to get on with his life when the site I'm working on doesn't break on his particular device or browser.
Look up at the stars. Think bigger.
Also, layout is totally borked on Android Browser.
I know of at least one stealth startup who have built up a javascript library that is indistinguishably performant with native apps, but that performance comes at the cost of progressive enhancement. It's a tradeoff worth making.
I believe in an open web too, but one that is as powerful as native apps, not a crippled second-rate one that loses users and developers to proprietary platforms. Any browser feature that developers find useful and actively adopt will quickly be incorporated into the remaining browsers.
"I’ve been reluctant to share the slides because I certainly don’t want developers to take them as dogmatic truth. Rather, I’d love for people to see a forest using trees they’ve planted themselves."
Certainly scrolling could be improved. I'll definitely look into improving the performance. I honestly had no idea this slide deck would get this much attention.