Just a couple days I got into a conversation with my coworker about UI stuff. I had to test something against our dev UI. Last time I did UI work was back when having index.html, img/, css/ and js/ directories with maybe a script or two was the norm. I had to fucking run make and I still have no fucking idea what was going on when I ran make which compiled a bunch of shit. There was all this NPM shit going on (isn't NPM part of Node.js which is a server-side framework? WTF?). I got it working and promptly noped the fuck out that horror show.
The web is a giant fucking pile of dog shit in 2016.
I'm a content guy who knows enough web dev to be dangerous.
I made 3 manual edits to a css file to fix a couple of incorrect background colours in our web content the other day. I was a good boy and made a pull request for those same changes in the git repo.
Our developer explained that he doesn't actually edit the css file. He would have to work out the change in the hue (as a percent of the base colour) and update that in the sass file, then use gulp to compile a fresh version of the output css.
He said that this was a simple build process to get set up on my machine so I could do it myself in the future.
He uses a mac. I use windows.
4 hours later after hitting so many hurdles I finally got it working. I can't even recall all the issues, but do recall that I side stepped them all by moving to a particular version of npm which actually used a sane system for storing the dependencies.
With out that version of npm this simple build process required 15,000 files in my node_modules subdirectory in a structure so deep and convoluted Windows couldn't create them....
Of course now that I'm armed with the toolset to make these changes I've reverted to testing changes in chrome dev tools and emailing him requests.
> this simple build process required 15,000 files in my node_modules subdirectory
You would think people learned a lesson about packaging every tiny item as a dependency with left pad, but apparently yesterday it was downloaded 16104 times.
Aaah, good luck. For me it's basically gotten to the point where if the build doesn't immediately work on Windows, I just fire up a Linux VM and work off of that.
And that's not just for front-end projects, but for open-source projects in general. Windows support is often really lacking in an environment where devs seem to use Linux and Mac almost exclusively.
a big problem with npm is, that a lot of package authors don't use the .npmignore [0] which leads to EVERYONE downloading your source/, test/ and docs/ folder even if only that one file in build/ is needed.
That, combined with the micromodule mindset, leads to insanity
Sass is awesome, and one of the few pieces of the 'compilation toolchain hell' I _don't_ hate.
But you ideally shouldn't have your CSS build product in the repo if you're using SASS. That would avoid the confusion of editing the wrong file (the compiled output artifact, which ought not to be in the repo).
It doesn't have to be this way. Unfortunately, we live in a world where younger developers "show their skill" by making things overcomplicated in order to create unnecessary barriers to entry to our proto-profession. My usual response is to refuse to work on such a project if I don't have the authority to change how things are done to make them more sane.
“make and npm” doesn’t sound overcomplicated. It sounds like someone didn’t take the time to find out what they were working with, didn’t really need to because it’s not their area, and decided to have an opinion about it anyway.
If you are doing a simple project, there is nothing wrong with just using jquery (or imho d3). If you know that your project is always going to be pretty simple or especially if you are learning.
I have been teaching a number of people javascript at my lab lately and I think its unwise to teach new javascripters using any of the modern tools or transpiling until someone runs into one the problems that those tools solve. Having been a javascript coder consistently from the jquery days until now, I am not pining for the simple old days of yore.
It can be hard to learn everything that goes into a big front end app these days but when used correctly all those tools are there for a reason.
You shouldn't use any of these tools just because people tell you to. If you can't see what problem something solves, then start at a simpler/lower level of abstraction until you run into that problem, and can appreciate the tool that solves it.
Of course, this advice doesn't apply if you actually need to write a production app, and aren't just playing around for learning purposes :)
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.
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.
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?
> 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.
>> 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 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.
While criticizing the current state of affairs, it
gives a nice overview of many of the emerging technologies
and how they fit together, even if for some tasks
it feels retarded to pull such an entangled mess of
dependencies.
You can then go insane diving into any particular one :)
Being primarily a Java dev, it felt to me like half of this was critiquing the churn rate of using different tools (warranted) and the other half was lamenting the fact that people built tools to solve the common problems they have when developing in large teams (largely unwarranted). Most of those tools have direct equivalents in the Java ecosystem (and there is tool-churn in Java too, just slower).
Facebook, Google, large startups, and the others which are building these tools are doing so to solve the problems they experience in their teams' front-end dev processes. Ironing out the kinks in the code assembly line. And they are of course doing so in a path-dependent fashion: add tool N+1 to solve problem N+1 given the existing toolchain. The result is a lot of tools and a lot of context to imbibe at once, but it doesn't mean they are solving nonexistent problems. Just problems you don't have, or don't know you have, or don't have yet, or can afford to leave unmanaged when developing a small site with just a couple people.
I have run into the problem discussed in the article multiple times. The first time was with Java, specifically J2EE. It isn't that these are non-existent problems, it is that all of the solutions require a full pull of the entire context. That is bad for both learning and software architecture. I was going to start moving in the J2EE direction (I knew Java itself fairly well), but I realized that getting the most basic program up and running would require knowledge about about 7-10 frameworks. That was ridiculous. Additionally, Java was terrible about framework installation at the time, so that made it even worse.
My preference, and I think it is born out by successful long-term projects, is to always keep everything to a minimum. A lot of people say things like, "that's not the optimal way" or "you could make the page load faster" or "you could integrate with xyz".
But, at the end of the day, you have to measure bang for the buck. Bootstrap - VERY high bang for the buck. Jquery, likewise. Pretty much everything else doesn't start yielding dividends until you are at a facebook-level application.
Which, frankly, is fine for Facebook-level applications. But the problem is that people are using these for everything, which is totally ridiculous. How they find people to pay for all of this is what really blows my mind.
Yes, it is called "Enterprising the sh out of it". And yes, Java (and C#/.Net) has a huge problem with that and Javascript is well on its way.
Large companies love to get cool haircuts and wear torn jeans and talk about building fast and being agile and yet, they continues to build frankenprojects.
Yes, but I really don't like the "How it feels to learn Javascript" title. Realistically you wouldn't give such a wide array of options to someone who wants to learn how to accomplish something specific.
Yes, realistically if you were to have a conversation with an experienced advisor like the article is staging that wouldn't happen. However, the article reflected exactly how I felt trying to do more JS again a few months ago after not having done much JS for a few years.
I don't know about anyone else, but the problem I personally have with the crazy, messy JavaScript ecosystem is:
- I am a relatively experienced amateur programmer (with limited [nine months] professional experience)
- I can learn any new programming language, library, methodology, or whatever pretty easily
- I don't have any formal experience using anything of this newfangled stuff; like the author of the article, my frontend experience involves plain ol HTML/CSS/JS, with a little jQuery to make things easier
- nobody wants to hire me unless I have `n` years experience with newfangled language/framework/methodology `x`, `y`, and `z`
- I don't have a CS degree
Unless you're a massive operation like Facebook or something... just give me a week to look through your website's codebase, I'll figure out how you guys do things and I'll start being productive before you know it. If you're using stuff that I've never used before, I'll learn it.
I should be a more attractive hire than someone who has `n` years of experience only using `x`, `y`, or `z`, because the way I think about getting things done with computers isn't tied down to any one specific framework... but it seems that this isn't how hiring works in the industry right now... which is directly at odds with the rapidly-changing nature of web development!
As a result, I don't feel inclined to learn any of this new crap. What's the point? Apparently I should've learned it all `n` years ago, and it's too late now?
It sounds like your gripe isn't with the knowledge base, but with the people doing the hiring. The issues there are very real in that, if you're dealing with a non-trivial codebase, there's no way to tell whether someone with very little real world experience is a competent programmer or just "faking" until you've got them working on it for a few weeks, and even then they may not be worth the time you put into training them until a couple of months down the line. And the people in HR for most organisations don't have a clue how to tell the difference.
So they make up a bunch of gatekeeper requirements that allow them to filter out anyone that doesn't fit the mold early in the process. They're still likely to find someone who can do the work this way even if it means throwing out a decent percentage of other candidates.
It's messed up, but it's kind of where the lack of technical knowledge in HR, and the need to avoid any potential lawsuits have left us.
This has been my exact experience. I just had a week of phone calls and emails about a very promising, well-paying frontend job opportunity. All of them were with no-technical-knowledge buzzwordy HR types who were very friendly and assured me that my resume and portfolio were great, and that I would be a good fit for the job. The whole thing ended with a phone call that went something like:
"Hi, so, your resume says you have nine months of experience?"
"Well yes, but I have countless personal projects under my belt, I designed and built game engines with teams of students..."
"Yes, but this position requires four years of professional experience."
"Well I still think I'd be a great fit for your company, I have experience with the specific technology stack you use, you can ask my previous employer..."
"Yes, but this position requires four years of experience, so, I'm sorry, but you don't meet the qualifications."
"Oh. Okay, thanks, bye."
Another story:
I got a call about a job I'd applied to. The guy on the phone said I looked like a promising candidate, but my resume didn't list the start and end dates of my previous job (nine months total), as I'd accidentally sent an old version of my resume. I emailed the correct version of my resume, and nearly immediately got an email back, saying, and I quote:
"Needed 1+Years of Experience so if you can change the duration time"
After a few minutes of consideration, I edited my resume to change the end date of my previous job to be one year from the start date, saved it as a separate copy, attached it, and sent it back. The guy immediately replied asking me to verify that the 50k starting salary would work for me. (Before anyone says 50k is too low, rent is due and I'm desperate.) This was just last week and I haven't heard back since but this is the most promising opportunity I've been able to find after months of searching.
---
The thing is, I don't even want to do frontend web development. I want to work in game development, but apparently to get a start doing that professionally, I need professional programming experience on my resume to look good because those positions are so competitive. Okay, fine, I can do web development, front- or backend, I thought. That'll be great for padding out my resume, and, y'know, paying rent. But it turns out that landing one of these jobs is also really difficult!
What frustrates me about all of this is not so much my own position, but about the future of the industry. As time goes on, I think we're going to see more and more people take the path I took of learning stuff on their own instead of at college. Formal CS education is far from useless, but if this stuff's all available for free online, people are going to download it, play around with it, and learn how to use it... it just seems crazy to me that companies are hiring just-out-of-college CS graduates over people who have made a ton of stuff on their own over the years.
Hi! Person who hires other people here. I too am self-taught, so I'm sympathetic. But these two things in combination scare me:
> [nine months] professional experience
> just give me a week to look through your website's codebase, I'll figure out how you guys do things and I'll start being productive before you know it.
I get why you think you can be productive. But a person with 9 months experience has no experience with long-term maintainability. Your definition of productive and mine are likely very different. And that you don't know that there's a difference means I can't trust you to write production code. You're in the "hazard" stage of expertise:
Novice programmers are great, and I've successfully hired them in the past. But that requires a context where they can work closely with experts who help them improve while keeping them away from doing things that feel productive but are long-term harmful. Left unsupervised, they can, with the best of intentions, be fountains of technical debt.
> the way I think about getting things done with computers isn't tied down to any one specific framework
This is a dangerous way to think. In software, everybody is bright. Everybody is a quick learner. If your operating theory is that you're just way smarter than those fools who have spent time learning something more deeply, you're going to keep yourself from advancing in your chosen work. To me, you come across like this:
> Apparently I should've learned it all `n` years ago, and it's too late now?
Find yourself a context where you can spend n years and dig in. Go make things. Go maintain things. Go find the edges of your knowledge and develop a little humility. Because without it, you're going to have a very hard time successfully asking people to give you a job where there going to have to give you a lot of help.
Nine months professional experience, over a decade of making websites, web apps, games, and game engines, in a wide variety of languages, frameworks, etc.... but all at an "amateur" level, which is not what hiring departments are looking for right now. I've been making websites since HTML4. In high school (graduated '09), I had a thumbdrive with Portable Notepad++, Firefox, and XAMPP, and I'd work on stuff in the library between classes and during lunch. I've been almost always working on at least one personal project at a time for the past decade, and while none of them are groundbreakingly impressive, my portfolio shows that I know what I'm doing... but that doesn't matter to hiring departments, apparently, because it's not "professional experience".
A thousand times this. When I started at my first professional gig, I had to learn their language (Perl) from scratch. So I sat down for two solid days and dug through perldoc until I knew my way around. Two months in, I'm explaining the subtleties of Perl's syntax and behavior to senior developers who've been coding in Perl for 5+ years.
1. Rule out any company that says they want 10 years of X. Especially if X hasn't been around 10 years. These companies are looking for such a narrow set of individuals it isn't worth your time. Or, the company doesn't understand technology and you'll be pulling your hair out (assuming you have any; it's cool if you don't) in no time.
2. Understand that rule 1 rules out 99% of tech companies.
3. (And I suck at this) Network. Network. Network. I truly wish I was better at this. I'm currently doing C#/Java/C++ (yes, it's that kind of project. It's been fun, but my interests are changing.) and want to transition to Python full time. I live in a mid size but rather secluded city with an absolute dearth of tech companies, so networking is extremely difficult here.
I have almost 2 years of professional experience but technically it's like '6 months 4 times' considering they were internships/contractual employment.
I've done projects with several frameworks and libraries on my own but not professionally. Regardless, recruiters/HR will tell me they're looking for people with "more experience" without being specific even though they're hiring for a junior level position.
In reality it seems more like they want to hire a senior-level developer and pay them at a junior-level rate.
I've actually heard a headhunter say that an open position they're looking for people to fill would like someone who knows and has worked with Polymer for 1-2 years. smh
We are not currently hiring, but we do 100% of our hiring based on our personal interactions. We are a Rails shop, and rarely if ever do our developers know Rails coming in. In fact, one of my best hires came straight out of high school.
I agree that the HR path is ridiculous. We can go another route because we are small. I don't know how you would balance the needs of large-scale hiring with the intricacies of tech at a big company.
I couldn't get through the entire thing. Even knowing that it's a fun/sarcastic piece of writing, the portrayed pain is all too real, as someone just starting to dive into the front-end.
In all honesty, can I still use jQuery for new projects without issues in 2016? Is there a real reason not to?
But honestly, I'd go with React if you can. The reason is, if the app starts taking off, and you end up with a team maintaining your app, you're much less likely to end up with an unmaintainable mess in two years than if you use just jQuery.
All applications, especially websites want frameworks. The framework is essentially a way to organize the massive amount of complexity boiled in. If you just roll with libraries, then you end up cobbling together a framework on top of it. You will then have to maintain this framework. This is fine when it's just you, it will coalesce into a bunch of conventions that's fairly easy for you to reason about.
But once you start involving others, then you're going to see your nice conventions get rekd like a bull in a china shop. Not everybody sees problems the same way you do.
If you pick the framework beforehand, then you don't need to maintain it, you can let the nice people at Facebook / Google do it for you. And whenever you finally get others involved, they're limited in the amount of architectural damage they can do because they have to stick to the conventions of the framework.
1. 'if' it's an actual app and not a web page with a smattering of interactivity
2. 'if' by 'take off' you mean becomes a moderately complex SPA
3. 'if' there's no alternative that is simpler and more maintainable (another excuse to plug intercooler.js here)
There aren't enough people saying "Are you sure you need a front-end framework?".
I've worked on several projects that had <insert framework> for no real reason other than the dev wanted to learn it. There is a threshold where it makes sense to use React or similar - but that threshold is being set way, way too low.
I agree - I think React is simple enough that there's no reason not to besides the overhead of JSX preprocessing (which I suppose isn't required but I would definitely recommend). It really is more of a library than a framework, which is great for starting out because there are fewer concepts to understand. Then when you start adding more people and your application gets more complicated and you need to manage your data flow in a more consistent way, you can add something like Redux after the fact incrementally. As long as you don't let components become too large, refactoring isn't too difficult.
This a great comment. Yes you can still use jQuery and yes it's still very powerful, but it lets you shoot your own foot off too much -- and your whole team's feet are in danger too.
Angular was a huge step up in "you won't shoot your foot off-ness" and React is a step further. You still can, but you realize that you're loading the gun most of the time and can take a step back.
And that is really all this churn is about -- trying to make things easier and more foolproof. We've introduced other problems trying to solve the first couple batches of problems (accidentally using the development version of Reach on production is one I see a lot), but we'll get there.
The PHP ecosystem has had quite a bit of churn in the last 5 years too, but the yelling about it doesn't seem to be as loud since people aren't forced into it since there are alternate languages.
As long as you stop reading popular blogs and all HN javascript posts, you can use whatever you feel will get the job done. Likely, you'll get it done faster than someone who reads all the popular blogs and chases the shiny.
React is really very simple. It only takes a short amount of time to learn it, and then when you do you won't get headaches all the time trying to keep track of state.
You don't need to know all the toolchains and crap if you just use create-react-app.
I did not have a simple experience with React. I did front end development for years, ending with jQuery-driven AJAX sites pulling from REST APIs (2013), and when I tried to learn React this year it was all voodoo.
Is there a good tutorial out there for lapsed front-end devs?
Good to know. Just trying to find a thread (in front-end dev) to latch on to was challenging.
So I threw out everything, and just started from HTML on Gitlab Pages. I've added on CSS, and just started adding in little JS functions. I can now (sort of) appreciate frameworks. React seems to be a popular choice.
> You don't need to know all the toolchains and crap if you just use create-react-app.
I love the hand wavyness of this! Yes, you DO need to know the toolchain. Because if you don't, it is going to be murder on you if you need to track down why something isn't working.
Professional developers need to use professional tools and understand them deeply. There's no compromises here.
It continually shocks me how much whining developers do about sometimes having to learn new things. The requirements for continued education are shockingly low (read: non-existent) in our industry, compared to other, similar intellectual/white collar industries - doctors in California are legally required to do 50 hours of CME/2 years, lawyers in California are legally required to do 25 hours of CLE/3 years, and those are both fairly standard. There are a tremendous amount of jobs out there that won't require you to learn anything new, ever, if you don't want to (think of how many thousand brain-dead Java jobs are out there). There are plenty more that will require you to learn one or two new things (any of the hundreds of consultancies and companies that picked a fairly standardized stack and work with it all the time). And then there is a tiny subset of companies that are actively working with new tech and trying new things, and a tiny subset of people actually using all of those new things. Whining about how "it's too complicated!" because someone somewhere provided you with some new programming tools for free because they thought those tools were useful and cool is an ugly look for a profession that's so prone to patting itself on the back while loudly proclaiming how forward-thinking it is.
Learning in other industries is offered in institutional settings as part of the profession.
Learning in the dev world consists of aimlessly screwing around with an undocumented, unsupported, glitchy web/server stack for many many hours unpaid after you've already spent 40 hours that week putting bread on the table.
The whining has less to do with the "learning" and more to do with the yak-shaving part of it torturing us endlessly in the off-hours. And, unlike in medicine and law, there is precious little professionally-written, detailed, helpful literature to help us along the way. There's just "quick install" and then a command/api reference. That is... not up to the level at which medicine and law have their industry practices & standards documented.
There is always that one person that says "others have it worse, thus you're whining if you have trouble doing your job".
Not a valid argument, and won't ever be.
Plus don't forget our education isn't formal. Doctors and lawyers have it much, MUCH more standardized than ourselves. We the devs are pretty much do-it-alls that have to learn 95% of their skills on the go.
You won't ever hear me complaining about learning things on the go. I love it. What I hate however is putting up with the lame work of people who probably can't do much more in their lives beyond tying their shoes. That's what this thread is about -- partially anyway.
I'm in a weird position where I like JavaScript and Node but dislike frontend (or at least I am disliking it more and more).
With Node, I can get quite far with just a couple of dependencies that install quickly. I don't need transpilation unless I want to use TypeScript or PureScript and I can target any version I want. I find it very fun to mess around with Node and a bunch of little modules.
I am slowly "transferring" back to server-rended pages using Node or Elixir. Probably not good for my employment (even in NYC most JS jobs are frontend), but whatever.
If I was learning JS right now and didn't care about employment I'd just learn Node (which just means learning JS really) and experiment with stuff.
JavaScript, admittedly, has a few more quicks than the average language but I quite like it. I know a lot of people who also feel the same way. (And as many how, of course, hate JS.)
It still feels to me like we're in the early days of node and the dev infrastructure for "modern" sites. Hopefully, things stabilize soon(ish).
Readit News
The web is a giant fucking pile of dog shit in 2016.
I made 3 manual edits to a css file to fix a couple of incorrect background colours in our web content the other day. I was a good boy and made a pull request for those same changes in the git repo.
Our developer explained that he doesn't actually edit the css file. He would have to work out the change in the hue (as a percent of the base colour) and update that in the sass file, then use gulp to compile a fresh version of the output css.
He said that this was a simple build process to get set up on my machine so I could do it myself in the future.
He uses a mac. I use windows.
4 hours later after hitting so many hurdles I finally got it working. I can't even recall all the issues, but do recall that I side stepped them all by moving to a particular version of npm which actually used a sane system for storing the dependencies.
With out that version of npm this simple build process required 15,000 files in my node_modules subdirectory in a structure so deep and convoluted Windows couldn't create them....
Of course now that I'm armed with the toolset to make these changes I've reverted to testing changes in chrome dev tools and emailing him requests.
You would think people learned a lesson about packaging every tiny item as a dependency with left pad, but apparently yesterday it was downloaded 16104 times.
[1] https://www.npmjs.com/package/left-pad
Aaah, good luck. For me it's basically gotten to the point where if the build doesn't immediately work on Windows, I just fire up a Linux VM and work off of that.
And that's not just for front-end projects, but for open-source projects in general. Windows support is often really lacking in an environment where devs seem to use Linux and Mac almost exclusively.
so when you clone repo or edit it directly in github you don't have option to edit wrong file (compiled css file for example)
but i agree that js community has everything very complicated for learning but it's not that bad for everyone that already knows how tings work here
[0]: https://docs.npmjs.com/misc/developers#keeping-files-out-of-...
But you ideally shouldn't have your CSS build product in the repo if you're using SASS. That would avoid the confusion of editing the wrong file (the compiled output artifact, which ought not to be in the repo).
That's when I knew things were about to get interesting :-)
I wouldn't say it's malice. I think they simply don't know better.
Dead Comment
Dead Comment
I have been teaching a number of people javascript at my lab lately and I think its unwise to teach new javascripters using any of the modern tools or transpiling until someone runs into one the problems that those tools solve. Having been a javascript coder consistently from the jquery days until now, I am not pining for the simple old days of yore.
It can be hard to learn everything that goes into a big front end app these days but when used correctly all those tools are there for a reason.
You shouldn't use any of these tools just because people tell you to. If you can't see what problem something solves, then start at a simpler/lower level of abstraction until you run into that problem, and can appreciate the tool that solves it.
Of course, this advice doesn't apply if you actually need to write a production app, and aren't just playing around for learning purposes :)
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.
WPF, XAML, iOS, Android, Qt.
None of them suffer from the same craziness of the web world.
I used to do web and don't miss it. Actually it was my experience in Web projects that changed my mind that web should have stayed HTML/CSS.
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.
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.
If you do keep up, you'll get amazing job offers.
If you manage to really be on the edge, you can give talks as well, expose yourself as a consultant.
That's much easier in JS than with Ruby, Python or whatever else.
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.
"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.
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 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.
Deleted Comment
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 front-end is harder IMHO, but as another poster mentioned, the opportunities are tremendous.
And in 2015 you would have been just fine learning Ember or Angular 2.
And in 2014 you would have been just fine learning Angular 1 or Ember.
And in 2013 you would have been just fine learning Backbone and Ember.
And in 2012 you would have been just fine learning Knockout and Backbone...
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.
From a pure computer science perspective, I feel the data structure, algorithms leveraged on the backend side has greater complexity potential.
While criticizing the current state of affairs, it gives a nice overview of many of the emerging technologies and how they fit together, even if for some tasks it feels retarded to pull such an entangled mess of dependencies.
You can then go insane diving into any particular one :)
Facebook, Google, large startups, and the others which are building these tools are doing so to solve the problems they experience in their teams' front-end dev processes. Ironing out the kinks in the code assembly line. And they are of course doing so in a path-dependent fashion: add tool N+1 to solve problem N+1 given the existing toolchain. The result is a lot of tools and a lot of context to imbibe at once, but it doesn't mean they are solving nonexistent problems. Just problems you don't have, or don't know you have, or don't have yet, or can afford to leave unmanaged when developing a small site with just a couple people.
My preference, and I think it is born out by successful long-term projects, is to always keep everything to a minimum. A lot of people say things like, "that's not the optimal way" or "you could make the page load faster" or "you could integrate with xyz".
But, at the end of the day, you have to measure bang for the buck. Bootstrap - VERY high bang for the buck. Jquery, likewise. Pretty much everything else doesn't start yielding dividends until you are at a facebook-level application.
Which, frankly, is fine for Facebook-level applications. But the problem is that people are using these for everything, which is totally ridiculous. How they find people to pay for all of this is what really blows my mind.
Large companies love to get cool haircuts and wear torn jeans and talk about building fast and being agile and yet, they continues to build frankenprojects.
As a matter of curiosity, would you mind unpacking this statement?
Not really sure if you mean to say the piece imparts a moral lesson. Or perhaps it relates to the writing aesthetics; Or something else
I don't know about anyone else, but the problem I personally have with the crazy, messy JavaScript ecosystem is:
- I am a relatively experienced amateur programmer (with limited [nine months] professional experience)
- I can learn any new programming language, library, methodology, or whatever pretty easily
- I don't have any formal experience using anything of this newfangled stuff; like the author of the article, my frontend experience involves plain ol HTML/CSS/JS, with a little jQuery to make things easier
- nobody wants to hire me unless I have `n` years experience with newfangled language/framework/methodology `x`, `y`, and `z`
- I don't have a CS degree
Unless you're a massive operation like Facebook or something... just give me a week to look through your website's codebase, I'll figure out how you guys do things and I'll start being productive before you know it. If you're using stuff that I've never used before, I'll learn it.
I should be a more attractive hire than someone who has `n` years of experience only using `x`, `y`, or `z`, because the way I think about getting things done with computers isn't tied down to any one specific framework... but it seems that this isn't how hiring works in the industry right now... which is directly at odds with the rapidly-changing nature of web development!
As a result, I don't feel inclined to learn any of this new crap. What's the point? Apparently I should've learned it all `n` years ago, and it's too late now?
So they make up a bunch of gatekeeper requirements that allow them to filter out anyone that doesn't fit the mold early in the process. They're still likely to find someone who can do the work this way even if it means throwing out a decent percentage of other candidates.
It's messed up, but it's kind of where the lack of technical knowledge in HR, and the need to avoid any potential lawsuits have left us.
"Hi, so, your resume says you have nine months of experience?"
"Well yes, but I have countless personal projects under my belt, I designed and built game engines with teams of students..."
"Yes, but this position requires four years of professional experience."
"Well I still think I'd be a great fit for your company, I have experience with the specific technology stack you use, you can ask my previous employer..."
"Yes, but this position requires four years of experience, so, I'm sorry, but you don't meet the qualifications."
"Oh. Okay, thanks, bye."
Another story:
I got a call about a job I'd applied to. The guy on the phone said I looked like a promising candidate, but my resume didn't list the start and end dates of my previous job (nine months total), as I'd accidentally sent an old version of my resume. I emailed the correct version of my resume, and nearly immediately got an email back, saying, and I quote:
"Needed 1+Years of Experience so if you can change the duration time"
After a few minutes of consideration, I edited my resume to change the end date of my previous job to be one year from the start date, saved it as a separate copy, attached it, and sent it back. The guy immediately replied asking me to verify that the 50k starting salary would work for me. (Before anyone says 50k is too low, rent is due and I'm desperate.) This was just last week and I haven't heard back since but this is the most promising opportunity I've been able to find after months of searching.
---
The thing is, I don't even want to do frontend web development. I want to work in game development, but apparently to get a start doing that professionally, I need professional programming experience on my resume to look good because those positions are so competitive. Okay, fine, I can do web development, front- or backend, I thought. That'll be great for padding out my resume, and, y'know, paying rent. But it turns out that landing one of these jobs is also really difficult!
What frustrates me about all of this is not so much my own position, but about the future of the industry. As time goes on, I think we're going to see more and more people take the path I took of learning stuff on their own instead of at college. Formal CS education is far from useless, but if this stuff's all available for free online, people are going to download it, play around with it, and learn how to use it... it just seems crazy to me that companies are hiring just-out-of-college CS graduates over people who have made a ton of stuff on their own over the years.
> [nine months] professional experience
> just give me a week to look through your website's codebase, I'll figure out how you guys do things and I'll start being productive before you know it.
I get why you think you can be productive. But a person with 9 months experience has no experience with long-term maintainability. Your definition of productive and mine are likely very different. And that you don't know that there's a difference means I can't trust you to write production code. You're in the "hazard" stage of expertise:
http://blog.gardeviance.org/2008/04/three-stages-of-expertis...
Novice programmers are great, and I've successfully hired them in the past. But that requires a context where they can work closely with experts who help them improve while keeping them away from doing things that feel productive but are long-term harmful. Left unsupervised, they can, with the best of intentions, be fountains of technical debt.
> the way I think about getting things done with computers isn't tied down to any one specific framework
This is a dangerous way to think. In software, everybody is bright. Everybody is a quick learner. If your operating theory is that you're just way smarter than those fools who have spent time learning something more deeply, you're going to keep yourself from advancing in your chosen work. To me, you come across like this:
https://xkcd.com/793/
> Apparently I should've learned it all `n` years ago, and it's too late now?
Find yourself a context where you can spend n years and dig in. Go make things. Go maintain things. Go find the edges of your knowledge and develop a little humility. Because without it, you're going to have a very hard time successfully asking people to give you a job where there going to have to give you a lot of help.
2. Understand that rule 1 rules out 99% of tech companies.
3. (And I suck at this) Network. Network. Network. I truly wish I was better at this. I'm currently doing C#/Java/C++ (yes, it's that kind of project. It's been fun, but my interests are changing.) and want to transition to Python full time. I live in a mid size but rather secluded city with an absolute dearth of tech companies, so networking is extremely difficult here.
I have almost 2 years of professional experience but technically it's like '6 months 4 times' considering they were internships/contractual employment.
I've done projects with several frameworks and libraries on my own but not professionally. Regardless, recruiters/HR will tell me they're looking for people with "more experience" without being specific even though they're hiring for a junior level position.
In reality it seems more like they want to hire a senior-level developer and pay them at a junior-level rate.
I've actually heard a headhunter say that an open position they're looking for people to fill would like someone who knows and has worked with Polymer for 1-2 years. smh
I agree that the HR path is ridiculous. We can go another route because we are small. I don't know how you would balance the needs of large-scale hiring with the intricacies of tech at a big company.
In all honesty, can I still use jQuery for new projects without issues in 2016? Is there a real reason not to?
But honestly, I'd go with React if you can. The reason is, if the app starts taking off, and you end up with a team maintaining your app, you're much less likely to end up with an unmaintainable mess in two years than if you use just jQuery.
All applications, especially websites want frameworks. The framework is essentially a way to organize the massive amount of complexity boiled in. If you just roll with libraries, then you end up cobbling together a framework on top of it. You will then have to maintain this framework. This is fine when it's just you, it will coalesce into a bunch of conventions that's fairly easy for you to reason about.
But once you start involving others, then you're going to see your nice conventions get rekd like a bull in a china shop. Not everybody sees problems the same way you do.
If you pick the framework beforehand, then you don't need to maintain it, you can let the nice people at Facebook / Google do it for you. And whenever you finally get others involved, they're limited in the amount of architectural damage they can do because they have to stick to the conventions of the framework.
1. 'if' it's an actual app and not a web page with a smattering of interactivity
2. 'if' by 'take off' you mean becomes a moderately complex SPA
3. 'if' there's no alternative that is simpler and more maintainable (another excuse to plug intercooler.js here)
There aren't enough people saying "Are you sure you need a front-end framework?".
I've worked on several projects that had <insert framework> for no real reason other than the dev wanted to learn it. There is a threshold where it makes sense to use React or similar - but that threshold is being set way, way too low.
Angular was a huge step up in "you won't shoot your foot off-ness" and React is a step further. You still can, but you realize that you're loading the gun most of the time and can take a step back.
And that is really all this churn is about -- trying to make things easier and more foolproof. We've introduced other problems trying to solve the first couple batches of problems (accidentally using the development version of Reach on production is one I see a lot), but we'll get there.
The PHP ecosystem has had quite a bit of churn in the last 5 years too, but the yelling about it doesn't seem to be as loud since people aren't forced into it since there are alternate languages.
Having heard the same from other - "jQuery is OK, use React for new projects" - I'll focus on that then.
You don't need to know all the toolchains and crap if you just use create-react-app.
Is there a good tutorial out there for lapsed front-end devs?
So I threw out everything, and just started from HTML on Gitlab Pages. I've added on CSS, and just started adding in little JS functions. I can now (sort of) appreciate frameworks. React seems to be a popular choice.
I love the hand wavyness of this! Yes, you DO need to know the toolchain. Because if you don't, it is going to be murder on you if you need to track down why something isn't working.
Professional developers need to use professional tools and understand them deeply. There's no compromises here.
The point of breakdown probably starts with Redux. There is no simple way of structuring multi-component pages in React. All is suddenly complicated.
Learning in the dev world consists of aimlessly screwing around with an undocumented, unsupported, glitchy web/server stack for many many hours unpaid after you've already spent 40 hours that week putting bread on the table.
The whining has less to do with the "learning" and more to do with the yak-shaving part of it torturing us endlessly in the off-hours. And, unlike in medicine and law, there is precious little professionally-written, detailed, helpful literature to help us along the way. There's just "quick install" and then a command/api reference. That is... not up to the level at which medicine and law have their industry practices & standards documented.
Not a valid argument, and won't ever be.
Plus don't forget our education isn't formal. Doctors and lawyers have it much, MUCH more standardized than ourselves. We the devs are pretty much do-it-alls that have to learn 95% of their skills on the go.
You won't ever hear me complaining about learning things on the go. I love it. What I hate however is putting up with the lame work of people who probably can't do much more in their lives beyond tying their shoes. That's what this thread is about -- partially anyway.
With Node, I can get quite far with just a couple of dependencies that install quickly. I don't need transpilation unless I want to use TypeScript or PureScript and I can target any version I want. I find it very fun to mess around with Node and a bunch of little modules.
I am slowly "transferring" back to server-rended pages using Node or Elixir. Probably not good for my employment (even in NYC most JS jobs are frontend), but whatever.
If I was learning JS right now and didn't care about employment I'd just learn Node (which just means learning JS really) and experiment with stuff.
It still feels to me like we're in the early days of node and the dev infrastructure for "modern" sites. Hopefully, things stabilize soon(ish).