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

Front End Development Topics to Learn in 2019

zendev.com

Post reply on HN
Print view View original

131–140 of 143 posts

Re: Front End Development Topics to Learn in 2019

#131

Post by acemarke »

bjoe_lewis wrote: post #130
ryanbrunner wrote: post #111

Earlier quoted context omitted.

I think this is all true, but one important factor is that there's currently an assumption that any serious project must necessarily use all this complexity, which makes your second point true - but not in a way that's the fault of javascript, but more the community around it. If you're making a simple site, or even a fairly simple application, the typical modern Javascript toolchain is absolutely unneeded complexity…

I have to agree with you. The shiny stuff syndrome is spreading like cancer in the front-end world. The only way to set this right is: when you create something, don’t sell it as a one size fit for all solution. State the tradeoffs as loud and clear as possible. Guide the users on what point you necessarily need the library and point them to simpler alternatives when needed. This is something I deeply respect about D…

I will say that as a current Redux maintainer, I _hate_ that I seem to have to spend more time cautioning people about when it's appropriate to use Redux, than I do actually promoting its use. :( I can't think of any other lib off the top of my head where the maintainers have had to do that.

That said, yeah, we've got a Redux FAQ entry that discusses when you should use Redux [0], and some other "caveat"-type sections scattered throughout the docs.

We're currently planning a revamp of the Redux docs structure and content [1], and we'll see if we can improve some of the messaging as part of that. Would appreciate any suggestions you can offer.

[0] https://redux.js.org/faq/general#when-should-i-use-redux

[1] https://github.com/reduxjs/redux/issues/3313#issuecomment-45...

Re: Front End Development Topics to Learn in 2019

#132

Post by commandlinefan »

mcintyre1994 wrote: post #101
calibas wrote: post #78

Earlier quoted context omitted.

A while ago you could get away with doing front-end dev with nothing but a text editor and an FTP client, compared to those days I can see how things seem absurd now.

I know what you’re saying, but you still can. React/Vue can be included as a script tag. You won’t get a transpiler or a bundler or a linter or types, but you didn’t before with just a text editor either. And honestly if you just want to sprinkle some JavaScript onto a website it is easier now, you probably don’t need jquery to do your Dom stuff and you probably don’t need to worry about browser support for what you’…

Not only can you still, but the documentation assumes that you are. If you want to use a more “advanced” tool, you’ll have to mentally map the command-line examples in the docs to whatever the tool does.

Re: Front End Development Topics to Learn in 2019

#134

Post by Chris_Newton »

winstonewert wrote: post #129
Chris_Newton wrote: post #126

Earlier quoted context omitted.

But code I write is also a potential source of failures, security vulnerabilities, and future maintenance burden. Perhaps, but the mere act of having an external dependency creates all of those liabilities on a significant scale in addition to any risks inherent in whatever functionality is being implemented. If those inherent risks are also significant and you can mitigate them by importing a good implementation of…

> Perhaps, but the mere act of having an external dependency creates all of those liabilities on a significant scale in addition to any risks inherent in whatever functionality is being implemented. Why? What is different about an external dependency that creates this risks in excess of writing it myself? To me, these risks all seem less when importing then writing it myself. No matter how crappy the module I find is…

Why? What is different about an external dependency that creates this risks in excess of writing it myself?

You seem to be answering your own question there: the extra risk is because you aren’t writing it yourself. The extra risk is because you are trusting an external source to provide what it says it will and that whatever it provides will then work as described.

As we have seen all too many times, these things are not guaranteed. The repository can be down. Semantic versioning might not be specified correctly. Packages might be transferred to a new maintainer who then abuses them to deliver malicious payloads. Or the package you pick might simply have bugs.

No matter how crappy the module I find is, its gone a lot more testing and review than whatever code I'd write to replace it.

I can see no basis for that assumption in the world of JS and NPM. Anyone can set up an NPM account and then push code for public consumption. Giants like react have been brought down by tiny packages like left-pad.

And yet, I could have written the code for left-pad, complete with a little test suite, in less time than it has taken me to write this HN comment, and probably so could a million other people. How much collective development time do you think was lost because no-one at Facebook actually did?

Re: Front End Development Topics to Learn in 2019

#135

Post by winstonewert »

Chris_Newton wrote: post #134
winstonewert wrote: post #129

Earlier quoted context omitted.

> Perhaps, but the mere act of having an external dependency creates all of those liabilities on a significant scale in addition to any risks inherent in whatever functionality is being implemented. Why? What is different about an external dependency that creates this risks in excess of writing it myself? To me, these risks all seem less when importing then writing it myself. No matter how crappy the module I find is…

Why? What is different about an external dependency that creates this risks in excess of writing it myself? You seem to be answering your own question there: the extra risk is because you aren’t writing it yourself. The extra risk is because you are trusting an external source to provide what it says it will and that whatever it provides will then work as described. As we have seen all too many times, these things ar…

As we have seen all too many times, these things are not guaranteed. The repository can be down. Semantic versioning might not be specified correctly. Packages might be transferred to a new maintainer who then abuses them to deliver malicious payloads. Or the package you pick might simply have bugs.

Fair enough, most of those are legitimately risks of external code that doesn't apply to internal code. However, I object to object that nobody writes bug-free code so the possibility of my chosen package having bugs isn't such a case.

> I can see no basis for that assumption in the world of JS and NPM

I overstated my point there.

> Giants like react have been brought down by tiny packages like left-pad.

Its a nit-pick, but react wasn't broken by left-pad. Babel was broken which is almost always used with react.

Re: Front End Development Topics to Learn in 2019

#136

Post by btbuildem »

juddlyon wrote: post #4

This is a solid list, but front end dev has gotten a bit absurd. I feel like I need to install 86,000 dependencies via NPM to do something that server-side frameworks already figured out. I was following a simple Vue/Vuex tutorial the other day and my node_modules directory was 200MB+. Use yarn or npm to install XYZ.... What's the difference? Why do I have to google this as step 0? Why do you assume I know the intric…

I've made the decision to not use NPM, or any front-end build chain tools.

Downsides: everyone else is using those things, it's not even an assumption, it's ground under their feet.

Upsides: SO SIMPLE. make handles any build / deployment scripting. Localized dependencies. Nothing changes without me taking an explicit action.

Re: Front End Development Topics to Learn in 2019

#137

Post by btbuildem »

juddlyon wrote: post #87
Etheryte wrote: post #42

> CSS grid > If you’re still using heavy-weight grid frameworks from UI toolkits like Bootstrap or Foundation, you are falling behind. This is a pretty sensationalist way to word this and honestly an absurd statement as a whole. If you have a public-facing site, ignoring everything that isn't up-to-date is a luxury you can't afford and blunt statements like these show ignorance in that regard.

Try explaining when to use Flexbox vs CSS Grid vs Floats to someone who isn't a hardcore front-end coder. Then it's time for PostCSS, because now we use JS to write CSS.

You can try to explain it like this: Grid behaves in a way that makes sense. Flex a little less so. Everything that came before it is a complete, absurd nightmare.

Re: Front End Development Topics to Learn in 2019

#138

Post by karmakaze »

acemarke wrote: post #90
karmakaze wrote: post #85

Earlier quoted context omitted.

The 'type'ing with PropTypes which required much typing. Also having to edit 4 or more places to add one thing. Let's see there's where the UI calls the action, the action, the api request, the reducer and finally the render of the data along with any new proptypes you introduced copied to each consumer. I imagine it could be better with a different state management library or maybe ReactReason or TypeScript. The oth…

PropTypes aren't required. Also, the "action" stuff is about Redux, not React. For Redux specifically, we've got a new `redux-starter-kit` package available. It helps simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state without writing any action types or action creators by hand. I'd encourage anyone using Redux to try it out a…

Whenever I read the source for React apps, I see a lot of machinery that varies depending on library choices, PropTypes and Redux are just examples. With Vue apps more of the source appears like things for the application and not the machinery. I also greatly value the separation of , code, and style but still kept in a single file per component. All of this may be possible with React, but with Vue it's the default.

Re: Front End Development Topics to Learn in 2019

#139

Post by mncharity »

ryanbrunner wrote: post #112
mncharity wrote: post #83

Earlier quoted context omitted.

2010: The food is poor, the seats are uncomfortable, the wifi is slow, and we're running half and hour late. 1910: We dream of human flight. 2018: So many dependencies; so much disk; who can understand why it all exists; how can anyone stay current; how can you trust it all. 1981: We dream of reusable software, of assemblable software components, of sharing.

I don't totally buy this comparison. People aren't bemoaning that shared libraries exist in the first place, they're arguing that Javascript's particular approach to them isn't great. Javascript didn't invent shared modules, but their particular approach has led to an explosion of libraries with marginal utility, an anemic at best standard library, dependency management that has historically been a big source of prob…

> their particular approach has led to [...]

So, paraphrasing part of that: it's too easy for too many people to share too small pieces of their code; and too easy to use them; which reduces the incentives for centralized monoliths? Ok. :P :)

I'll agree that javascript's ease and culture of fine-grain sharing raises still regrettably-unaddressed needs for social and technical infrastructure beyond the "1990's CPAN, but now as a github ecosystem" currently in widespread use.

> I don't totally buy this comparison.

Hmm, so upon reflection, maybe that's right. Consider an "npm code quality can be abysmal" complaint. Which in part unpacks as "I wish it was harder for mediocre programmers to share their code". An analogy for "this airplane, is this slow wifi really the best they could do?" might be "Sorting on aggregate project-level stars is the best we can do? Really? Not even Consumer-Reports-like multi-attribute ratings?" In contrast, an "isn't npm horrible - there's so much bad code" seems more like "abysmal wifi... we should be driving instead". Pointing at the community-wide fine-grain sharing as the problem, rather than at associated technosocial debt, or at renormalized-by-success expectations.

Yes, the npm ecosystem has various and serious flaws. But it still seems the closest we've yet managed to come to a large diverse community easily sharing code.

Re: Front End Development Topics to Learn in 2019

#140

Post by mncharity »

digitaltrees wrote: post #86
mncharity wrote: post #83

Earlier quoted context omitted.

2010: The food is poor, the seats are uncomfortable, the wifi is slow, and we're running half and hour late. 1910: We dream of human flight. 2018: So many dependencies; so much disk; who can understand why it all exists; how can anyone stay current; how can you trust it all. 1981: We dream of reusable software, of assemblable software components, of sharing.

Absolutely awesome. Is it ok if I use this myself in the future?

Disney/Berne-wise? CC0. Inspired by Louis CK's Everything Is Amazing And Nobody Is Happy. s/reusable software/code reuse/ was the phrase in use.
Post reply on HN