
Front End Development Topics to Learn in 2019 - theBashShell
https://zendev.com/2019/01/15/frontend-development-topics-to-learn-in-2019.html
======
juddlyon
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 intricacies of Webpack? Is this tutorial for
Webpack 4 or Webpack 3?

I'm exaggerating a bit but honestly, I get the same feeling of rage that I
used to get trying to understand the box model during the IE 6 era.

~~~
kevinflo
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 phase, but it's marching
towards a possible future of competing with native mobile apps and the two
companies to which they're entirely beholden. To me, 200MB of tooling is not a
sign of cruft, but of steady and imperfect progress.

Edit: and for the record, xcode is a 13.8GB install

~~~
acemarke
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 distributed as source, which affects the
number of files on disk. (Granted, many NPM packages do include unnecessary
files in the published artifacts, but Javascript itself is a major factor
there.)

As you said, a full-blown IDE like XCode or Visual Studio is easily multiple
gigs, and if you were to look at the actual file size on disk of any C++
compiler toolchain, that would be a minimum of dozens of MB - those are just
usually preinstalled on Linux or Mac systems.

So, context is pretty important here. A couple hundred MB for a complete JS
build toolchain is understandable. I don't think it's necessarily _good_, and
I think it can be improved a lot (especially with upcoming tooling like NPM
Tink and Yarn PnP), but it's not the catastrophe many make it out to be.

~~~
lewisjoe
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 interesting ways.

And there's people like you (the latter), constantly explaining the former
groups that JS isn't so bad.

I'll see if I can write a blog (or a book if it has to be) on each part of JS
ecosystem that has changed with detailed explanations on why it is better.

I already wrote a piece along those lines -
[https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c...](https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c28f7020a3a523)
but I guess I (or someone else) can do better.

~~~
ryanbrunner
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. It's
not even React - many developers will turn their nose up on anything that
isn't using Redux / Typescript / GraphQL / whatever flavour of the week is
popular, even on sites where Javascript itself is probably not that big a
requirement. As an example, we're all talking on a site that has almost no
Javascript and works perfectly well - but I have no doubt that if you hired a
developer to build a site like this in 2018 it would absolutely use a typical
complex setup.

That isn't Javascript's fault, really - no library demands that you use it for
everything, and many like Redux make it a point to push users away from using
them inappropriately. But the Javascript community is currently in a phase
that's probably unhealthily pushed towards the new, shiny, more complex
library, regardless of how well it suits the problem.

~~~
bjoe_lewis
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.

~~~
acemarke
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](https://redux.js.org/faq/general#when-should-i-use-redux)

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

------
Etheryte
> 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.

~~~
cageface
CSS grid is supported in all modern browsers. Depending on your audience,
there is a very good chance you can use it in favor of older and much less
powerful and pleasant grid layout tools.

~~~
koboll
According to CanIUse, it's supported in browsers used by 88% of users in the
United States. Which means sites will fail to render properly in 12% of
browsers.

Developing for a b2b or enterprise product? That percentage is going to be
lower. Developing for users outside advanced industrial countries? Lower.

And it's not like you can polyfill it or use a fallback -- CSS grid is a
completely new way of building layouts that isn't amendable to automatic
fallbacks, so you literally have to build _an entirely different parallel way
to do the same thing_ if you want those 12% to have the same experience. At
that point... why bother using CSS grid at all?

The simple and sad fact is that until IE 10/11 fall totally out of use, grid
is simply not worth learning for many projects.

~~~
cageface
CSS grid works in IE11 with a few restrictions. Requiring IE11+ support is
quite common for websites targeting the US market at least. Unless your
audience is pretty unusual it's easy to make a case for excluding older
browsers than this.

~~~
naniwaduni
You can use what is, essentially, a totally different grid layout engine which
works in IE11 only, but fortunately doesn't interfere too much with the more
recent grid spec since everything is vendor-prefixed.

It is _not_ just "a few restrictions"; you can't even get close to a grid-
based layout that works in IE10/11 by accident.

It's doable, but practically, it might be a fairly reasonable decision to give
up on giving IE the nice layout and falling back to a flat "mobile" layout, if
you're doing progressive enhancement properly.

~~~
koboll
On my own personal projects where I have the authority to make broad
declarations like "IE11 is marginal enough to be served the mobile version",
that works. But try explaining that to a corporate executive. The cost-benefit
analysis is not really in favor of jumping to grid for most mass-market
products.

------
pascalxus
It's pretty difficult to keep up with all the new frameworks these days.
That's why I created a faster way of learning. I noticed that everytime I
wanted to learn a new framework or new library, I was always creating examples
and modifying them to learn how they worked. So, I created a Tutorial/Example
code website that combines tutorials with real working examples:
[https://codeorc.com](https://codeorc.com)

By not having to set up every single example anew, I hope this saves people
some time in allowing them to learn things quicker.

~~~
ollerac
I've taught people coding a few times and I always start with a game, but it's
hard keeping it simple enough for them to understand. This tutorial looks like
a great place to start. Thanks!

------
Jeaye
Has anyone realized the wheels on the treadmill are spinning _toward_ the
carrot? Shouldn't be tough to keep up.

~~~
jenscow
ah.. perhaps the aim is for the developer to escape the carrot.

~~~
james_s_tayler
edit: you have much to learn young grasshopper

------
austincheney
Many comments here are concerned with the ever changing trends, downloads, and
such. Frontend technologies really don’t change that fast.

If being a stronger frontend developer is a priority focus on the basics. I
have received some favorable feedback about this list that requires no
additional downloads
[https://github.com/prettydiff/wisdom/blob/master/Web_Educati...](https://github.com/prettydiff/wisdom/blob/master/Web_Education.md)

------
MilanoCookie
Related to this topic:

What are the minimum technologies needed to get a solid front-end stack, with
a nice balance between modern features without framework/library/build
tool/transpiling hell?

For example, I don’t want to learn TypeScript when vanilla JavaScript will
suffice. I’m wary of picking up the “hot” new frameworks because they haven’t
stood the test of time and may get deprecated/irrelevant.

Basically, I want to have a flexible and minimalist stack, but also with a
good balance of features (i.e. not just a static HTML site).

Any ideas?

~~~
root_axis
I'd strongly urge you to reconsider using TypeScript. At this point there
isn't much difference between TypeScript and ES6 (besides the types) and types
are a gigantic maintainability booster and significantly reduces bugs. The
TypeScript language server also provides high quality autocomplete and jump-
to-definition functionality in your editor of choice. It's very helpful to be
able to enumerate through object methods and properties for 3rd party
libraries as well as your own application code.

~~~
MilanoCookie
Thanks, I’ll look into TypeScript more.

------
lucidone
I've been away from front end for about half a year while doing Node work on
the backend. It's intimidating. There are too many choices, which correspond
to too many libraries to learn, which are often half baked since the ecosystem
is so fragmented. Everything is a special snowflake with its own
idiosyncrasies and way of doing things.

~~~
albertgoeswoof
Most of those idiosyncrasies and libraries are really simple and not that
deep. Read the source code of your dependencies and it will make a lot more
sense.

------
commandlinefan
Five things I will learn just in time for them to become obsolete.

------
DanielBMarkham
This is a good list. Also web development has went down some insane rathole
that it needs to eventually get out of.

Let's look at it.

Typescript: Javascript, only with strong typing from OO you love

React: Use Javascript as if it were OO with IOC

Vue: Finally the web component architecture that the web itself is coming up
with in another few years, only here today

CSS Grid: Miss tables yet?

GraphQL: Install your own generic data layer, because you need a generic data
layer, right?

Don't get me wrong. These are all great techs. I use them daily and plan on
learning more about them over the coming year. But I can't get past the
feeling that web development is simply suffering from too many dang
developers. Come back in 10-20 years and we'll end up having another C++
that's more of a CF than C++ is. I sure hope it doesn't turn out like that.
Right now we've got a thousand ever-changing solutions looking for a problem.

~~~
aphextron
>CSS Grid: Miss tables yet?

It literally makes me feel like I'm cheating or something. What used to be an
hour of fiddling around with floats and percentages is now two seconds of
declaring a grid layout. Thank god for the evergreen browser revolution.

~~~
DanielBMarkham
Happy path on all of this tech rocks. It's quite impressive.

~~~
marcosdumay
Besides Internet Explorer, what failure mode does CSS grid have?

------
randomsearch
I’m fairly new to web dev and using Vue.

Web dev is a complete mess, it’s true.

I also think the direction of travel is good from what I’ve seen, we’re making
progress in improving it. For example, introducing types, getting away from
hacks like bootstrap etc.

What I do find infuriating is that it seems most of the problems are not new
and already well solved. Ultimately it looks like web dev is going to be quite
similar to Android/iOS/Java Applet dev, which themselves are not particularly
innovative (XML layout, MVC-variant style). Package management has been done a
gazillion times but we have yet another tool, etc.

Anyone understand exactly how we got here?

I’d also be interested if more experienced people have a good idea what the
endgame is, where this is all headed.

~~~
GordonS
> hacks like bootstrap

Do you mean Twitter Bootstrap, the CSS framework? I've never considered it a
'hack'?

~~~
randomsearch
Well, I think it's a hack in that it's kinda providing functionality you need
that isn't baked in, by making some opinionated decisions and then encoding
them in fragments of class names (as one example). That feels like a (good)
hack to me.

------
sambroner
Are people still using the responsive design? I feel like people stopped
addressing that issue with new technologies?

~~~
dolguldur
Of course they are. It’s just not a buzzword anymore but considered normal.

------
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.

------
hanoz
2019 may or may not be the year, but I'm sure it's coming - this inexplicably
expansive land grab of web application functionality by client-side
technologies is going to peak, and things will start to swing back towards the
server side.

~~~
buchanaf
Very unlikely. You'll see more of a merger where client-side solutions are
leveraged in very specific ways to address web requirements -- similar to
next.js and gatsby.js.

~~~
cantthinkofone
This seems plausible. There's usually a proliferation then a consolidation
phase with any period of innovation, where people invent all sorts of ways of
doing things and then gradually figure out what works best together.

Why the client-side has seen such an era of fecundity in recent years is
beyond me. Perhaps because there was a real problem with leaving the job to
jquery. Regardless, eventually there's just going to be too many available
solutions but not enough solidified and proven methods where everything you
need has been packaged together neatly because trial and error and years of
iteration have pulled the optimal toolchains together and left the others by
the wayside.

The way everything client oriented is just sort of floating around with no
real scheme to it creates a lot of possibilities but at the same time much
confusion and exhaustion. Eventually, (hopefully) there will come the
standards.

------
ww520
Instead of techs to learn, how about resolute to build small front end apps,
and along the way, learn to use whatever techs to make them happened.

BTW, GraphQL is more of a backend thing. The frontend part is simple.

------
vertline3
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?

~~~
digitalzombie
> 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 rendering.

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

------
danr4
My top one is ReasonML.

~~~
cageface
I would love to see ReasonML take off too but I think it's unlikely.
Typescript is pretty good and an easier conceptual leap for most developers. I
think it takes a company the size of Apple forcing a language on its
developers to bring an ML into the mainstream. And although I consider Swift
to be a kind of ML it's made a lot of concessions to more familiar language
designs.

------
leowoo91
Fullstack dev here, I'm still happy with jquery.

~~~
randomsearch
I think one problem with jquery is that it tightly couples your classes and
IDs, and your layout, which your logic.

Simple example: your new dev changes layout or an ID or classname, and some
code somewhere that relied on it via jquery breaks.

~~~
yakshaving_jgt
Yeah. Solve that with tests or a compiler.

Not using jQuery doesn’t suddenly make that problem go away.

------
igotsideas
Out of curiosity, are most companies/devs disregarding angular or is it slowly
picking up?

~~~
jcroll
It should be mentioned on this list but because Angular has positioned itself
as the enterprise solution to web frontend it scares away novices. Great
solution tho, I work with it fulltime

~~~
mcescalante
I'll second this. It's not very friendly to beginners, and many people dislike
"batteries included" frameworks, which Angular tends to be more than React or
Vue does. I use it at work in an Enterprise setting and it's worked well for
us thus far and have seen great improvements between Angular 2 and 7 (latest
as of writing).

------
azundo
Interesting that Graphql makes the list - any frontend devs without
considerable backend experience out there that have adopted it? Would be
interested in your perspective on it vs rest or rpc.

~~~
doubletgl
Played around with it. I do see the appeal and advantage if you need to save
requests and fetch lots of nested data. Haven't had an actual use case yet (as
in paid work). My fear would be that companies who'd be better off with rest
(because their data and entities are relatively flat and simple) adopt it
anyway. But that's my fear about a lot of libraries :D

------
Dowwie
This article makes it sound like the grid layouts of the CSS Frameworks have a
legitimate reason for updating. Is this a matter of swapping out grids?

~~~
soneca
Used by them. It is a new property added to CSS language

Edit: well, parent was a question that is now edited

~~~
Dowwie
sorry about that..

------
more-entropy
Does anyone have something for backend or even better system wide? What
correlates with that "3 mos" concept.

------
k_bx
Elm

~~~
mrdoops
Elm will be amazing when it doesn't have to compile to Javascript.

~~~
k_bx
Even Javascript has to compile to Javascript. Elm's TodoMVC, after
compilation, takes less JS code than the React version. What else is needed?
:)

------
gammateam
I need a site that tells me that something as simple as

npm install

would really be

sudo CXX=clang++ npm install --unsafe-perm

with some explanation of what really went wrong alongside the disclaimer about
the negatives of using anything unsafe-perm

every framework or language has developer tool nuances like that which waste
devs hours.

------
gammateam
Vue, Angular function similarly with prefixed/namespaced directives and
insertion techniques

v-if

ng-if

This is more of a matter of untechnical recruiters, resume crawling bots, and
technical interviewers understanding that these are the same skill sets and
concepts to make the labor market slightly more efficient.

All the company's devs are going to be using the resource manual and
stackoverflow either way, and most of their time will be messing around with
the dev tools than figuring out the most academically efficient solution
within the allotted time.

