This is pretty much why I don't do front-end. I'm fully capable of it, but I just don't like keeping up with this flavor-of-the-week. It just doesn't feel like programming to me, or at least not the programming I enjoy.
Strangely, I see so many new developers rushing toward the front-end, which seems much more complicated in many ways than just building solid web API services, analyzing data, etc.
I laugh when people doing web work say native is the horror show, the last bit of "churn" I had to deal with was figuring out if JavaFx would be the new Swing, and that pretty much sorted itself out...
After a few years with a framework, for all it's worts, you know it inside and out, limitations and all, and you can work around them. For web stuff it feels like everyone excuses having a million and one solutions by shrugging it off and saying "figure out your problem then find what works for those problems". The issue being there are N frameworks for my problem and I only know N/2 of them well enough to even start evaluating if they solve it, and if there are limitations a new feature comes up against, I'm back to square one in searching for another little tool for this new requirement.
There's something freeing about only having a few solid tools at your disposal, vs a million smaller ones with divided mindshare, even if it can be limiting.
The toolset itself has the weirdest gaps. You can get to 80-90% of a website design really quickly with the standard angular+bootstrap or whatever. But when a client wants it to do "Feature X" that is in one of the gaps then you're stuck spending hours trying to either hammer the problem into one of the frameworks or roll your own solution. And it's very hard to explain how "Feature X" took nearly half the time of standard "Features A-W".
I don't think that it's fair to blame the frameworks. You should see it the other way 'round: They save you 80% of your time. The 80/20 rule is real (https://en.wikipedia.org/wiki/Pareto_principle), 20% of the whole work needs 80% of your time.
If you have problems explaining why features need their time, it's not about your frameworks, it's about explaining the clients in all honesty what happens. Or, if you want to get paid enough, you simply factor in some risks into your budget planning and up your budget. They don't have to know that you only needed 2h to get nearly everything up and running and 6h for that one sneaky feature. Use asymmetric information (https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...) to your advantage. It's not about the toolset, it's about your mindset.
I have to disagree. In my experience, the frameworks get me to 80% completion but I'm not spending the next 20% on achieving completion. I'm spending orders of magnitude more than that fighting the framework, trying to make it function the way my product needs to function.
In other words, all of the time saved to get to 80% is lost, and then some, because the framework can't do what my project needs.
I've seen this time and time again, with every framework I have ever used.
I've used Ember.js in the past and must admit that it got in the way and the whole team was magnitudes slower than it should be, although I would also see the bad codebase we had to build upon was a big factor of this, so I can relate to that.
But I've never experienced this problem on projects where I'm able to choose my tools. I use Django and Vue.js with webpack and I can estimate the time constraints for each feature accurately using that stack which is most important for me.
Maybe you've used too opinionated frameworks in the past. If that is the case, loosely coupled frameworks like ampersand.js or very flexible solutions like Vue.js will be a pleasure for you.
In regards to the Pareto Principle: The 80/20 rule means that you need 80% of your time to finish those 20% outside the scope of your framework, not 20%, so your observation fits with this.
It's more like spending 20% of the time on 80% of the features (the standard ones), then 80% of the time on 20% of the features (the details, hard stuff and integration).
It's not about "blaming" anything. But the fact is that software development is much harder to make an accurate estimate for, in many ways, than a highway project and this is because the tools we have available to use are not as mature as they could be.
Fair enough. I've hit a sweet spot now in having done Ruby for ~8 years, so I can get away with saying, "having someone else deal with the front end. I just want to talk about data".
The new problems I'm working to learn to solve are with ML, NLP, etc. I'd like to step away from web services completely soon, and just live completely with data.
I am curious, how did you transition into ml, nlp. I am thinking of transitioning to ml, as work is getting kind of boring for me, but most job requires at least a master in the relevant field. I am self studying right now, maybe going back for a master, but I felt I lack alot of necessary probability and linear algebra theorems. I can code svm, neural network from nothing. I understand basic markov chain, bayes network, but that is really just scratching the surface. Any recommendations?
The 2016 ml scene doesn't seem so different from the 2016 front-end wild west I gather from this thread. Unfortunately. Machine Learning is in rapid flux, the solid theory of svm and the like are getting abandoned for a lot of techniques that seems to work some times. Certainly some people have a very good intuition for what works, and how to make it scale, but there is no one authority and you have to keep constantly up to date.
I'm in the same boat. I'm no longer interested in the plumbing, much more the type of questions that can be answered with large scale data, and other types of efficiencies that are dormant with 'pure' code.
For a developer role, and in the context of web applications(CRUD-ish) what do you think is the ceiling potential (in terms of earnings) Comparing JS/frontend positions vs backend development?
I don't do that type of analytics, but what I can see is that's it's quite hard to hire a good FE guy.
Backend can be hard as well when looking for specialized stuff like Elixir, OCaml, Scala, Rust, etc. On the other hand, pure Ruby - Python - Java - C++ that's fairly common and not as likely to fetch high salary, since you'd be competing with a larger talent pool.
> Strangely, I see so many new developers rushing toward the front-end
"Easiest" area of programming to get a decent job and enter the industry. It's so much easier to find a job in big cities if you know Angular or React. As long as you keep yourself up to date in frameworks and tools you can theoretically stay employed for a long time.
That said, I have heard of plenty of people who had done the above getting burn out or bored after about a decade.
> I would transpile it from Typescript using a Webpack + SystemJS + Babel combo.
Don't find it surprising that the author intentionally makes his/her story more complex than necessary.
For example, you can use "Typescript+WebPack" instead and ditch all the blah-blah on Babel/SystemJs, but that wouldn't help the naritive much, now would it!
I don't even mind the keeping-up part. What I don't understand is how anybody keeps the code base reasonably up to date. I want to build something that lasts.
I was talking to somebody at a place where they're throwing away a big custom code base in favor of gluing together a bunch of aaS stuff. Four years ago, the system was cutting edge. Then they had a big round of layoffs, and they only now can afford to do new work again. One of the big factors in the decision was just the cost of getting everything up to date. There was a bunch of failed flavor-of-the-week stuff that needed to be rewritten. There was a bunch of technical debt from using cutting edge stuff (e.g., library versions pinned to particular GitHub hashes, forks of libraries to get that one feature or work around that one bug). And there was just the proliferation of different technologies picked because they were the "best" for the local problem, but definitely not the best when you account for operations and maintenance cost.
I'm hoping that the roulette wheel eventually stops spinning and the JS world settles on something, anything where I can be confident that somebody can come back a couple of years later and be able to extend it without having to throw everything out.
I am a full stack guy who was doing 50/50 front-end vs back-end till last year. But since then, I've started moving more towards the back end as I simply am not able to keep up with the newer frameworks and libraries coming out everyday.
What is worse, a lot of employers have already decided that if your app isn't written in React + Redux + whatever-is-hot-today, it isn't worth doing. I like to keep my stack fairly simple, and my approach apparently doesn't work.
I still do a fair bit of front-end development, but only when its on my own terms.
The "flavor of the week" is mostly a meme. You would be fine just learning ES6, a front-end technology like Angular or React, and a bundler like Webpack. Learning Webpack is painful, but there are other choices.
The front-end is harder IMHO, but as another poster mentioned, the opportunities are tremendous.
Yes, but the point was that the poster said that "flavors of the week" is just a meme, and then said all you need to learn is two current flavors of the week.
No no no Ember is too old to take advantage of $featureX that you just HAVE to use. There's a couple forks like Coal or Ash that try to enable it but you're still stuck using Embers $designPatternThatWasHotShit5MinutesAgo instead of $newDesignPattern.
>> You would be fine just learning ES6, a front-end technology like Angular or React, and a bundler like Webpack
In nearly every circle of developers I know, they insist you learn plain, vanilla JS first. Jumping in Angular without knowing what a JS object is, understanding how closures work, understanding callbacks, or understanding how JS's "this" works in detail. All things someone should be fluent with before they go jumping into Angular and React.
Also knowing there's a HUGE difference between Angular (which is a full MVC framework) vs. React (which is just the View part of an MVC framework) is a small, but important detail for someone just starting out.
I was assuming that JavaScript would already be known to a certain degree.
I would actually recommend React over Angular for a beginner, because (assuming Angular 2 here) they're going to have to learn Typescript too. That's a big undertaking.
A beginner could also use plain old ES5 with a JSX transpiler right in web page with React.
VueJs might be a better choice than both of those, but much more limited job opportunities.
I feel the perceived "hardness/complexity" of the front-end stack is largely due to the relative less mature nature of JS / CSS / and the ever evolving toolset.
From a pure computer science perspective, I feel the data structure, algorithms leveraged on the backend side has greater complexity potential.
Strangely, I see so many new developers rushing toward the front-end, which seems much more complicated in many ways than just building solid web API services, analyzing data, etc.