Hacker News Reader

I have no idea what "professional work" could possibly mean in that sentence. The things that you have deemed superfluous are the tools of the trade. We don't use every tool on every job, but when we do use them, its because they make our work easier!

Someone who doesn't know that lodash exists will reinvent lodash, and do it poorly because JS has crazy edge cases.

Someone who hasn't experienced Bootstrap's crazy, nested selector hierarchies and pseudo-selectors will end up creating their own CSS hell.

Someone who doesn't know about flexbox will end up writing who knows what instead of 'justify-content: flex-end' (or even vertical align).

react-router has been a disaster, but that doesn't mean that rewriting it yourself will be great.

Someone who doesn't know the purpose of Redux will eventually end up with spaghetti callbacks or a building a much worse clone.

Every single project I've seen that uses Redux without Immutable ends up creating a worse Immutable.

Could someone build something without any of this knowledge/experience and throw it on the Internet? Sure! Would I be happy inheriting (or even using) that "reasonable application"? No!

I used to feel like underscore was an absolute requirement to do anything serious in Javascript, but I'm not sure I've used it even once since switching to ES6. If you want to say lodash is ultra-important, fine; like I said, it was a nitpick, since "learning lodash" basically means "reading the documentation for a utility library".

I don't know what you mean about Bootstrap, since Bootstrap (or something like it) is one of the things I do think new React developers should learn.

If you're using a CSS framework like Bootstrap or Foundation, I'm not convinced that an intuition for flexbox is at all important.

I think you'd do a better job than react-router just implementing it yourself. It's a couple of functions worth of browser glue to handle navigation events, and then a loop; there's even a utility library (path-to-regexp) that does the only "interesting" thing that react-router does. My point in calling out react-router is that it is a nightmare to work with and is an actual obstacle people have to working in React, and that obstacle is pointless; just skip it.

I strongly disagree with you about Redux, and someone else who disagrees with you is Dan Abramov.

None of those are react specific.

> because they make our work easier

This seems to be my biggest pet peeve with the JS ecosystem as a whole; people chase things that are easy to learn rather than simple to reason about once learned and the result is almost always a convoluted mess of a codebase, regardless of the project.

I used jQuery, then Underscore, and later lodash; now I'm using ClojureScript and wondering why I ever could enjoy any of those crippled FP alternatives in the past.

"Someone who doesn't know about X will create its own worse version" is true, but it also applies to you and everyone else :) We don't know what we don't know (thats meta-ignorance) and we tend to assume what we do know is the state of the art, it quite usually is very far from it!

I’m a professional react dev, currently using it with TypeScript.

I don’t know the last time I needed to use a lodash function was - the point is, JS abstractions have been solidifying and advancing, and now if you use TS, you really don’t need much else.

It’s not because those tools and techs aren’t useful - it’s because the higher level blocks of the language have advanced.

> will reinvent lodash

Someone who knows modern JS inside and out will see lodash as yet another unnecessary dependency.

> Someone who doesn't know the purpose of Redux

Knowing the purpose of Redux has nothing to do with knowing or using Redux. Write a couple medium-size apps in React. Congratulations, you now know the problems that Redux aims to solve.

If your team doesn't have the discipline and experience to write a maintainable app without Redux, dropping Redux in isn't going to make it better and probably will make it worse.

The main problem with modern Web dev is that we think it's necessary to solve every problem by layering on ever more and more shiny crap on top, rather than focusing on a small set of inescapable tools and mastering them.

Want to be a React developer? Master HTTP, HTML, CSS, JS, and React. Then you'll know if you need lodash (nope) or a CSS framework (maybe) or Redux (probably not) and you'll be well equipped to make those decisions according to the project and team.

Of course, if this wisdom were commonly heeded, we wouldn't have this:

    $ create-react-app foo && find foo/node_modules -type f | wc -l
    20444

Which shows that in a modern "hello world" React app there are 20k files of dependencies installed out-of-the-box, with 900+ packages pulled from NPM. Good luck doing a security audit on that.

And we probably wouldn't have "awesome" lists of only the 2000 most important things you need to know to be a modern web dev, either.

You wouldn't want to use an application that uses array prototype.map > _.map? That's quite the dogmatism

That's really stretching the definition of "professional work". If you're just gluing third party components and libraries together you're going to end up with a bloated mess.

This is why javascript/front-end developers get so much flak - there is a prevailing opinion that you can just fake it and not bother to learn best practices, not bother to test, and not bother to care about performance. If you do not consistently produce work of professional quality you just might not be a professional.

If you've invested the time to derive a first-principles understanding of why every element in a React environment works the way it does, and what the alternatives are, and why you're going to use any given alternative, I can understand being irritated with the idea that there's a happy path that people can traverse to get to your level of productivity with 1/50th the amount of effort.

What I don't really get is the reason why their work is going to be less professional and effective than yours will be; among other things, they're much less likely to pointlessly reinvent wheels.

Really, the critique you're delivering applies only to a couple of the points I'm making, and, subtextually, it really applies primarily to the use of CSS/React frameworks like Bootstrap and Material and Foundation and Grommet. I think an ordinary developer can throw a dart to pick any of those frameworks and end up with better, less-janky, more usable UI than they would get by DIY'ing it first (and, inevitably, adopting a framework anyways).

It's a weird quirk of web development, not shared by any of the other kinds of front end development I've been exposed to in the ~22 years I've been shipping code, that "pro" UI has to be done from scratch. WinAPI and OSX developers get UI toolkits from the platform vendor, and while you might work outside those toolkits for some custom stuff, eschewing it entirely will get you looked at funny.

But use a decent UI toolkit on the web and you're "just gluing third party components together".

Its not so much about re-inventing the wheel but more about understanding how the underlying system actually works.

So yes, go ahead and use a framework if that helps but when your UI Designer gives you something that doesnt neatly fit into a framework component you need to know enough to implement it yourself right?

Also - understanding how it actually works also helps when the JS community rallies around the next big thing 6 months down the road. I still find a lot of devs who cant do basic DOM manipulation without pulling in a jquery dependency.

I’m by no means a full time UI/front end dev - I do it when I have to. Over the years as css has improved and my understanding has improved I find myself less inclined to use a framework because doing it yourself isnt difficult and you’re not stuck fixing bugs and issues in the underlying framework and fighting against it to do whatever weird thing your design requires.

I don't know if "difficult" is the word I would use. Is a mail merge in Microsoft Word "difficult"? I think probably not. But it would still take me longer to get a mail merge working in Office than it would for me to implement and test a topological sort or a breadth-first graph traversal. That's approximately how I feel about the level of difficulty involved in DIY-ing CSS and layout. I could get really good at it, I'm sure --- but why would I? Other people got these details right already, and did a better job of it than I would (it was, at the time, the most important thing they worked on, and a perfectly laid-out button or sidebar is always going to be very far down the list of most important thing I work on).

Honestly --- and this isn't fair but I am just being candid about my impressions --- the pushback I see to relying on frameworks reads to me as a combination of specialist front-end people feeling threatened and of dilettante developers being irritated that something might be invented somewhere other than here. But if you're using React at all, hasn't that ship sailed? Oh, wait, there are like 10 bespoke vdom JS frameworks now, so I guess it hasn't.

Buttons, sidebar, grid systems, and vdom libraries are commodities to me. I think they are and should be commodities to 80-90+% of all applications that get built anywhere. Build an online pharmacy or trading position and inventory tracker or continuous integration system or CDN console and I guarantee you that nobody who pays money for it will give a shit whether your buttons came from Foundation or you lovingly handcrafted them yourself.

I dont disagree with you.

I guess you’re coming at this from “I need to put this together and it needs to look decent.”

I’m coming at this from “here are the psds from our design team - go implement that”

In my experience consulting for basically every kind of company that ever makes software, most front-end development follows the former pattern, not the latter.

I agree preemptively that you aren't going to get a job on the front-end team at Square without an intimate knowledge of how modern HTML layout works. But that's not the problem we're trying to solve with posts like these; rather, it's "where do I start". Here's where to start.

> there’s a happy path

The problem is that (if there really is such a happy path) it’s different for every person, dependent on that person’s previous experience, and impossible to determine until you know all the other stuff. You don’t know what you don’t know, and somebody who’s advising you ALSO doesn’t know what you don’t know.

I’ve tried, over and over again, to “just do it” instead of taking things slowly and deliberately (especially because I always have a boss breathing down my neck to “get it done already”) and I always run into completely inexplicable stack traces that Google and StackOverflow can’t help me with. (Or is it just me?). However, when I finally bite the bullet and take the “hit” for the lost productivity spent reading the documentation, working through smaller, simpler examples before building up to the “real” production application, everything is clear, the stack traces make sense, and the application works like it should. The only problem is having to account to the merciless time tracking system for the week or two that I “wasted” on something as trivial as “learning”.

I, too, need to understand how the things I’m using work before I am able to use them efficiently.

Whew, I thought I was just crazy.

I’ve been where you are. Its not a good place. There are better workplaces.

> It's a weird quirk of web development, not shared by any of the other kinds of front end development I've been exposed to in the ~22 years I've been shipping code, that "pro" UI has to be done from scratch.

Back in the 2004-2008 these frameworks were not well maintained and their coverage (the amount of elements/styles) they have was very small. They also were, uh, pretty ugly. I think that what made my opinion about them at the time.

But things have changed. Bootstrap now is well used, maintained and you can purchase professional styles for it.

For (on a limb here) ~80% of all applications built professionally, making it look better or even just different from the default Bootstrap look-and-feel is a waste of time and money. Users don't care.

There are applications where they do care. The pathology is, people who talk about UI development online act as if the ratio were reversed, and that not looking like stock Bootstrap should be a top-of-mind concern for people building random business applications.

Interesting perspective: I think the precise opposite is true.

Redux, react-router, design patterns are gluing third party components together. The number of people who blindly run create-react-app without a hint of real understanding of what boilerplate it installs, or how many dependencies it pulls in, what those components do, is overwhelming.

You're right: the prevailing opinion is that you can just fake it; drop in redux, follow a nice straightforward guide on creating some actions and reducers step by step without having to make any real architectural decisions about application state or even fully understand the mechanics of dispatch lifecycle.

(Note: not a criticism of Redux, Redux is fine, rather a criticism of any ecosystem where hordes of relative beginners run automated boilerplate generators and slap together convention-over-configuration apps run on the most populist trending paradigm with no attempt to understand the—possibly very good—reasons these patterns became fashionable)

tptacek is pointing out that one can focus on learning your individual components (general definition of the word, not React.Component) properly, rather than learning the "way" to put all the recommended bits together at a high level and not understand each deeply. e.g. learn React, rather than trying to learn React+Redux+router; it will give you a much more professional understanding of the boundaries between these dependencies too.

> If you do not consistently produce work of professional quality you just might not be a professional.

I'm sorry but this sentence comes across a little conceited. If you are unable to grok the composition of your own product how can you even begin to ascertain its quality?

As someone who's pretty far down the rabbit hole on a bunch of these fronts, I think this is wonderful advice. Many of these are tools to solve very specific problems, and you should make sure you have those problems first.

The only thing I'd differ on is the semantic HTML advice. What you're saying is true modulo accessibility, but accessibility is (well, should be) table stakes for professional work. And while the community has come up with some really nice individual abstractions around tricky a11y concerns, I haven't seen a way to get good results without at least some knowledge of HTML semantics. I'm not implying you don't care about a11y -- it's totally possible I've missed some better ways of doing things.

I agree fully. I think a lot of people who claim that someone needs to know those things to be employable are just elitist. It’s no different those who claim one needs a Ph. D. in math/statistics to grok machine learning.

I’ve found that the best way to learn is top-down: identify the problem and then start learning the bits and pieces you need to solve it and go as deep as necessary (but no more).

> really understanding "semantic HTML" (if you know what div's and span's are, you're ready to get to work)

If you're not willing to at least think about making things accessible to screen readers, you're not being "professional".

I've still not found the time to really look at reason+react - but I strongly suspect that the "return" on learning reasonml is much better than lodash+js+react+redux.

As for loads in a post es5 (never mind es6) world - I agree. I briefly contemplated adding lodash to a legacy project (jquery, not spa) - but found that es5 without any transpiling/shim gave me enough to do some functional refactoring without adding an additional dependency.

Anyone have experience with reasonml in a real, greenfield project?

>- design patterns --- in fact, I might argue that you're better off not reading about design patterns, which are kind of an architectural blind alley,

I have to disagree with this one. People who don't know design patterns are doomed to reinvent them anyways... badly. Even worse, without a common language to describe code structure, communication with team members is harder than it needs to be. Design patterns often get a bad rap because some people get really excited when they learn them and they try to use them inappropriately. But the correct usage of design patterns is the difference between inexperienced devs and experienced devs.

This might be broadly true. But I think in the context of what tptatek is talking about -- that is, getting low-ceremony mileage out of React -- it's not. The reason is React's main abstractions of declarative components and one-way data flow are already well-suited to describe most of the UI problems you'll face.

(I'm not sure if you mean "design patterns" in the general naming of abstractions sense, or if you mean Gang of Four specifically. If the latter, I'll point out that many of the GoF patterns really aren't relevant to Javascript unless you're writing it in a very OO style)

But the correct usage of design patterns is the difference between inexperienced devs and experienced devs.

This might be true but is probably not causal. That's one of the fundamental problems with design patterns as a thing-you-ought-to-learn. They're not that useful or elucidating when you don't understand what they're for and when you understand what they are and what they are for, there's not all that much to be gained from someone cataloguing and naming them for you.

If you are building a small webapp where the difficulty is in WebSocket, updating a small user interface, etc... then maybe. But some sites require different things. You can't run a large eCommerce site with hundreds of sections/styles and not use CSS preprocessors or CSS architecture.

CSS could get more sophisticated than any React work. You can fix yourself with small patches but if you have thousands of pages this can't happen. It becomes suicidal and unfixable (you'll need to rework the whole CSS to SCSS and have a CSS architecture).

Of course you can- many did that before CSS preprocessing was a thing.

GoF Design Patterns is still my goto cure for insomnia.

how does ES6 remove dependency of Moment? just curious.