Funny that the manifesto doesn't render well on an iPad. It's too wide, and scrolling is chunky.
I also find it funny that they're using the processor intensive version of the bigtext plugin AND emphasising performance on the same page...
A Front End Engineer's Manifesto
31–40 of 43 posts
Re: A Front End Engineer's Manifesto
#32> 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.
example: in some specific situations random javascript error(and lack of exception handling) can disable your interface forever,
random HTTP connection problem may occur, while loading CSS/JS files,
etc.
Re: A Front End Engineer's Manifesto
#33I'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.
Look up at the stars. Think bigger.
Re: A Front End Engineer's Manifesto
#34"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…
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.
[1] http://jsperf.com/bens-test [2] http://bugs.jquery.com/ticket/7607
Re: A Front End Engineer's Manifesto
#35"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…
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?
Re: A Front End Engineer's Manifesto
#36"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…
I pretty strongly disagree. > 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…
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.
Numbers made up, of course.
Re: A Front End Engineer's Manifesto
#37Scrolling through that was very annoying. Page up/down obviously won't move by exactly one of the "pages".
I found out that the page listens to j/k just as in Vim. However, it seems the scroll directions are inverted from Vim; j goes up and k goes down.
So, it is iOS-style touch optimized for people who have onscreen keyboards?
Re: A Front End Engineer's Manifesto
#38Nice how security is an after thought as something to strive for, not commit to.
Also, layout is totally borked on Android Browser.
Re: A Front End Engineer's Manifesto
#39Here'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.
Re: A Front End Engineer's Manifesto
#40Seems over the top, but I think it's great if someone wants to make a commitment to being better at what they do.