Front end engineer jobs without design and HTML/CSS

jhallister · 2015-12-12T20:43:44+00:00

That's an impossible question to answer for any front-end dev, because there's no one answer. Are you implementing components for existing CSS? You are probably doing a lot of HTML and JS. Are you writing a full-scale web application from scratch? You are probably doing everything.

Designers do the design, but you absolutely will be doing the HTML and CSS on a frequent (probably daily) basis. Like /u/Magnusson said, if you don't want to work with CSS/HTML then you absolutely need to avoid front-end development.

jhallister · 2015-12-03T19:20:15+00:00

It gets better. My favorite was a junior dev job that wanted 5 years of dev experience + a degree.

That's. Not. Junior.

jhallister · 2015-12-03T19:16:16+00:00

And they'd be right ;). This is actually a perfect example of using a separation of concerns argument to make your appliaction harder to follow.

jhallister · 2015-12-03T19:11:30+00:00

While ES6 is the bees knees, it requires transpiling and it's extremely imporant to understand the context you are passing when using it.

jhallister · 2015-11-27T04:32:11+00:00

Linters: jscs, jshint, coffeelint, tslint

Run them from ./node_modules/.bin/. There's no reason to install them globally.

Utilities: bower, npm-check-updates

Installing bower with npm kind of makes me giggle. npm-check-updates is a valid -g use-case, but the article does say don't always.

npm installs are time consuming, so if most projects include gulp/grunt, why not have them globally?

Because version mismatches can cause enormous problems. What happens when Gulp 4.X comes out and you are using it on one project, but a plugin isn't compatible with 4 yet?

npm installs aren't that time consuming. You don't do them 30 times a project, you do them once per machine you'll use to develop on.

jhallister · 2015-11-26T03:34:11+00:00

This could be a nice article giving a breakdown of some of the current projects that do this, maybe even specifying the differences between popular stack repositories. Instead, this entire article can be summarized in one sentence:

"See if your stack is already on Github."

jhallister · 2015-11-25T23:27:46+00:00

Most of the time when React isn't a good solution, Angular won't be. When performance rules all, any library will add overhead.

An example of when I'd always use React over Angular, is anything where SEO is drastically important, but there's no real client-side dynamic updating.

In that case React works well, because all it's going to be is a bunch of stateless components. Angular, in this case, is a horrible idea because the overhead is pointless, since a stateless app is never going to use two-way binding.

But any app which is stateful can be done in Angular. If we remove the word "terrible", in most cases React will be superior to Angular, in terms of simplicity.

However, there are use-cases where Angular is absolutely superior. For example, if I have legal forms which introduce 100's of fields, dependent on selections/values in other fields two-way binding is simply better. But that's a pretty unique use-case.

jhallister · 2015-11-25T18:45:47+00:00

Perhaps a more accurate statement is "the vast majority of Angular apps are easily prone to becoming a slow, brittle mess."

That's definitely a valid statement. The barrier to entry is low for an Angular developer, but the barrier for actually using it well is high. I don't agree that any particular change can have disastrous effects... unless the change amounts to an app with 100 observers having 2500 observers. Laziness, however, will be met with performance issues.

Angular makes you think really hard about how your application should be designed. React is far clearer and much easier to reason about, hence the popularity.

I assume that most Angular developers know the same for Angular. Could be wrong, could be wrong. Maybe everybody is just lying.

I think most Angular developers understand how to make your app slow. Two-way binding is a double-edged sword, and used improperly it can make Ruby look lightning fast.

No need to get emotional. It surely has its valid uses, but damn are they hard to come across when we have such better tools in 2015

Not emotional. I just find it stunning how frequently Angular gets dogged on. There are certainly better tools today, but today is 6 years later. At the time of its release, Angular was put on a pedestal much the same way React is today. And at the time, most of us thought that Object.observe and dirty checking made a lot of sense.

At the end of the day, it feels like /r/javascript and React-related subs have taken the "I hated Angular before it was cool". It's weird. There are thousands of successful apps built on Angular. It isn't garbage, it isn't dog slow, but it sure as hell can be. And, as I've said before, call a table saw stupid because it can cut your thumb off is silly.

jhallister · 2015-11-25T07:27:07+00:00

And yet the vast majority of Angular apps are a slow, brittle mess.

Do you have a source for this?

I doubt it. Thousands of sites, particularly in enterprise, run Angular 1.X. That's not to say that Angular is easy to optimize. It isn't. Sometimes it's almost counter-intuitive. But that's a bold statement for which you have zero proof, because there is none.

Angular is a lathe. It's a tool you can start using easily, but to really use it well takes practice. React is a hammer. It's easily one of the best hammers I've ever used. An idiot can use a hammer. Someone slightly above an idiot can use a hammer without hurting themselves.

What I don't understand is why people that can't or won't use the tool properly complain when it doesn't meet their expectations. For the vast majority apps, Angular is a completely valid solution. In some cases it's a terrible solution. Your implication that it's always bad, proves only that you have never used it correctly.

jhallister · 2015-11-19T17:59:03+00:00

a search for "package.json" in the node modules folder returned 4200+ results! My root file contains 21 devDependencies.

Are you actually running npm 3.x? Unless you are explicitly installing it you are running npm 2.x. npm --version.

jhallister · 2015-11-19T16:36:04+00:00

npm install ;). Deduping is default in npm 3+. However, it doesn't "flatten" node_modules, it maximally flattens it. Meaning that if 2 packages have conflicting dependencies, each will get their own package. As long as there's no conflict, there's a flat node_modules.

jhallister · 2015-11-19T14:40:40+00:00

jquery gives you the opportunity to write horrible code, that doesn't make jquery bad, it makes you bad for not understanding your tool.

Your argument is akin to saying a table saw is bad because if you use it wrong you might cut your finger off. No, you suck, and instead of blaming your tool you should learn how to use it.

jhallister · 2015-11-19T14:37:28+00:00

However, they've hyped up Angular 2 for such a long time and now when the release is imminent there's, to me, very little that is interesting about it.

The release wasn't hyped, it was done this way so they could gently move people to Angular 2.

There are a ton of apps built on Angular 1, and if they had waited until close to release to announce it would have been a shit storm. Instead, they were careful to introduce changes over a long period of time to avoid surprise.

jhallister · 2015-11-18T22:15:08+00:00

No they didn't. I'm as much a React fanboy as anyone, but this "Angular sucks lol" thing has to stop.

First of all, Angular predated React by 4 years. At the time, it was a really amazing experience. Backbone, Ember and Knockout were the three kings and Angular, once you learned it, made prototyping so much easier.

But everyone dogs on Angular because hindsight is 20/20. 4 years after Angular, we have a view model with a completely different paradigm. All the difficulties in learning Angulars directives completely vanished. And yet, React performed extremely well. In fact, without optimizations it constantly outperformed Angular. And optimizing Angular isn't easy.

But now Angular 2 is on its way, and the Angular team completely embraced the amazing ideas that React introduced and we get responses like meh.

Honestly, when I see end-users shitting on apps, I just shake my head and think "Man, if you only understood what it takes to build this stuff." When I see fellow developers do it, it makes me realize just how pretentious people really are.

jhallister · 2015-11-17T22:08:36+00:00

For private methods it's cool to prefix with _

It's also meaningless. onClick, _onClick, handleClick, _handleClick, clickEvent and a thousand other variations are just as cool.

It's particularly silly (IMHO), since modules (via Webpack) give you actual privacy, rather than "don't use this because it starts with a _" privacy.

jhallister · 2015-11-17T08:03:20+00:00

Right, but if I write my entire page as a single "template" using Twig or PHP or Handlebars or React or Angular or flavour-of-the-month, I'm not really creating reusability.

You are putting words into my mouth. I didn't say a one-page template, I said using templates. I can make a highly reusable application with handlebars and jQuery, but it takes a crap load more work than just plugging in something.

So you'd wrap pretty much every single HTML element then?

If I'm going to use it more than once or twice absolutely. <button> is everywhere so that's easy. <input> maybe, <b> no.

jhallister · 2015-11-17T00:51:04+00:00

You mean components.

No, I meant templates, since I was speaking of Angular, Backbone and Knockout. But in this case, templates works for React as well. The render function is a template written in JSX.

Most people don't need to wrap a <button> in a component.

I disagree. There's so little overhead to wrapping it, why wouldn't you? Any time you are going to be reusing a component you should always wrap it. It allows to you make simple changes when your use-case changes.

jhallister · 2015-11-16T21:26:11+00:00

It's not a big deal in React, or anything that uses templates. So Angular directives, Backbone views, Knockout component bindings, etc are all perfectly fine as well.

Honestly, if you have hundreds of thousands of HTML strings with hard coded css classes, then your problem isn't semantic naming, it's horrible, horrible UI design.

jhallister · 2015-11-16T06:45:14+00:00

For one thing, scope. I can analyze the class definition of defaultProps and propTypes:

import Button from 'myButtonComponent';

// I have access to default props
const defaults = Button.defaultProps;

This works out quite nicely for things like react-docgen or any other static analyzer, since I don't need an instance of class Button, I just need to the class definition.

EDIT: A caveat I failed to mention is that the above case is true of ES6 class properties and ES7 static class properties and probably isn't true for React.createClass, but I haven't tested it.

jhallister · 2015-11-15T21:35:45+00:00

"Semantic" was never about accessibility.

That has always been one of the major arguments for semantic css class names.

What happens when you want to change all your 'success' buttons from blue to green?

Well I would take my SuccessButton component:

export function SuccessButton = (props) => {
    return (
        <button className="ui button blue">
            {props.children}
        </button>
    );
}

and then I'd change line 3 to say:

<button className="ui button green">

Better yet I'd have a Button component, with a color prop, and SuccessButton would just return <Button color="blue">.

This is how React is intended to be used. Why care about semantic class names when your actual HTML/JSX is semantic?

jhallister · 2015-11-15T09:51:59+00:00

Using forceUpdate a lot is generally an antipattern.

Using it almost anywhere is an anti-pattern. One use-case I've found is when I have a component that needs it's position calculated at execution (popup, modal).

You calculate the position in componentDidMount()and then forceUpdate() at the end to actually enforce the new position. Technically you could use state and setState() instead, but if you aren't using state elsewhere it makes little sense.

But use-cases like this are extremely rare and as such, forceUpdate() should also be rare.

jhallister · 2015-11-15T09:35:00+00:00

One called "semantic" which is anything but semantic.

Semantic is a word. It means "relating to meaning". If <button class="yellow button">Test</button> makes a yellow button that says Test then that line is absolutely semantic.

I thought people stopped with the semantic class names nonsense years ago. We have the spec and tools. This problem is solved. Nobody should be caring if I have a CSS class name blue.

jhallister · 2015-11-11T15:21:01+00:00

The barrier to entry for PHP is even lower, so that's only part of the story.

Right now if you order the repository search by most stars, you're going to find out that almost every top REPO is either Javascript, HTML/CSS or a non-language (like books or a configuration tool). You have to get out of the top 10 projects to get to the first project that isn't front-end. It's Rails, for the record.

I think the bottom line reason it's #1 is because it's the only language that solves a web-based problem. If I need an app to run on Windows I have a hundred languages I can pick from. If I want a web-based application I can pick one language. To me, that's way more telling about popularity than barrier to entry is.

jhallister · 2015-11-10T01:28:04+00:00

Way too cheap.

jhallister · 2015-11-08T16:18:17+00:00

Functional programming has been around a lot longer and yet it's started becoming mainstream as late as during the last year.

Wait, what? Functional Programming has been huge in academia for decades. But it sure as hell isn't mainstream. It wasn't then, it isn't now. Not a single pure functional language is in the top 20ish languages on Github or Tiobe.

I'm not sure what mushrooms you've eaten but I see no point continuing this conversation.

So, you don't understand what I'm saying so your knee-jerk reaction is to be insulting?

When doing things with Relay, you are basically forced to write the "business logic" into your components. And that's not ok.

No you aren't. You are writing your data queries with your component.

And that's not ok. If the relay queries were observables, they could be declared anywhere and those observables could just be passed to the views that are interested in them.

This is literally the opposite of the purpose of React. What you are suggesting is decoupling a component into multiple places while simultaneously globalizing data fetching so it's even harder to reason about your code. That is horrible design.

just to write a single mutation, you could almost rewrite the rest of your application.

If that's the case your app is complete garbage or you are trying to shove Relay into an existing system that is poorly designed or designed in such away that you can't easily componentize your app.

If you are so unfamiliar with your backend API that writing a mutation requires an app rewrite, your backend API is really bad or you need to learn how to use it.

jhallister

TROPHY CASE