I have to echo the general sentiment here so far - degree should not matter. As someone without a degree, who's been working in the industry for 18+ years, I've never lost a job opportunity simply because I don't have a degree. This is a field where one's experience and willingness/passion to continue learning should matter above everything else.

[user] name = Mike Sprague email = ... signingkey = ... [core] symlinks = true autocrlf = true longpaths = true [alias] co = checkout st = status br = branch ci = commit cia = commit --amend hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short s = status -s lg = log --oneline --decorate --all --graph pom = push origin master [filter "lfs" ] required = true clean = git-lfs clean % f smudge = git-lfs smudge % f [pull] rebase = true [rerere] enabled = true [color] ui = true [ commit ] gpgsign = true

That was my first thought too. However, it will continue to work. It just won't be the recommended solution. And, it does fit with some of the other decisions they made for Vue 2 - like getting rid of built-in filters and recommending outside libraries for some of the more commonly used filters. For what it's worth, I played around with Axios after reading that yesterday and it's not only a well-built library but pretty straight forward to replace vue-resource with.

Bad management. And unrealistic expectations. But those usually go hand in hand.

It's a pretty biased article but at least they make it clear up front that they prefer Parse Server. I like Parse, but the decision really comes down to: closed-source/saas hosted vs open-source/self-hosted. They both have their merits, depends on the project.

I've used Semantic UI a bit and recommend it. Your mileage may vary but... I feel the framework is updated enough. I suppose this is somewhat open to each developer's interpretation of what "enough" is. The last notable release was July and the last commit to their master branch was at the end of September. As long as there aren't major bugs, and the framework is fairly feature-complete, I don't personally need weekly or monthly updates so this works for me. I haven't run into any real annoying bugs. Yet. I only support modern browsers in all my client work unless I am being paid specifically to support IE10 and below. Therefore, their lack of support for older versions of IE9 and below doesn't affect me. It works with all modern browsers. The docs are your friend regarding components. They address creating components and .less files with theming variables, etc. on their site. If you follow their guidelines your component should blend right in. It does not "need" a library like React, but right in their documentation it says: "Semantic UI components are designed to be compatible with libraries that tightly manage UI lifecycle like React. No special bindings are needed." There are also Vue versions of the Sematic UI components and as mentioned in the quote from their docs above, it's really straight forward to implement Semantic UI with other libraries. Semantic UI has really good documentation. Most of the things you've mentioned are covered there so I would probably start there when evaluating if it will meet your needs as a whole.

Looks interesting @beneb, will have to try it out. My first thought after reading the article was that some server-side code that handled the tasks would be nice, hadn't yet considered a build task.

Hi Caner, Fair enough! And yeah, I agree, a job title is just that (and often misclassified by someone in HR) and very rarely what conveys one's day to day activities.

For those that don't find Medium to be the best platform for cheat sheets, last week (with the author's permission) I put that post on GitHub as a markdown-based document. It's available here: https://github.com/mikesprague/yarn-vs-npm-cheatsheet

It often depends on the company. I've been a web developer for nearly 20 years and in the course of my career I've had titles like "Senior Software Engineer" and "Programmer/Analyst." In my experience, any web developer worth their salt knows about application architecture, algorithms, scalability, distributed systems, version control, databases, data migration, APIs, testing, and on and on. It's the companies who realize a good web developer is a software engineer that often use that title whether you are building web applications, embedded software, etc. In these cases, Facebook/Google may very well have web developer positions for hire under the "Software Engineer" title. I have to respectfully disagree with @cdagli. As developers, we all face problems that are already solved. A good developer knows how to evaluate the existing solutions and determine which ones are well done and evaluate when their time is better spent building their own. Or, contributing to open source solutions that meet some of their needs but lack in other areas. If doing unique work was what made someone a software engineer, then there wouldn't be many of them out there. Also, unlike @cdagli, it's been my experience that a Wordpress developer can be responsible for custom development, integrating with 3rd party systems, and other "software" oriented roles. It's the platform itself that gets a bad name due to many poor implementations and how easy it is to get started but there's a big difference between an editor who builds pages in Wordpress, Drupal, etc. and a developer who implements custom solutions built on these platforms. If companies were to think like that, then a Java developer who deploys some of his apps on Heroku isn't a software engineer. Slack uses a ton of PHP for server-side application logic in their infrastructure. I bet the developers behind their codebase are considered software engineers. Just my 2 cents but I wouldn't assume every web developer is just building Wordpress pages.