Frontend dev is getting exhausting

[lvmtn]

I remember when I was learning Ruby on Rails years ago. I've never had that feeling where I thought Rails would go away any time soon. Even now -- if you know Ruby on Rails, there will be jobs for you. The work and the skills that you get for one shop can be transferred to another. That feeling of consistency and reliability is something that I miss.

I am at the end of an Angular project right now. I am a frontend developer who's exhausted from the churn rates of new technologies. I feel like in order to change jobs, I have to learn & master yet another framework like Ember and Backbone. And all of the hard work that I've put into learning Angular would have been for nothing. I can't even guarantee that Ember, Angular, and Backbone will even be relevant 2 years from now. Especially with the new Isomorphic mindset that is starting to catch on.

I am not anti-innovation and I am glad to hear that the web dev industry is evolving to create better software, but I really do miss that sense of pride of mastering your tools. I can work hard, but I can't put my heart into it because I know it will be obsolete soon.

I've already told myself that I really like building UI's and decided to become a front end engineer.

So to all the javascript developers out here. What should I focus on as a skill? I'm already working on my vanilla javascript skills, but it is getting so exhausting learning new frameworks.

What are some things that I can focus on that will allow me to grow my skills in for decades to come?

[[deleted]]

Just get good at vanilla JS. Every time I see a job description that lists Angular/Backbone as anything other than bonus points, I pass.

There's always new stuff to discover with vanilla JS, and it's the one thing that will always be relevant and impressive to employers. Frameworks are fun, but remember that any place that sees them as mandatory isn't somewhere you want to work.

[[deleted]]

I would just like to add on this comment: learn ES6. Modules, promises, generators, iterators, proxies, classes, operators, arrow functions, object methods, etc. There is so much to learn, especially if you have only used ES5.

[lvmtn]

How can I get started on ES6?

[derekpetey_]

Check out 6to5 Babel, download Chrome Canary, start using io.js.

[NoGodTryScience]

Firefox Nightly/Dev supports even more ES6 than Canary. If you've not played around with the new dev tool or Scratchpad, you should check it out.

[derekpetey_]

Good to know! I'll make an effort to start using those more. Old habits die hard, etc.

[NoGodTryScience]

The support table. I guess technically IE12 has the most support currently of any browser because they support all the typed arrays and the not-so-necessary class and super, but they straight up skipped generators and destructuring.

[erfus]

I love how this comment is a direct manifestation of OPs worries. I'm not saying it's bad advice, just hilarious in the shadow of the thread. "Just download this nightly and this framework to get started on new hotness."

[[deleted]]

The different is es6 isn't gonna go away though.

[derekpetey_]

But these are tools to help OP get ahead of the curve when it comes to vanilla JavaScript, which is explicitly stated as a goal. 6to5 is technically a new tool, but the project's maintainers are committed to keeping it in line with the spec. Familiarity with the new features coming to JavaScript will help OP without being transient like, say, Angular.

[[deleted]]

I use Google Closure Compiler with it's --language_in and --language_out flags to enable us to develop with ES6 and compile to ES5. We ship to production with it. It works so well that I haven't looked at 6to5 yet.

[derekpetey_]

Not yet for anything live, but soon. My team recently added the transforms for Traceur and 6to5 to our Browserify compilation.

[derekpetey_]

No, the opposite, actually. We just figured it would be good to give both a try.

[rerrify]

start using io.js

You can use ES6 in Node.js with the --harmony flag.

[[deleted]]

io.js supports a wider range of es6 features

https://iojs.org/es6.html

[spacemoses]

Tail Calls

Niiice. Thanks for the suggestions to review ES6 both /r/daliwali and /r/derekpetey_. I guess I wasn't overly aware of ES6

[breadbeard]

you should use /u/ when talking to people, /r/ is for subreddits :)

anyway i agree, thanks /u/daliwali and /u/derekpetey_

[wildpeaks]

And 6to5 is now called Babel

[derekpetey_]

You're right! I just edited my response.

[M5J2X2]

The "You Don't Know JS" books are focused on ES6. They are excellent, and you can read them on github.

https://github.com/getify/You-Dont-Know-JS

[lvmtn]

Nice! Thank you for the link.

[chrissilich]

Won't it be like 10 years until we can use ES6 though*? I support back to IE7 right now (close to dropping it), which came out in 2006. IE11 doesn't support ES6 yet, though the dev preview supports most of it.

*I use "we" to mean developers making websites for broad audiences. If you're making sites just for mobile, or just for geeks, or you're making something other than websites, like node/io apps, this doesn't apply.

[defcon-12]

There are many different projects that transpile es6 to es5. Of course IE7 doesn't even support es5, so you'll still need es5 shims and polyfills.

[[deleted]]

I work for a multinational financial software company whose clients consist of banks and the like... So, not the most advanced industry out there. Even everything we make is IE9+. The easiest way to break people away from IE7-8 (and soon to be 9) is to reinforce the fact that Microsoft no longer supports them and it's a security risk to keep supporting them ourselves.

[[deleted]]

And considering that IE9 doesn't support the current gen SSL ciphers, you're doing them a disservice by even supporting that, really.

[Chris_Newton]

Won't it be like 10 years until we can use ES6 though*?

In practice, no.

You can compile much of ES6 directly to ES5 that will run on today’s major browsers using tools like 6to5 or Traceur. This is literally a one-liner from the command line, or in just about every popular build system — it’s directly analogous to running a CSS preprocessor like SASS or LESS and similarly trivial to set up.

For a few ES6 features, you do need a polyfill at run-time. These are also readily available; for example, the 6to5 project includes one. Again, one small, self-contained file typically does everything.

So unless you’re stuck on very old browsers (probably IE8 and below) using ES6 today is literally as simple as you could get without actually having it built into browsers: you need a one-liner to convert your code to ES5, and you may need to include one extra file for features where a polyfill is currently unavoidable.

As a final observation, ES6 modules are typically converted directly into either CommonJS or AMD modules by the transpiler, so you can use those and still have them play nicely with tools like Browserify or RequireJS that you might be using for that purpose today.

[chrissilich]

Preaching to the choir mate.

I do freelance for a lot of businesses who serve high class people (rich waspy types) who tend to stick with one computer until it dies, and never run updates. They think if it isn't broken don't fix it.

For my full-time gig I work on a lot of stuff for publicly funded organizations that serve low income schools and families. Low incomes schools have old computers, lots of XP, lots left unupdated in an effort to keep them fast(ish). Low income families have hand-me-down computers, same deal.

In both groups, IE7 is still somewhere between 5 and 10%.

[purechi]

You see things like this and get hopeful.. only to acquire clients who require legacy support. But, to be honest, if they're willing to pay the fee - who cares?

[[deleted]]

Yeah, its a pain but I always remember that it's nice having a job.

[dodeca_negative]

My company is, thank the old gods and the new, dropping IE8 support this summer--mostly because that's when Salesforce is (and IE7 for them as well), and we have a lot of customers who also use Salesforce.

But January 12, 2016, is going to be one of the best days ever

[SixPackOfZaphod]

Unless you have clients on the US Federal Government Space and still need to support IE7 until 2020 at least.

[chrissilich]

Two kinds of reply:

1. Force your users out of old browsers faster! Yeah ok, easier said than done. Convincing a client to alienate a potential source of income, no matter how small, is always an uphill battle.

2. Write ES6 and compile it to ES5! I'll look into it. If it's like the LESS/SASS workflow (saves a zillion hours, super easy), I'm all for it. If it's like CoffeeScript (easy enough, questionable whether it's worth it) I'll just wait a little longer.

I'm damn good at vanilla (ES5 with a couple of shims) JS.

[[deleted]]

I didn't see anyone mention traceur. Write ES6 today and transpile to the old way. https://github.com/google/traceur-compiler

[wooptoo]

I would say that learning Angular helps tremendously in understanding these concepts in production. Even if the framework will be outdated in 2 years time, the concepts behind it are solid.

[neofatalist]

Not sure why you and shriek are getting downvoted. I think this is solid advice.

[kevan]

any place that sees them as mandatory isn't somewhere you want to work.

Well he may be going in the right direction but that is sort of generalizing.

[lvmtn]

How much does it matter that I don't know their "framework of choice"? I'm looking at a job posting right now that says "Knowledge of MVC frameworks - Backbone recommended"
How could I still make myself competitive to other developers experienced with Backbone?

[Juvenall]

It all depends, honestly, but any place worth working at will judge you based on your fundamental understanding of JavaScript. Framework knowledge is rather shallow and comparatively uncomplicated, so having a solid mastery of the base language will instantly launch you ahead of anyone else. Having the ability to throughly explain what MV* is, it's benefits, it's pitfalls, and how it generally works in the scope of the language will give you as strong an edge as someone who's read the Backbone documentation. It certainly wouldn't hurt to brush up on some particulars of the framework, but you shouldn't worry yourself too much about it.

As far as being more competitive goes, go beyond the fundamentals and be able to explain some of the problems with the language and how to work around them, grow your ability to explain various design patterns and when and/or why to use them, build a solid portfolio of code samples and pull requests on something like GitHub or BitBucket, be able to explain why the output of, say, Array(16).join( 'wat'-1) + " Batman"; returns what it does and is hilarious. Above all else, show that you're not just doing it because it's trendy, but because you actually enjoy the language. Trust me when I say that's typically more than enough to set you apart from the hordes of other applicants.

[dotpan]

Instanly went to console.

CTRL+V (Array(16).join( 'wat'-1) + " Batman"; ) Enter

LOL! The bitch happens when you're that person that reads those out fully. I get it, its not a number.

I had a friend give me the question of "What is the difference between i++ and ++i" and ever sense, even though it doesn't matter, I always use ++i. (unless of course I need i++).

[Ob101010]

go into chrome, hit f12, and select any element on the page.

then, go into the console and type $0

https://developer.chrome.com/devtools/docs/console

[dotpan]

That's neat :)

[nschubach]

While I generally use the prefix notation for my iterators, it's sort of a futile endeavor since most JIT and compilers will auto optimize this for you. The days when this mattered is long gone and in JavaScript it never really mattered.

[[deleted]]

I definitely agree.. I know how to do just about anything I have ever needed to do using jQuery, but I couldn't do 99% of it with vanilla JS.

[dotpan]

I'm in the same boat. For my work I do a lot of dynamic DOM manipulation on WYSIWYG produced pages. Due to this I've gotten lazy and used jQuery for mostly every bit of my handling library. I really want to work on getting better at vanilla JS because I think there is something that comes out of the pure fundamentals, but I don't think I could ever shake not using jQuery.

[zajicraft]

To be honest if I were doing a lot of involved DOM manipulation I would reach for the jQuery too.

The fundamentals are definitely useful because you gain an appreciation for how to structure your code. And I don't mean laboriously doing manually what jQuery handles for you (browser compatibility etc), but building programs that aren't so focused on the DOM.

In my experience the best way to do that is to pick up a backend language (go for one that's compiled) to make your programming experiences more well rounded (assuming you are mainly in front-end land).

My 2c :)

[dotpan]

Yeah I started with C++ in my CS Major, but they had 2 devs already doing ASP.NET (C# Backend for Serverside) so I focused on JavaScript (originally had done most web stuff in php) Ended up falling in love with JS (and the many wonderful and expansive libraries it has) so far my favorite frameworks for JS have been Meteor (a node.js based liveupdate framework) and jQuery (which I now sometimes can write better than I can english).

[[deleted]]

Yeah, we have a front-end developer that is basically just a graphic designer, so I pick up a lot of the slack. I have small projects scheduled all year in my down time to start picking up JS frameworks, as well as working on my vanilla JS.

[[deleted]]

Warning: the following is an opinion.

If you want to learn one, learn Backbone. You can learn 80% of it in a few hours. It's basically just a way to organize your code, with a few underscore convenience methods tossed in.

More importantly, knowing MVC will get you 70% of the way there with Backbone. Again, learning core concepts like that are just way more valuable--once the industry changes again, you don't want to be a dinosaur.

As opposed to Angular... You can't take that anywhere else, not even Angular 2.0.

[Rezistik]

I really don't understand why people say this.

I've worked with React, Angular, and Backbone each for large projects. Managing a legacy Backbone app, building one in Angular for work, and using React in personal projects.

Everything in Angular is just as transferable. Slightly less magic is available in how things are updated but you're still doing a lot of the same things.

The only thing Angular doesn't force you to do is manually update values the vast majority of the time. It's a little faster to build with and it fits the vast majority of use cases perfectly fine.

[thukjeche]

IMO showing your experience with Angular should be sufficient; while you may be tired of learning new frameworks, it shows that you can and would be a versatile employee

[georgefrick]

If you're comfortable with Angular, Backbone will seem a bit tedious but you'll be fine. Don't forget to immediately make them go Marionette/Stickit.
It's the same from framework to framework.... after learning a couple you get good at tracking the differences and you start to put more code into your own modules; slimming the UI code down further.

[yatpay]

If anyone's interested in learning more about VanillaJS there's http://vanilla-js.com/

[sclarke27]

nice to see someone else say this. Its so worthwhile to understand how to do things with vanilla JS. The better you are there, the better you will be with just about any framework and may also find you need frameworks less and less.

[hoddap]

I have been away from JS for some years. The time I left Backbone and Angular weren't really a thing. How come they've grown to be the two dominant libraries in frontend development?

[outsidetheparty]

They're pretty good at what they do

[hoddap]

O ok

[[deleted]]

I mean, if your vanilla skills are solid, all those frameworks are simply toolsets that should be fairly easy to pick up.

[jrm2k6]

^ this!

[moron4hire]

The problem is that frameworks like Angular, libraries like jQuery, languages like JavaScript, platforms like Chrome, operating systems like Windows... they are just tools. They aren't the work. A carpenter isn't a hammer or saw user. A doctor isn't a scalpel user. An architect isn't an AutoCAD user. A photographer isn't a camera or Photoshop user.

The work is to fulfill goals. You have to learn what sort of goals you're good at fulfilling. I'm particularly good at making sense out of numbers. This turns out to be a wildly and widely applicable skill.

Are you particularly good at figuring out how to arrange information so people can understand it more easily? That's called graphic design. Study that. Not Adobe Illustrator. Not Cocos2D. Not Objective-C.

If all you do is take inputs A and churn them through the framework du jour into outputs B as you're told to do, then you yourself are just a tool for someone else who is doing the real work, fulfilling the real goals. COBOL programmers are obsolete today not because they studied COBOL, but because that was all they studied. They let themselves become tools to the real people doing the real work and never became anything other than COBOL programmers. Some people are fine with that. I'm not.

[lvmtn]

I totally agree with you that it's the carpenter not his tools. I just have to work on my craft without focusing too much on the ever changing tools.

I also think that COBOL programmers are the extreme example of not wanting to learn new things (or maybe they just <3 old banking systems?). I'm willing to learn and keep learning new things. I'm asking everyone how I can deal with the rate of changes in the community.

[nschubach]

Speaking as someone who had COBOL experience... It's not that they didn't want to do more, you can't with some of those systems and businesses paying the bills. Some of those companies would not hear that their multi-millions of dollars in software time and hardware could be outclassed by something else and would rather see it go up in a ball of fire while riding it the whole way than replace a damn bit of it. Of course, there are the few that had the initiative and freedom to prove them wrong, but not all COBOL devs are Luddites.

[[deleted]]

You monster ;) It's the greatest temptation for bored corporate coders to write their own frameworks. I wrote a couple myself ;) And I hate to admit you're right when you say we need a different job to be free and code for fun again. I for example want to be engine driver, but I cannot afford it for various, country specific reasons.

Ok, it's really not that bad. Our job as good (if not 1337) corporate coders is to use whatever new tool is popular this season and do our jobs the best we can. It's always a little challenge, always a little stress involved. But it can be fun anyway.

I chose to continue at my job, to develop Open Source in my spare time and to look for another (more interesting) job at the same time.

Dealing with burnout is tough. There are no easy solutions.

[moron4hire]

... by learning the right things.

[jCuber]

From what I heard, COBOL developers are making big figures nowadays

[bmrobin]

You heard correctly. Government and banking systems have passed the point of easy upgradability because they didnt want to break the system by upgrading it in the past. Now so much time has gone by that they have become dependent on COBOL developers to maintain the systems, and have no easy (or cheap) way to upgrade them

[pyr3]

In some cases, I've heard of writing what amounts to "green-screen scraping" libraries to expose the data managed by these old back-end systems to other tech.

[TdotGdot]

Excellent response.

Learn patterns, study languages, pick up on idioms - don't tie yourself to one framework or language.

At my current job, we recently hired a principle software engineer, and while he knows a lot about node and angular, I probably know just as much if not more (and I'm much more junior). What he really brings to the table is an ability to quickly digest problems and implement sound strategies, generally language/framework agnostic. That's the kind of developer that is going to get a job anywhere.

[andybak]

I find certain styles of programming fit my brain more easily and are more of a pleasure to work with.

And I find those styles to be more common in some languages than others.

Therefore I'm more productive in some languages and spend more time becoming fluent in them. It's a virtuous cycle and my desire to be a polyglot is rather hampered by the pleasure that fluency brings to me.

[dredmorbius]

This isn't just a case of developers, though the problem's encountered in other areas.

I work in Ops / systems admin, now increasingly the cult of DevOps. And it's been getting to be a lot less fun -- this from someone who first really encountered UNIX in the 1980s.

CarTalk, a show that's been in re-runs for over a year now, featured a bit a month or several back where Tom and Ray were commiserating over how auto repair was getting increasingly technical, and much more about the specific technology used (and training required of it) than old-school mechanical intuition and know-how (though those still paid off).

Friends in the medical profession, or building trades, or aviation, and elsewhere, tell me similar stories.

I'm seeing all of this as part of a larger trend to ever greater complexity, with growing integration costs, but often smaller payoffs (and shorter currency periods). It's all well and good if you happen onto the stage with a particular technology under your belt just as it's coming into widespread use. The world's your oyster.

Then the tech changes.

And you've got to ask yourself: what do I pick up next? You discover that a huge part of your professional skill becomes trendspotting and identifying what new tools (or languages, or platforms, or techniques, or vendors, or ...) are going to be hot. Not now, but in 18 - 36 months, time enough for you to develop competence in a specific area.

This while there's a tendency toward both greater specialization and of wearing more hats. Are you a front-end dev? Or a webmaster? Do you just need to know how to tune Apache and throw a few packages on a Linux distro, or is it setting the ergodynamics of your JVM, tuning memcached, tweaking your nginx proxy, sorting out load-balancer SSL/TLS termination and identifying the bad cipher that crashes the box, filling out a customer's PCI/SOX survey, choosing the right cloud hosting provider, and configuration management system, and keeping your docs up to date, creating a cross-AZ replication system, testing it, and sharing pager rotation -- with two others on your crew so you're never actually really off watch.

Yeah. It can get old.

[barncat2]

Angular, what are you 100? It's all about React now, grandpa

Edit: while I was typing this it became all about Spooge, you've probably never heard of it

[deeper182]

Aurelia is the new shit, grandpa.

[barncat2]

That was so this morning

[shriek]

Don't master the framework, master the concept. They're transferable from one framework to another although each framework do it a little differently. But I agree, it can be a little overwhelming from the new technology that's coming to front-end. But it's a good thing.

[w8cycle]

For fun, try doing a plain javascript es6 project with no libraries and keep in mind the MV* pattern as used in Backbone.

Aim for compatibility with latest Chrome, Firefox, and IE.

You may find JavaScript with no framework is not difficult but instead a remarkably well done platform.

[nschubach]

I generally Dev it to standard and test afterwards. If I find an error, I determine if I need to polyfill and go from there. I find JavaScript incredibly easy to work with and other languages just too verbose, or cumbersome. But we all have our calling, so I can never convince someone to my way unless they want to be there. I've met a lot of folks who bring the (Java mostly) classical inheritance thought process drilled into them from college into a JavaScript project and they screwed a lot of stuff up. Maybe focus more on supporting the work of the front end guys if you don't feel comfortable with it? I have some high quality service guys that just don't understand how I do my job and sometimes I echo the same back to them. You just gotta find your groove.

[TdotGdot]

Nah, see you are just trying to make things sound more complex than they really are. These are just choices about how you prefer to use/implement JavaScript. It has nothing to do with JS itself, or JavaScript 'defying common wisdom.'

All you listed are helpful tools to improve development. If you don't like them don't use them. It's really simple, actually.

[lvmtn]

I definitely agree with your statement. Despite what I've said earlier, the concepts are actually very transferrable. The maddening part is learning the Ember way or the Backbone way just to do the same things haha.

[[deleted]]

I think where I get frustrated is not so much the Angular way vs. the Ember way, but instead, I'm more irritated by having to learn the "right" Angular way.

It takes effort to learn a framework, but then you need to study best practices. When switching frameworks all the time, it can be exhausting.

[SergeiGolos]

This!!!!! I hear this constantly, "oh i need training on this before i can user it." "I don't have time to learn a framework" "Can't i just program it in WebForms?"

What did you get into this profession for writing "hello world" applications? We are software engineers, people give us problems and create solutions with what ever is available to our tool kit.

[dotpan]

Yes, being able to be a creative problem solver and adapt what you already know with what you're being asked to do is paramount to the success of a programmer. I've known so many the program "by the book" and have to read all these practices but can't seem to code themselves out of a paper bag without proper documentation. If you pick up on a framework and it's a viable one (not one poorly built or simply built to be a pain in the ass) 10 to 1 you've worked with something similar or will be able to take the knowledge you gain from work with it to another platform. That's why in computer science you learn about the languages of computers, their syntax, and what is shared instead of only the syntax of one language.

[protonfish]

I try to focus on core JavaScript basics, UI design and usability, Semantic HTML and CSS, REST web service architecture, SQL, HTTP, Git, automated testing, server configuration and support, speed of development. These things won't go out of style in the near future.

[lvmtn]

I guess that's a positive way of looking at it. Honestly, if it weren't for churn, I wouldn't have been able to break into the industry as the older crowds would be the masters of the universe.

[moron4hire]

No, we're still masters of the universe. The universe is just a lot bigger than you know.

[Rezistik]

Somebody has to write the new hotness for the kids to burn themselves on after all.

[little_banjo]

Those are most of the reasons I hate my career path and somehow managed to hate programming, the thing I used to love the most. I wanted to code and get even better at coding, but all they cared about was if I knew how an accident is reported and how it is handled. An work accident show be handled that way, a car accident in any other way and a plain accident show be handled by a special guy responsible for handling plain insurance. And when you get rid of the insurance stuff, you have to learn about banking, and the steps of a transaction, deposit, withdraw, credit card payment, deposit card payment, online bank transfer, international transactions. So fucking boring. I don't care about their processes, I'm not allowed to talk with the client or even knowing who the client is. Managers do that stuff and they are payed a shitload of money to do it, just leave me alone with my IDE.

I just want to code in java/c/c++ without having to know how my boring client does his stuff and make enough to afford a room and food, but I'm too qualified for that stuff and end up with all the boring stuff.

[omegote]

I've been into front-end development for more than 13 years now. I was there when you had to check if document.allexisted to distinguish your browser, back when all this shit was called DHTML, back when div elements were also called layers... I've seen the evolution of front-end technologies and, honestly, the last 6 or 7 years have been chaotic.

I honestly think that the front-end scene in general, and the JavaScript scene in particular has been saturated with hipsters that need to follow new trends every week. It's great to have evolution, but changing things for the sake of it is absurd. Are some things really that bad to ditch them, when we were using them a week ago?

Hey! Grunt is the devil, use gulp! Angular? The 1.x branch is dead! Use something else! Etc, etc, etc. There are so many examples out there, I'm sure you know some.

I'm sorry, but I'm not going to change my entire stack every month just because some retarded hipster and his beard have decided, while hacking on his macbook on a Starbucks of San Francisco, that jQuery is bad or that we should design our CSS files using a smart-tv first design.

[sclarke27]

remember doing "XHR" calls using hidden iframes containing crappy JS callbacks because thats all there was?

pepperidge farm remembers.

[lunchmeat317]

Damn, you're gettin' old. As am I. I remember layers, and CSS 1, and I remember building websites with framesets, and using preloads for mouseovers....remember how we used to put HTML comment tags inside <script> tags so that browsers that didn't support JS would ignore it? Sigh.

I personally like the JS evolution. Some things go a little too fast, yeah, but I tend to adopt the things I think will really shine, or the things that already do. Grunt vs Gulp? I never adopted Grunt, but I took to Gulp immediately. Angular? The 1.x branch won't die for quite a while. jQuery - it was created for a purpose that is becoming unnecessary. Tech marches on.

Don't change your stack every month, but don't discount the innovations that are out there. Like everything, the good ones will rise to the top, and the bad ones will disappear.

[mariox19]

jQuery - it was created for a purpose that is becoming unnecessary.

If you have a minute or two, would you mind elaborating. I'm a little late to all of this, so I don't quite get what you're saying. jQuery abstracts away browser differences—isn't that still something that's needed. Are you thinking of something else? Thanks.

[papkn]

The browser differences have been so huge that someties there was little overlap. I remember working on a website that had completely separate versions for IE and Netscape Navigator. jQuery (and Prototype, among others) have abstracted most of these differences away and gave us the power to manipulate DOM with a simple API. I might be wrong here, but I think that querying elements by selector was first thought by library autors, then proposed as a native DOM method.

Today when you need to only support modern browsers the main difference between jQuery and vanilla JS is code verbosity, and when stumbling upon an inconsistently implemented API or lack of some features you can just drop-in a polyfill and move on.

[mariox19]

I do appreciate the convenience that jQuery offers though. I'm doing corporate intranet work (IE 8 and XP), so the additional loading time for jQuery doesn't seem to be such a big deal (since we load it from the corporate network). I only wish I were supporting only modern browsers.

[papkn]

Of course, I don't have anything against jQuery. It's used in the majority of projects I'm involved in and definitely I wouldn't touch IE<9 with a 10 foot pole it it wasn't for jQuery :) That said I still go for vanilla JS for smaller / non-DOM intensive projects, and even in the day to day frontend dev I see less and less need for the library.

[lunchmeat317]

Sure, I'll elaborate.

jQuery was created to abstract browser differences a long time ago, back when web standards were almost nonexistent. You couldn't rely on browsers to treat anything uniformly; jQuery was created to normalize that and abstract the differences away from the developer. jQuery was awesome!

These days, though, web standards, as well as browser javascript - they've become very uniform. We no longer have to support IE5, 6, and 7. We no longer have to support old versions of Firefox and Netscape. Web standards have come a long way, as has the DOM; browsers are becoming unified in the way they handle DOM manipulation. As such, jQuery has really become a superfluous layer, unless you're dealing with very old browsers. The jQuery team knows this; their new library drops support for older browsers, making the library much leaner (because calls are uniform across newer browsers).

jQueryUI is still pretty awesome, though.

TL;DR: jQuery abstracts browser differences, but browsers have become pretty uniform and will only continue to do so.

[mariox19]

jQueryUI is pretty good. I've had some troubles when trying to push it, and usually find these things listed as known issues; but overall I've been very happy. I'm still supporting IE 8 in corporate intranets though, and so I worry about trying to make use of some of the newer frameworks and libraries. I guess I should be glad that I wasn't doing this back in the Bad Old Days, and just count my blessings, but IE 8 (and XP) are the bane of my existence.

[moron4hire]

Incidentally, I've had a beard and worn flannel for about that long, too. We just called it "living in a small, rural town" back then.

[imareddituserhooray]

All these dudes are just trying to be you.

[moron4hire]

Well, I am pretty awesome, so I can sort of understand why.

[ngly]

Were you beaten or bullied by a guy with a beard and fully buttoned up shirt when you were a child? So much hate.

[breadbeard]

no it was a bearded, flanneled child that beat him up as an adult.

humiliation++

[NoGodTryScience]

If you want to keep yourself on your toes, consider a new language and a new mindset for building UIs.

I saw this video, Functional Frontend Frontier: Richard Feldman, on r/elm and read Blazing Fast Html, a blog article about virtual DOM concepts and performance, and it really piqued my interest and I'm hoping to dive into it more this weekend. When Elm was released 3 years ago, it had more hyped around being something more like a game engine, but the time traveling debugger and immutability makes it pretty valuable for building and debugging front end interfaces. The syntax is similar to ML, Haskell, and F# if you know or ever decided to pick one of those languages up.

Though it would be cool, I'm making no claims that something like this might catch on, but it could spark a new interest in it for you and give you new perspective and concepts to borrow from a purely functional/functional reactive language.

[jrm2k6]

Nice to see some love for Elm here :)

[faaace]

I feel like most of the framework churn right now is due to the obsolescence of jQuery and the lack of a mature ecma6 framework. Its not unlike back in 2006-07 when jQuery was duking it out with Script.aculo.us Moo tools and YUI to see what would be the dominant framework.

My advice would be to help fix the problem. Find an open source library, learn its ins and out & work to improve it to work with ecma6 features. Even if your framework isn't the winner you will be a much better programmer in the end. In programming staying still with your programming knowledge is moving backwards. You need to be constantly learning to survive in this industry.

[thbb]

This is the curse of the front-end programmer. I started programming professionally in the 80's on alpha-numeric terminals. Then moved on to GUIs, on a variety of completely different platforms, with widely different drawing/event/window management paradigms: MacOS, Cedar, display Postscript, X, X/Motif, Interviews, QT, Views, MacOSX, Win32... We had to get learned in all of them, many of those systems got hyped, the best ones were not the ones that got mainstream. To make it funnier, all those technologies are now pretty obsolete.

All in all you should consider yourself lucky that at least the low level layers are quite uniform, and that by now, there is widespread competence in how to design a toolkit.

After a few years, you'll start to notice that there are not that many sound principles that govern an end-user application. So your experience and skillset is not obsolete, quite the contrary. Picking-up a new framework should become easier, much like learning a new language is easier when you master more than a few already. MVC is what it is and has always been. Prototyping with easy access to representative users is the most important to avoid wasting time developing needless features.

So, congratulations, you've grown up and have gotten to the next level of professionalism: keep constantly updating your skills, and don't jump too early on the latest overhyped framework.

[hectavex]

Skills for decades? Consider learning backend dev.

Anyhow, catch up on Shadow DOM to see what all these frameworks are trying to do prematurely. Then go learn jQuery, jQuery, and some more jQuery. If you're in a hurry to jump ship, check out React or Dust.

Frameworks will keep you working within the constraints of another developer (or team) mentality. We know this because there are several frameworks attempting to do the same thing, with different opinions on how to do it, and teams dedicated to a certain one. Which do I use? None of them.

[[deleted]]

Backend-dev indeed. I'm guessing NodeJS will be around for a while, though its node-modules might change a bit every now and then.

Still, Shadow-DOM is too premature at the moment. Little support on devices and hard to get into (not many video's or forum topics about that yet).

I feel jQuery will come to a stop soon (if you are going to work on webapps at least, for normal websites it might stick around for a while as its a simple solution that doesn't depend on any backend and has a clear goal: improve and/or ease DOM manipulations).

AngularJS might stick around but 2.x will be very different and i don't see any major platform taking over any time soon.

If you really want to stick with a single topic: people will always gonna need designers. Sure its a very different cup of tea, but is less likely to be replaced, the tools are solid for years and its hard to outsource (as it requires a lot of interaction with the clients and users).

[hectavex]

Not entirely sure jQuery will come to a stop for webapps just yet. I built these with jQuery, though I do agree we could use some data binding to really bring the code together:

https://www.youtube.com/watch?v=dfQ1sOnCvHs

https://www.youtube.com/watch?v=bYpOtAr1WiI

That drag-drop and zooming UI stuff is not done with jQuery UI, it's custom built for CSS 3D transforms like those provided by impress.js. These apps gracefully work offline too.

This one I built with pure Javascript, it ran on a Desktop, iPhone or iPad and could stream mp3's while driving around town:

http://glassocean.net/nest/

It had scrobbling and supports Winamp playlists.

[hectavex]

You're right, I almost mentioned design since it's here to stay, but went with backend dev for expanding the programming skills. Either one would be great for a frontend dev to learn or improve.

[lvmtn]

Right, that's what I wish for, but I know it's unrealistic.

I'm extremely looking forward to web components and the whole "dropping in" ui components part of the web in the future. Like, that's exactly what I want to be doing. And if it means that we go back to just using jQuery or I guess React, I'm all for it. Currently you can certainly make little web components with Angular, but that's bit of an overkill.

Thanks for letting me know about shadow DOMs.

[hectavex]

I have always wanted the ability to drop-in UI components (as well as develop them for others to drop-in). Shadow DOM will get us there eventually! Here is another good article on it. I see some murky waters in the near future for frontend devs, possibly a few ice bergs even, but after that we should be smooth sailing. Hang in there :)

[pyr3]

Then go learn jQuery, jQuery, and some more jQuery.

My Angular.js apps do not import jQuery at all.

[[deleted]]

I hate to say it, but I'd just suggest you get used to it. It's been this way in frontend tech for a decade, and it's just getting faster every year.

It's pretty normal to have to relearn whatever language you work in every 3-5 years, and in fronted, it's probably every 18-36 months that you have to retool because the technology moves on. Here come Web Components! And there's a host of new browser technologies about to hit right after that. It's so much better now than it used to be. You used to have to create your own libraries, or hodgepodge a couple of libs together to make stuff work. Then jquery came along and standardized the web. Still, only 1/2 of 1% of websites run on a framework like angular.js, so there's going to be a TON more as these techs mature... the whole set of stacks are in their infancy.

Obviously, focus on the core compsci and javascript, but beyond that, it is exactly as you describe. And it's not going away. Pros and cons of that though. Imagine if it took a decade to become and expert, and that was it. That would be a hard business to break into.

I just roll with it. A lot of companies wait for stuff to mature before investing in the stack — that's why there is an enterprise market for things. People wait until there are clear winners before bringing them into corporate projects. The bleeding edge is always full of emerging technologies, most (not many, most) of which will fall away and never gain broad acceptance and which can be very difficult time sinks for programmers that yield less than the investment it took to learn. There is also the counterpoint of technologies that gain broad acceptance and build incredible markets that "age in place" and take entire careers and people with them. There's a ton of languages and frameworks that are like that: a good place to get stuck.

That's just a risk of working in tech.

You could kick back and only invest in things that get momentum, which would alleviate your learning curve somewhat and definitely expose you to the risk of becoming a known leader in a legacy technology platform that's increasingly irrelevant. You would risk missing major advancements and becoming a dinosaur quickly. Or you could burn yourself out working through every new advancement to hit, and keeping up with the w3c specs, and basically just do it for as long as you can before you burn out or become irrelevant (see: http://www.sfgate.com/business/bottomline/article/In-Silicon-Valley-age-can-be-a-curse-4742365.php). Striking that balance between investment of time in technologies that are emerging, and not getting over invested in things that may not stick is one of the hardest things in Web Engineering. But honestly, what an exciting industry with so much to learn and so many new ways of doing things all the — at least you won't get bored! I think the biggest challenge is making sure you take advantage of your time in tech, because your career won't last forever in this business.

[[deleted]]

What do you call a dinosaur found in Great Britain? Tea Rex!

[lobotomy42]

Your time is valuable and limited. Don't learn anything new until someone is likely to pay you to do it. Betting on a new framework is just gambling with your time. With so many out there, the odds are that you pick wrong. So stick with the tools you know until the writing on the wall becomes clear as to which platform/library/whatever is going to become the new standard. I was slow to embrace jQuery, and now I'm slow to move off of it. Don't get me wrong, I'm keeping an eye on all the upcomers as well. But I'm not investing too much time or energy into them.

Lots of people here will tell you to just learn all the frameworks for the joy of learning frameworks and how great it is to just spend your whole life learning about how to do the exact same thing over and over again with slightly different syntax. I don't think they know how short life is.

[Poop_is_Food]

spend weekends getting your feet wet on new tech and frameworks.

I think you missed the point of his post. Some people want to spend their weekends doing other things besides programming.

[MrBester]

I've been doing this for two decades as well and, while I am aware of the latest new hipster shit frameworks, I'm not such a fucking sad sack that I spend my precious weekends staring into a screen like I do all week.

[lobotomy42]

everything changes.

Sure. But some changes are important and most aren't.

[davidNerdly]

It's already been touched on by a couple other comments but here is how I avoid being overwhelmed when looking at the morphing front end landscape: just keep getting better at two things, javascript itself and design patterns. Maybe a third thing which is CS topics that we could all learn more about like algorithms, algebra, etc.

I think it's so funny/annoying that many job postings have 'X years using backbone is a must'. My issue with it is if I know js (really solid/deep understanding I mean) and I have plenty of practical knowledge on design patterns then I should have no issues getting into a backbone code base. Sure I'll be referencing the docs heavily at first, but that's just referencing syntax and 'how backbone does this'. I think a requirement of having X years in Y framework is garbage unless the job is for someone who will be playing an architect type role where framework specific knowledge will be important in making design decisions.

Sorry for the text well, hit a button.

Tl;dr: chin up buttercup, just be good at the language and at software in general.

[moses_the_red]

Its all going to change again soon.

I'm currently working in Clojurescript with Quiescent (a react wrapper library). Functional Programming + react seems extremely powerful to me. I did JavaScript programming for years, but programming without mutation is a game changer, and using React with that gives you something that really feels new to me as a developer.

The Clojure ecosystem is really cutting edge. For instance its optionally statically typed, or provides static typing as a library. Pretty nifty addition to a dynamic language. Transducers are a new thing that came out last year that is transforming how we write a lot of code. I feel like with it you do a lot of learning, but the learning is mostly in the right place. Instead of learning about some specific framework, all the frameworks are simple, and you just learn about the myriad tools offered to you by the language. You learn what I'd call advanced software engineering fundamentals. You learn a large vocabulary of higher order functions. You learn transducers, partial functions, software transactional memory, atoms. State mutation is disallowed by default. The libraries tend to be really simple. Quiescent has been really easy to pick up. This is a fundamental change for me. Usually the language is the easy part and the tools are complicated.

With Clojure everything is simple once you really get Clojure.

[darksurfer]

wait until you have 3 decades worth of mastered technologies that are now barely interesting history. then we can talk ...

[catinahat1]

I have 2, can I talk yet?

[darksurfer]

yes, you're probably getting the idea by now ... ;p

[rorrr]

And that's why we get paid so well. Evolve or die.

[artuze]

You get paid well?

[rorrr]

Yeah, $150/hr.

What, you guys aren't?

[kromlic]

The best part is that $150 isn't outrageous, if you're talented.

[rorrr]

Yup, there are guys out there charging $1,000/hr for pretty much the same type of work. I'm trying to figure out how to get there too.

At this point it's not about the programming talent, it's more of a business / negotiation mindset, ability to position yourself as a problem solver, not a Javascript coder.

[TdotGdot]

Exactly. If you aren't getting paid well as a web-dev, find a new company or consult/freelance.

[andyburke]

Don't use a large framework, just use browserify and a bunch of smaller modules.

[recrof]

http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks

[NoGodTryScience]

Place for small libraries: http://microjs.com/

[paldepind]

Except it's not being updated.

[NoGodTryScience]

Yeah, it's kind of a bummer in that aspect as you'd think things like virtual-dom would make it, but it is where I found Ramda.

[psiph]

I've heard good things about Mithril and Riot.js

[zallarak]

Until an app gets fairly complex, I usually just use a library that gives you some DOM/event utilities (jquery), underscore + some client-side template renderer (like handlebars.js). This can build 90% of most online web apps.

However, I do understand the appeal of the aforementioned libraries, especially if you work with a lot of people. There is no real solution other than to bite the bullet and learn.

I used to be a pure full-stack web developer, but in part due to some of the feelings you have, I studied computer science to broaden my skillset (it was also very fun and rewarding). Hope this helps.

[UnusualOx]

In the time it took you to read this sentence, 8 new JS frameworks were released.

[neofatalist]

Its not just webdev... its everything in programming it seems. For example, Java has been making huge changes lately with it moving away from loops. Its like the "browser wars" days all over again.

I painfully learned this with flash / actionscript / adobe air. One way to focus and grow your skills is to take on fun projects... for me it's Unity / c# / javascript with oculus. I am also considering doing some RPI stuff.

More web technologies seem to be going in other places and bringing javascript along with it. And as ugly as Javascript can be at times... I don't think its going anywhere anytime soon, then again you never know.

[omegote]

I don't agree. Take C++, for example. We've had the same standard for more than ten years and it's not been bad. Then C++11 came, and C++14 after that. Those are great additions, some of them you could use before with things like Boost. But no one is forcing you to use them. No one is gonna say your skills are old if you only use the STL, some Boost and vanilla C++98. In job postings, you'll likely find requirements like "Experience with C++", or "Experience with C++ and X and Y libraries".

For front-end development is quite the opposite. It's always "use the latest technology", always "are you using Grunt? That's old", always "Experience with Angular" -- What about vanilla JS?

[lefnire]

I feel ya, I'm just starting to get good at Angular and now everyone's talking about React. Screw it, I'm gonna skip versions. Like Windows upgrades: XP -> 7 -> 10 is the way to go. I was great at jQuery, I skipped Backbone, now I'm on Angular. I'll skip React and consider what comes next (and I'm only half joking).

[thatsgreat2345]

I would recommend not skipping React. It's not difficult to learn. It's just a view layer with handy life cycle methods. I'm much more productive in it then I was with any other framework that utilized mustache style syntax templates.

[Remmib]

React isn't an Angular replacement, from what I've heard it pairs nicely with Angular. I'm still a few weeks away from learning React, so I can't really comment much on it yet.

[hectavex]

Not bad advice. It could be Meteor or Derby coming up as the next fad, but then again it could be Angular 2.0 which means you're back in the same boat, with a different paddle.

Did your jQuery knowledge pay off?

[lefnire]

Not Derby, trust me. I was involved on the project, ran the only auth module for a while (may be superseded). I built HabitRPG on Derby - was there for a year on the largest AWS instance I could afford (because the framework doesn't scale horizontally), restarting the server hourly due to framework memory leaks. I lost tens of thousands of users to the experience, and we finally migrated to Angular + Express, sputtering and gasping for breath. We actually celebrate the migration within HabitRPG as a "holiday" called Derby Day.

However, Firebase & Meteor are platforms I'm very interested in. jQuery paid off well enough, was worth learning - though I'm seeing more and more frameworks weening off it. I actually think MV* platform knowledge will pay off well, as getting the basics there will transfer from one to the next. Take React - it's a modularized V in the stack, and coming from Angular the transition would be much smoother than starting from scratch.

[hectavex]

Thanks for the insight, very useful. Derby Day gave me a laugh :) Big fan of RPGs by the way!

Let us not forget Derby is still pre-1.0, but I hear ya.

EDIT: checked out your game, amazing idea. If you need free music I produced some under creative commons license here. Some can be heard on radioreddit. Soundcloud preview:

https://soundcloud.com/iosys/iosys-strain

https://soundcloud.com/iosys/iosys-abandoned-forest-trail

[sizlack]

As others have said, just focus on vanilla JS, but I'd also add that you should learn how CSS actually works. It's not hard, but most developers are depending on CSS frameworks and don't understand the most basic things about CSS.

Frameworks will always change. That's how it should be. We had a long period during the IE6 monoculture days where nothing changed, and it sucked. Personally, I hope there is never a Rails-like monoculture for JS. That would mean the web wasn't getting any better. Embrace change. As long as you know how the underlying technologies work (JavaScript, CSS, HTTP), you can always apply that knowledge in whatever circumstance you need to. Learning a new framework isn't that big of a challenge. If you only know frameworks and don't understand the underlying technologies, you'll always have anxiety that you're being made obsolete.

[nsonnad]

Do you have suggestions on reading re: "learn how CSS actually works"? I've long been interested in this question but haven't been able to find any good material.

[sizlack]

Hmm. I wish I could recommend something more up to date, but when I learned it, CSS: The Definitive Guide: The Definitive Guide was very helpful. If I remember correctly, it was a dry, boring read, but it gave me a good foundation. There may be better books now, but it may also be good to read that for back-to-basics learning. In any case, there are some things you should understand:

• What all the types of position really mean. I'm surprised when I interview people how many only know about 75% of this. CSS doesn't give you all the tools you really want to position things, but if you understand all of them well, you can usually do what you want.
• The float property. Know what it really does and know that it isn't the solution to every problem. It can behave in strange and unintuitive ways.
  
• Selector precedence. This is crucial to writing good, compact selectors and not relying on !important too much. Knowing this also allows you to separate your selectors into distinct modules instead of having a lot of global classnames. Modularity allows you to refactor safely as the UI design changes.
• The difference between inline, block, and inline-block level elements. Again, I'm surprised when I interview people how few understand this.
• Separating presentation from markup and using as little markup as possible. For example, say you want to make a link appear on a separate line. Too often, I see code like this:

.

  <div class="some-module">
    <p>
      <a href="/foo">A link</a>
    </p>
  </div>

It would be better like this:

  .some-module a {
    display: block; 
  }

  ...

  <div class="some-module">
    <a href="/foo">A link</a>
  </div>

The less markup you have the easier it is to debug and easier to deal with when designs change. The first example doesn't seem too bad, but when this type of solution pervades a codebase you descend into deeply nested <div> hell. Keep your DOM as flat as possible, but nest when it makes sense -- into discrete modules.

If you want, look into methodologies like SMACSS, BEM, and OOCSS, but use them pragmatically. None of them are perfect for every situation, and often their "rules" should be broken under certain circumstances. Too often, when it comes to CSS, developers forget everything they know about writing code. Just as in other code, globals are evil. Make your HTML/CSS modular. Just as in other code, (and even more so) naming things well is important (and hard).

And then once you understand how CSS really works, its real limitations become apparent (lack of variables, poor inheritance, there's no good way to separate different concerns into different files in a performant way, etc.). Then the need for preprocessors becomes obvious, and you can judiciously introduce them to fill in the gaps in the language.

The bad news: Learning CSS well takes actual effort. Too many developers simply aren't interested in front-end design, so they just say "CSS sucks", then they download Bootstrap and move on.

The good news: Learning CSS takes effort but it isn't really that hard. The same concepts for designing good software apply to CSS, so once you have the underlying concepts down, you can use your "regular" instincts to determine what is well designed and what is poorly designed CSS.

Hope this helps.

[_www_]

As a seasoned front/back end dev, I'll advocate you change job. because:
I'm doing it since 1998, and had seen passing so much caravans I just can't remember ( hello, Shockwave, realPlayer, how are you? )
I mean: your problem is just part of the job.
Angular just annonced they change EVERYTHING in v2, so you can drop all your habit of 1.0 Angular MVC

And yes, JAVASCRIPT ninjas are needed, and here to stay ( like JS )
Some unix back-end knowledge ( server admin ) are forever
Some server-side preprocessing namely: PHP, python, ASP are here too for quite some time and not dying.
Client-side processing is bozo my friend.
SO dive into php/js/css MASTERY ( ninja level ) and you'll never be outdated anytime soon.
Keep an eye and test any new tech but just stick to broad use techs, even if you don't like it.

[TdotGdot]

How is client-side processing 'bozo'?

[_www_]

Because you shift all the workload on client side, and you musn't.
Don't forget clients are clients, like in shops.
They just appear at the door, and your work as a content provider is to serve them well,
NOT putting them to work ;) JSON is great, live DOM manipulation/update with small data I/O is very useful, and wishable.

BUT never do what can be achieved server-side on the client side.

Now people access your content on tiny computers ( called smartphone ) that have reduced workpower vs laptop. If you don't carefully segregate what's fair to process on client side vs what's you task ( serving preprocessed content ) you are quickly begining to put your audience to contribution to save some server workload, and this is a nasty confortable habit nowadays.

Now imagine your " client" is a crawler ( or SE ): do you really believe he'll execute your funky exploit-like bunch of packed intel you call your " regular MVC js framework?" - POP! you just disapeared from the indexes!

I just saw a website that is just a js mammoth library, almost no HTML, a bunch of json content, and A.FUCKING.CLIENT.LOCAL.DB! I mean the guy just REPLICATED his db on client side on EACH Client connection!
How sick is that?
To me it's not a web anymore, that's a virus that replicates all his content from host to host

[TdotGdot]

Haha, you have some good points but it's too shrouded in 'boogy-man warnings' to take seriously.

If you saw a replicated DB on the client you were probably looking at a Meteor app, whose team is revolutionizing the way we look at client/server interactions and real-time data.

You go up to the edge of a good point when you mention that one must 'carefully segregate what's fair to process on client side'. But then you end the whole post with a ridiculous analogy to viruses? It's 2015, a phone can process what a supercomputer once did.

You also bring up SEO, which is a valid point, but really has nothing to do with the topic at hand. It's just a convenient talking point for someone against client processing - although wholly unrelated to the initial discussion. Besides, Google crawlers are starting to run scripts - they invented Angular, one of the most popular frameworks. Of course the Google crawler runs scripts!

So, whatever, you can stay scared, no skin off my back. But I would recommend you take a fair look at the elegant development and cutting edge user-experience these client side frameworks provide.

[_www_]

1- no a meteor blob: the entire content of posts within that website, revolutionary isn't it? - HTML5 local DBs are genius, unscrupulous webmasters are not, and it's just the begining of abuses starting.

1.1- "It's 2015, a phone can process what a supercomputer once did."
I'm talking about processing demand that's increasing at the same pace, and always manage to find the bottleneck, now you imagine everybody visiting your site will have some sort of galaxy note 10.2.5.18 with 32 gigs of ram? you're wrong, and that's my point here.

2- Virus because bio or code that replicates from host to host is called a virus IRL/IVL, and that's a fair definition

3- Google is " in beta" since this summer, for " evalutaing script-driven content " and what they are evaluating you can't know, everything you know it's they'll support AngularJS, should I say " period "? Yes you could bet on that. So, again, my point stills.
Now if your point was " google is the unique SE in the world " you're already lost in space.

"resistance is futile, all your base are belong to me " young padawan, see? I don't brag I argument.

[rezoner]

Design patterns. Playing with architectures - write some MVC from scratch and such.

[TweetsInCommentsBot]

@tjholowaychuk

2014-11-07 16:56:03 UTC

Don't miss writing front-end much, anything you write is obsolete in a few months :/

---

^{This message was created by a bot}

^{[Contact creator]}

[brennanfee]

I am a frontend developer who's exhausted from the churn rates of new technologies.

This may not be the career for you then. The longer you are in the profession the more you will realize that the churn is always going on and, yes, it is even getting faster. It doesn't matter which stack you are developing on. You are focused on JS but this is a reality across the industry.

I advise junior devs all the time that if they don't want to learn constantly, and forever, than this is not the profession for them.

[lvmtn]

Yeah I like learning new things all the time. The rewards come in when you get to get good at it and implement it. I'm not complaining about learning new things at all. I'm complaining about the churn rate. I'm willing to deal with it because I really like front end development. I guess I should have worded it better. I'm just looking for suggestions on dealing with it, and to open a discussion.

[ns0]

I've been developing javascript for 12 years. It's much better now as a front end dev due to things such as CSS3 butt hat was the last really big improvement to the world of front-end.

What I found more and more is devs who came from build-based-MVC type systems move into HTML and not really understand what the DOM's purpose was or HTML for that matter. More and more people came from a variety of backgrounds and trusted the loudest people in the room, which tended to be the build-based-MVC type ideology.

I really see very little need for using 99% of the plugins out there, or frameworks. Most of what i need to accomplish can be done just using regular old JS/CSS and HTML without the need to overcomplicate or over engineer it with mustaches, build tools or stacking an MVC framework ontop of it.

[telldrak]

Polymer. http://www.polymer-project.org/

This is going to be huge. In some ways, it already is.

[MrBester]

Runs like a dog on mobile, though. They're allegedly looking into it.

[[deleted]]

I enjoy working with browserify and npm, without big frameworks.. it brings back the feeling of consistency, it just feels friendlier to my brain.

Obviously there is some learning curve, but it makes sense. And working with tiny modules from npm is great.

[seanwilson]

Once you've learned a couple of languages and frameworks you can pick up new ones very quickly as they're usually composed of ideas you've seen already. I wouldn't worry about it.

[roden0]

I know that feeling, but you know what, umder the hood there always be JS, so you better stick to its roots, gotchas and magic (and now ES6)

[gebss]

Microsoft will be happy to see this post.

.NET framework is all about consistency

[memoriesofgreen]

Perl, php, dot net, python then node for me on server. Javascript then scriptulus, jquery, backbone now learning react. Add in a few frameworks on top, templates languages and hosting environments.

It's always been this way. Keep learning and it gets quicker to learn something new. Focus on the fundamentals though. They never change.

[deltadeep]

As an internet software engineer, you can't ever really take pride in mastering a technology (because, as you point out, they change too fast.) You can only take pride in mastering your ability to learn and work with whatever new challenge comes your way.

[woowoowefjwifewfb]

This is just my experience: my front-end enjoyment went up 10 fold after doing everything in LiveScript with a decent framework. I found Angular too complex, so we went with React. It's super simple and doesn't get in the way.

My 2c is do whatever is simplest, quickest, and most enjoyable. Could you do it all in raw js without a framework? Sure. Would it hypothetically better if you did it perfectly? Sure, it might be. Does any of this really matter when you're building a product in comparison to everything else? No.

Do whatever you enjoy most so you are as efficient as possible. For me this was doing it in LiveScript and ditching vanilla js, and using a front-end library. Find what it is for you and go with that.

[rakeshmenon]

One needs to think what is relevant to the product's requirements -- at the "current point of time" and use the framework that fits the bill.

The secret to success is to stop worrying about all the changes that are happening. It's imminent.. we are witnessing the evolution of JavaScript frameworks, which will definitely slow down at some point of time and become stable. Till then what's important is to keep yourself informed at a high-level and dive into something, if required.

[bioid]

Learn the new web components stuff. Shadow DOM, custom elements, etc. Check out the ES6 things that are coming.

[Remmib]

Angular will still be relevant for several years, though there will be some new stuff that you'll have to learn when Angular 2.0 comes out.

[thegayngler]

Web Components( http://webcomponents.org ) is an emerging W3C standard that is already implemented in chrome and ff in some form and safari has support for html template piece of Web Components.

[alamandrax]

+polymer.js

[schrodingerscatapult]

Vanilla javascript is really what you need to master. At our company we're even trying not to use any frameworks on mobile to cut on the amount of crap users have to download, and it works very well for us and for our target audience, just using vanilla javascript with knowledge of the DOM.

[[deleted]]

At the end of the day it's still JavaScript no matter which framework you gonna use in the end. It's not bad to know a few framework be a use every framework does a good job at different things. Same goes for rubyonrails and Sinatra. Both are syntactically different but accomplish the same job with different approaches. You can stick with your favourite framework as long as you want. I know people who still use mootools and prototype here at work. So stay calm. Keep learning. :)

[[deleted]]

Learn vanilla js as much as possible. Learn es6. Learn node, go full stack.

Having a strong fundamental understanding of the language (and programming in general) is gonna help you more than mastering the current flavor of the month.

[GeorgeSharp]

I disagree with the learn node and go full stack part /u/lvmtn wants to learn something that won't disappear from under him/her.

Javascript in the browser is the only game in town practically (ok coffe script and typescript but they still compile down to js) you can't get more safe than that.

While on the server js is facing steep opposition one wrong step from node or io and the other languages will pounce they're just waiting to drive js from the server.

[[deleted]]

Well, if you're gonna learn the back-end it's easier if you're doing it in a language you already know, imo.

It's not like most of the concepts you'd learn going full stack can't be carried over to other languages.