91–100 of 125 posts
As an aside, the author of the article is one of the authors of Tachyons—the library I consider the tool that makes me not want to die when designing web pages: http://tachyons.io/
Something
Earlier quoted context omitted.
I think the real markers should be that a person is not afraid of broadening their views. Usually, the advice for hiring for Erlang, as an example, is not to hire people that know Erlang, but focus on hiring good people (who are capable of learning beyond your average C-like) and then teach them Erlang. It's a small and very easily learned language, for sure, but learning it is certainly a bigger undertaking than lea…
I've been trying to learn Angular2 recently, maybe I'm not a good developer (but I faired ok with Erlang :D), but it really is such a struggle. Documentation is lacking, and what is available is often wrong or outdated. It doesn't help that half the tools and libraries are still in 'beta' and breaking changes are seen as a way of life. This post really sums up my experience, and I've done plenty of Javascript before…
The first set is normally seen as "hard", because it is very easy to shoot oneself at the foot with them, and because experts tend to be attracted by them. The second set is often seen as "easy" because the complex features are normally there to stop novices from harming themselves.
The unexpected thing is that "simple" is much easier to learn than "complex", independently of what other adjectives come bundled with them.
1 - Yes, the other 2 combinations exist. "Simple and powerless" does not make the headlines, and "complex and powerful" is very, very rare.
Earlier quoted context omitted.
I've been trying to learn Angular2 recently, maybe I'm not a good developer (but I faired ok with Erlang :D), but it really is such a struggle. Documentation is lacking, and what is available is often wrong or outdated. It doesn't help that half the tools and libraries are still in 'beta' and breaking changes are seen as a way of life. This post really sums up my experience, and I've done plenty of Javascript before…
> I'd actually say for someone completely new (e.g. locked in a basement doing C or Java for the last 20 years), learning Erlang would be far easier than learning modern JavaScript and Angular2. I suppose that might be the case. It feels incredibly counter-intuitive, but it's not inconceivable that the JS frameworks stray that far from "normal JS". Were I in this situation as a employer (and co-worker, necessarily, n…
Earlier quoted context omitted.
Nope they won't, because then your are just another contributor. There are thousand working on linux (the kernel). How many of them do you know?
Which is better (for your CV), be a contributor to Angular.js (example) or create your something.js that left-pads and right-pads at the same time?
Having a patch or two in angular doesn't seem to move the needle.
Earlier quoted context omitted.
Which is better (for your CV), be a contributor to Angular.js (example) or create your something.js that left-pads and right-pads at the same time?
From what I can tell, something.js if the amount of code is equivalent. Having a patch or two in angular doesn't seem to move the needle.
Getting something on Angular means you were able to get your changes approved and merged (team work)
Situation is better if you can have a bigger project or more people using your something.js
Earlier quoted context omitted.
> I'd actually say for someone completely new (e.g. locked in a basement doing C or Java for the last 20 years), learning Erlang would be far easier than learning modern JavaScript and Angular2. I suppose that might be the case. It feels incredibly counter-intuitive, but it's not inconceivable that the JS frameworks stray that far from "normal JS". Were I in this situation as a employer (and co-worker, necessarily, n…
Yeah, you can really tell you don't work in front-end development from that insane suggestion. What you're suggesting simply isn't practical.
To clarify, what I mean is that someone who can't learn Elm, PureScript, Bucklescript or the like, very likely isn't a very inquisitive person and isn't someone I'd like to work with. On top of that, someone who can't see why you'd want to write in any of those languages instead of JS very likely isn't someone who I would want to work with, for fairly obvious reasons.
I've been a coder and have watched coders for a long time. I consistently see two trends. As an agile guy, back in the day I wrote an Agile story tracker. Fun times. Then I saw some other Agile project management tools. Then for a while it seemed like every week or two I was getting emails asking me to evaluate yet another agile/to-do list tool. It seemed that programmers were unable to grok the agile story concept w…
The point of that story is that it takes a long time to properly understand a problem domain well enough to start solving problems in it at the right level of abstraction. A framework can "understand things for you" and just work if you set it up right, but the cost is that you lose the freedom to replace that framework with something smaller and lighter.
Earlier quoted context omitted.
> I'd actually say for someone completely new (e.g. locked in a basement doing C or Java for the last 20 years), learning Erlang would be far easier than learning modern JavaScript and Angular2. I suppose that might be the case. It feels incredibly counter-intuitive, but it's not inconceivable that the JS frameworks stray that far from "normal JS". Were I in this situation as a employer (and co-worker, necessarily, n…
Yeah, you can really tell you don't work in front-end development from that insane suggestion. What you're suggesting simply isn't practical.
CircleCI chose to use ClojureScript and Om instead of using React directly. NoRedInk chose to use Elm instead of writing JavaScript directly. Others have chosen ScalaJS.
It's not popular in the startup world, but plenty of companies chose (and continue to choose) to use GWT to build their in-browser user interfaces. I worked at one of them back in 2010. I had huge doubts about the Java-to-JS compilation process. I'd mostly only seen ugly GWT apps cobboled together from the UGLY base components GWT shipped with. As it turned out, we were able to created our own good looking components quite easily. So long before Angular or React existed, we were able to create a nice an easy to understand component based web app, with business logic split out into services and wired together with dependency injection. It ended up being a sane choice that enabled us to continue developing safely and sanely as the app became larger, and it performed very well on both desktop and mobile browsers. GWT wouldn't be my first choice (or second, or third) in 2016, but it ended up being a pretty good one in 2010.
I'm not saying that choosing a compile-to-JS language that has very different semantics than JS is necessarily sane and practical. But I think that plenty of real world successes demonstrate that this choice can be simultaneously sane, practical, and successful.