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

121–130 of 143 posts

Re: Front End Development Topics to Learn in 2019

#121

Post by pojzon »

Chris_Newton wrote: post #107
winstonewert wrote: post #20

Earlier quoted context omitted.

why? I mean it takes far less than 15 minutes to install a module, so why should I implement it myself?

Importing anything into a project, no matter how small, creates a new dependency. Any additional dependency introduces, among other costs: * a potential point of failure * a potential source of security vulnerabilities * a potential legal liability and maybe some licensing constraints, and * an additional aspect that needs to be maintained indefinitely and understood by any future developers. Accepting all of this ju…

Unfortunety the moment the person you explained that to understood it. 50 new young developers joined the bandwagon of "download everythink, think later"..

Thats the issue with frontend.

Re: Front End Development Topics to Learn in 2019

#122

Post by luord »

The top one should always be on top is "keep up with standard JS", it's rapidly approaching what could be considered a sane standard library.

Once the specification for web components is finished, standard JavaScript plus Babel (and polyfills) would be all that's needed to build 95% of web apps.

Re: Front End Development Topics to Learn in 2019

#123

Post by jjkaczor »

acemarke wrote: post #38
kevinflo wrote: post #28

Earlier quoted context omitted.

This (or something like it) is always the top thread. I wish this was something the frontend community cheered about, not lamented. Those 200MB of node modules are developers ad-hoc cobbling together an alternative to xcode and android studio, except entirely modular and where we have complete control. Serious application development for the open web is hamstrung by limitations and definitely in an awkward growth pha…

Yep. To repeat Dan Abramov's standard reply: > The set of dependencies that Create-React-App uses includes: > A compiler. a bundler/linker, an optimizing minifier, a linter, a development server with live reloading, and a test runner All of those are isolated and scoped to that one project, and they are all build-time dependencies only. It's also important to understand that Javascript packages are effectively distri…

>Visual Studio is easily multiple gigs

In June of last year, I had to prepare an offline Visual Studio installer for an isolated environment - the install package (with all available options) weighed in at over 50gb...

Re: Front End Development Topics to Learn in 2019

#124

Post by winstonewert »

Chris_Newton wrote: post #107
winstonewert wrote: post #20

Earlier quoted context omitted.

why? I mean it takes far less than 15 minutes to install a module, so why should I implement it myself?

Importing anything into a project, no matter how small, creates a new dependency. Any additional dependency introduces, among other costs: * a potential point of failure * a potential source of security vulnerabilities * a potential legal liability and maybe some licensing constraints, and * an additional aspect that needs to be maintained indefinitely and understood by any future developers. Accepting all of this ju…

But code I write is also a potential source of failures, security vulnerabilities, and future maintenance burden. These are costs which, for the most part, apply to code whether you import it or write it yourself.

In fact, the imported code is arguably better in many cases because if there is a problem in my code it only gets fixed if I fix it. At least sometimes, problems in my imported code gets identified and fixed by other people.

Re: Front End Development Topics to Learn in 2019

#125

Post by jenscow »

djtriptych wrote: post #30
jenscow wrote: post #27

Earlier quoted context omitted.

Like left-pad? By adding more 3rd party dependencies (and theirs) you're increasing risk.

You’re increasing risk by writing it yourself too.

Not if it's something that takes 15 minutes to implement :)

Re: Front End Development Topics to Learn in 2019

#126

Post by Chris_Newton »

winstonewert wrote: post #124
Chris_Newton wrote: post #107

Earlier quoted context omitted.

Importing anything into a project, no matter how small, creates a new dependency. Any additional dependency introduces, among other costs: * a potential point of failure * a potential source of security vulnerabilities * a potential legal liability and maybe some licensing constraints, and * an additional aspect that needs to be maintained indefinitely and understood by any future developers. Accepting all of this ju…

But code I write is also a potential source of failures, security vulnerabilities, and future maintenance burden. These are costs which, for the most part, apply to code whether you import it or write it yourself. In fact, the imported code is arguably better in many cases because if there is a problem in my code it only gets fixed if I fix it. At least sometimes, problems in my imported code gets identified and fixe…

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 the required functionality instead of building your own, that can be a trade-off worth making. It would rarely be a good idea to use a home-grown encryption algorithm, for example.

However, if we’re talking about simple functionality that you could write yourself in minutes anyway and where you would have to try quite hard to create a significant vulnerability or to need much ongoing maintenance, the costs introduced by importing the functionality instead will often be disproportionate.

Re: Front End Development Topics to Learn in 2019

#127

Post by vertline3 »

digitalzombie wrote: post #79
vertline3 wrote: post #62

Uhm I... I just think it's a bit like quicksand. In a few years, things will have shifted somewhere else. A percentage of our time should be on staying current, anyone have a good strategy?

> anyone have a good strategy? I left the industry for data science. Went back to school and fall in love with statistic. Going to try to get a biostat job. I'm trying to do side projects web app and not give a damn about the flavor flav of the month. I don't know if that's a good strategy.. it's basically peacing out. I also move most of my tech stack to plain old stuff like a simple mvc framework and no frontend re…

This peacing out is sort of exactly what I've been considering. Focusing more on algorithms or big picture things. Thanks for your perspective.

Re: Front End Development Topics to Learn in 2019

#128

Post by acemarke »

jjkaczor wrote: post #123
acemarke wrote: post #38

Earlier quoted context omitted.

Yep. To repeat Dan Abramov's standard reply: > The set of dependencies that Create-React-App uses includes: > A compiler. a bundler/linker, an optimizing minifier, a linter, a development server with live reloading, and a test runner All of those are isolated and scoped to that one project, and they are all build-time dependencies only. It's also important to understand that Javascript packages are effectively distri…

>Visual Studio is easily multiple gigs In June of last year, I had to prepare an offline Visual Studio installer for an isolated environment - the install package (with all available options) weighed in at over 50gb...

Right, exactly. Now, that can be broken down into smaller chunks based on what toolset you're intending to work with (C#, C++, web, SQL, etc), and the sizes for each toolset vary, but clearly these toolsets take up a lot of space.

Re: Front End Development Topics to Learn in 2019

#129

Post by winstonewert »

Chris_Newton wrote: post #126
winstonewert wrote: post #124

Earlier quoted context omitted.

But code I write is also a potential source of failures, security vulnerabilities, and future maintenance burden. These are costs which, for the most part, apply to code whether you import it or write it yourself. In fact, the imported code is arguably better in many cases because if there is a problem in my code it only gets fixed if I fix it. At least sometimes, problems in my imported code gets identified and fixe…

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, its gone a lot more testing and review than whatever code I'd write to replace it.

Re: Front End Development Topics to Learn in 2019

#130

Post by bjoe_lewis »

ryanbrunner wrote: post #111
lewisjoe wrote: post #98

Earlier quoted context omitted.

Here's an interesting observation from recent HN reactions to JS: + The hardcore server folks are hating JS these days, because it requires more than dropping a single script tag. + The full-stack people / JS beginners are hating JS with a passion , because they think it's unneeded complexity for their deadline. + Advanced JS veterans totally like how the JS ecosystem is rapidly maturing & solving its problems in int…

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 Dan Abramov. He did this with Redux. Now that he’s in React, I see a lot of this culture in React docs as well these days.

Bottomline: The responsibility is on the creators to stop spreading this shiny stuff syndrome.

Post reply on HN