A Front End Engineer's Manifesto
f2em.com
f2em.com
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.
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.
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"?
content_page<-------->web_app
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.
I thought this was debunked?
See: http://www.psychologytoday.com/blog/brain-myths/201206/why-t...
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.
And the scrolling is annoying.
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.
Also, layout is totally borked on Android Browser.