Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Front-End Developer Handbook

frontendmasters.com

Post reply on HN
Print view View original

21–30 of 73 posts

Re: Front-End Developer Handbook

#21

Post by nothrabannosir »

zdragnar wrote: post #17
FLUX-YOU wrote: post #9

Earlier quoted context omitted.

Looking back and forth between code and docs just to remember the shape of returned objects is annoying and probably the worst for productivity. I imagine most people using vanilla JS have significant amounts of objects memorized.

IDEs like webstorm can ostensibly be quite helpful if you use jsdoc style annotations. However, in my experience, once a code base is big enough, you can open almost any file and find documentation that's out of date, incorrectly copy-pasted, or some other major issue. TS, on the other hand, at least forces you to stay correct, which is ultimately what convinced me to switch.

> jsdoc style annotations

Which are a form of type annotations. Case in point: the typescript compiler can actually parse those, in .js files, and yield appropriate warnings on errors. See the //@ts-check annotation.

Re: Front-End Developer Handbook

#22

Post by hn0 »

poof131 wrote: post #7

"A whole lot of developers adopt static type checking for mostly subjective reasons or band wagon emotions. Some sell out completely to Typescript and the Microsoft way of doing things while others take on a slower approach with Flow. One thing is for sure, most developers don't need types, they are simply complicating already complex problems and solutions. Like most things, most of this trend is subjective dogma no…

Hmm, complicated? I think JS’ type rules are much more weird and complex than the average static type checking solution.

Re: Front-End Developer Handbook

#23

Post by lioeters »

Noticed that "Learn Node.js" is a single short page. These days, I think frontend devs are increasingly working with complex build and test flows that require deeper familiarity with Node.js, for example, npm, Webpack, etc.

Re: Front-End Developer Handbook

#24

Post by pjmlp »

NullPrefix wrote: post #4
pjmlp wrote: post #2

The title should be Web Front-End Developer Handbook. Native desktop, mobile, TV and infotainment systems are also front-end.

Technically you're correct, but... web browser is the default front end. Technically command line programs are also front end.

It is surely not the default frontend on many business that still rely on native apps, on mobile devices, device displays, air gaped networks, factory automation and robot control systems, ....

Re: Front-End Developer Handbook

#25

Post by baron816 »

poof131 wrote: post #7

"A whole lot of developers adopt static type checking for mostly subjective reasons or band wagon emotions. Some sell out completely to Typescript and the Microsoft way of doing things while others take on a slower approach with Flow. One thing is for sure, most developers don't need types, they are simply complicating already complex problems and solutions. Like most things, most of this trend is subjective dogma no…

> Making a large refactor without types is the wild west. Types help provide structure/understanding about the data flowing through your system.

If you’re working on a large, unstructured project that you’re trying to refactor, you’re problem probably isn’t with the types. It’s that the people working on it used types as a crutch so that they thought it was okay to write classes that were thousands of lines long with giant methods that are impossible to make sense of.

The interview question I’ve been asking lately is about object design. I tell them not to put things into one big method—that it needs to be readable for junior devs. They always ignore me. The ones who struggle the most are the ones who try to do it in a staticly types language (which I’m sure you agree is crazy to use in an interview for a tiny problem). Their mental model forces them to think about types first, and they then can’t think about anything other than that and just making the thing work.

If you aim to keep your objects and you methods small enough that anyone can read them and make sense of them, then you don’t need static types and refactoring becomes easy. There are plenty of developers of mediocre talent who never use types and are able to build huge features and projects quickly and with high maintainability and flexibility because they write code that sticks to good object oriented design principles.

A class I work on regularly has become so big that everyone, especially the more senior, more talented engineers at my company are too afraid to touch, let alone try to refactor. It’s stayically typed.

Re: Front-End Developer Handbook

#26

Post by zdragnar »

nothrabannosir wrote: post #21
zdragnar wrote: post #17

Earlier quoted context omitted.

IDEs like webstorm can ostensibly be quite helpful if you use jsdoc style annotations. However, in my experience, once a code base is big enough, you can open almost any file and find documentation that's out of date, incorrectly copy-pasted, or some other major issue. TS, on the other hand, at least forces you to stay correct, which is ultimately what convinced me to switch.

> jsdoc style annotations Which are a form of type annotations. Case in point: the typescript compiler can actually parse those, in .js files, and yield appropriate warnings on errors. See the //@ts-check annotation.

It'd be a lot less effort to just use TS imho.

Re: Front-End Developer Handbook

#27

Post by codingdave »

jpd- wrote: post #18

"A developer who can code the front-end, back-end, API, and database isn't as absurd as it once was (excluding visual design, interaction design, and CSS). Still mythical in my opinion, but not as uncommon as it once was." I see this attitude expressed a lot among people who identify as "front end" developers and it seems like psychological projection to me. I would count myself and a number of close friends and asso…

Agreed - almost every developer I know can code full stack. They are typically better at some parts than other, so they choose to specialize, but the full ability is there. I see it even more often outside of the startup world - in Enterprise IT, you normally not only know the full stack, but multiple products at each level to support all the products that end up running inside a large company. Again, you are not an expert in everything, but you gain a broad knowledge base. And such a knowledge base, held by almost all enterprise IT coders, is hardly mythical.

Re: Front-End Developer Handbook

#28

Post by Blackstone4 »

jpd- wrote: post #18

"A developer who can code the front-end, back-end, API, and database isn't as absurd as it once was (excluding visual design, interaction design, and CSS). Still mythical in my opinion, but not as uncommon as it once was." I see this attitude expressed a lot among people who identify as "front end" developers and it seems like psychological projection to me. I would count myself and a number of close friends and asso…

Agreed. Just look at this article: The Death of Front-end Developers (https://medium.com/@jerrylowm/the-death-of-front-end-develop...)

The author states: "Even without the divide on the front-end I still hear lots of people claiming they’re full stack developers — I guarantee they’re not."

I don't understand his perspective here. If you work on the front and backend then you are a full-stack developer. If on the other hand, a full-stack developer claimed to be an expert on both the front and backend...then I would be wary.

I was a backend dev who can now also do frontend :)

Re: Front-End Developer Handbook

#29

Post by nxc18 »

baron816 wrote: post #25
poof131 wrote: post #7

"A whole lot of developers adopt static type checking for mostly subjective reasons or band wagon emotions. Some sell out completely to Typescript and the Microsoft way of doing things while others take on a slower approach with Flow. One thing is for sure, most developers don't need types, they are simply complicating already complex problems and solutions. Like most things, most of this trend is subjective dogma no…

> Making a large refactor without types is the wild west. Types help provide structure/understanding about the data flowing through your system. If you’re working on a large, unstructured project that you’re trying to refactor, you’re problem probably isn’t with the types. It’s that the people working on it used types as a crutch so that they thought it was okay to write classes that were thousands of lines long with…

Sounds like you're permanently stuck living in amateur hour... I have never seen anyone past high school level CS try to pull the shit you describe. Those aren't problems of static typing, they're problems of poor dev talent.

Re: Front-End Developer Handbook

#30

Post by [deleted] »

baron816 wrote: post #25
poof131 wrote: post #7

"A whole lot of developers adopt static type checking for mostly subjective reasons or band wagon emotions. Some sell out completely to Typescript and the Microsoft way of doing things while others take on a slower approach with Flow. One thing is for sure, most developers don't need types, they are simply complicating already complex problems and solutions. Like most things, most of this trend is subjective dogma no…

> Making a large refactor without types is the wild west. Types help provide structure/understanding about the data flowing through your system. If you’re working on a large, unstructured project that you’re trying to refactor, you’re problem probably isn’t with the types. It’s that the people working on it used types as a crutch so that they thought it was okay to write classes that were thousands of lines long with…

[deleted]
Post reply on HN