Front End Development Topics to Learn in 2019

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

I can't really understand the sentiment that front-end dev is absurd. I started with .NET years ago and find _anything_ that becomes 'standard' in the front-end more approachable than the constant reinventing of the wheel / new framework releases MS did circa 2004 - 2014.

It was something like:

- Learn ASP, opps we meant ASP.NET web forms. Actually, we meant .NET MVC.

- Oh no, the world wants APIs ... please learn WCF. Actually, we meant .NET Web API.

It seems things have finally calmed down with .NET core. But, along with the MS frameworks you also need to have good command over C# and data access / manipulation utilities such as LINQ, Entity Framework, etc. If you happen to be working with MSSQL Server as I was -- you had to learn it and all of its quirks.

I will say the tooling, once learned, was pretty good everywhere (except WCF in terms of configuration). I can't say that for a lot of front-end utilities, which I think results in a lot of configuration pain and StackOverflow searches.

I do find the answers / guidance on configuring front-end much higher quality than most things in the MS ecosystem, though.

____

My intent here isn't to bash MS so much as it is to point out that the breadth of things you actually have to learn for front-end development is less than some other ecosystems. We're a part of a privileged profession where income and demand is high, so I do expect re-skilling to be an ongoing process.

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 understand your frustration. One thing I'd like to mention is that a comment similar to your comment is frequently mentioned in any HN post about typical frontend/JavaScript topics. So frequently, that I'm not sure what it adds to the discussion at this point.

It's possible you are not aware of that and just wanted to let you know.

I think currently front end development becomes a bit messy.

One could compare it to a wild west.

And most likely its caused by misusage of javascript. Typescript is now just a "lets learn less competent ppl how to write frontend", technologies change too fast and have too many holes. Young folks want to be recognized and jump from one bandwagon to another..

This whole mess could use some refined standarization enforced by browsers (like apple store process)

Ps. Sorry for bringing so many topics here but situation is that bad and i didnt even mention security..

It's frustrating how the go to solution for a problem tends to be to install another module. I agree it's not smart to keep reinventing the wheel, but when the solution takes less than 15 minutes to implement the recommended answer shouldn't be another module.

Why would someone need to preemptively learn both React and Vue? I can get saying you want to understand how they accomplish their respective roles, but is there an actual (non-crazy) scenario where your core, day-to-day job depends on really knowing both?

Or is that the whole point? Am I erroneously assuming "learn" means really deep knowledge(which for me really digging into any single one of these would be enough) when it means "known enough to pass a job interview when I ladder-up to the next company"?

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.

I think it's weird to compare server application development to client development which is an entirely different beast.

Client development on any platform is more complicated than the server stack. Back-end API devs have a much simpler job for most apps too. We as back-end devs like to pretend otherwise even though our app runs on just one machine.

What's a language/domain/framework that's _not_ like this? After spending a few weeks struggling with Bazel and Spring you'll not convince me Java is any better.

npm hell, I assume it's still a thing?

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.

It’s pretty sensationalist but I don’t disagree with the content of the message: by sticking with a float or flexbox-based grid system from a framework, you’re not learning the intricacies of newer tech like grid.

That being said, for most of my professional and personal work I only see grid as an incremental improvement over flex. It’s cool but time I spent learning it I could have just used what I already knew and create more things the customer actually cares about.

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.

If I switch to Grid for layout, don’t I still need Bootstrap for other things, eg toolbars, buttons....? Or is there a more lightweight choice for those?

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!

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

Yeah, first thing I noticed. Then I was thinking, "How hard would that be?" to run backwards on a treadmill at any speed.

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.

Vue is simple and progressive - ie you can use it when you want to and use plain JS etc when you don’t.

If you like “pythonic” simplicity, use Vue.

The answer can be a bit different depending on what you already know, but here is a list of a few things things I work with:

- Rails or Express for the backend (depending on needs, I'll usually chose Rails over Express 90% of the time).

- Vanilla JS if you only need a few simple things

- Vuejs if you need a bit more complex client-side logic, but still easy setup (Vue can be installed from a <script> tag)

- React if you need more complex UI, but it will make your client bundles more complex (while importing Vue as a script tag is ok in prod per their doc, React's docs recommend against that).

Another thing, if you already know React and you want something quick if Next.js. It's still a full React framework, so it comes with a pretty "complete" bundle that you might want to avoid, but is really plug and play and requires 0 config. You'll be able to very (very, very) quickly start building pages, etc. with server-side rendering and it works very well (I'm using it on a fairly sizeable project for a client and I'm happy with it so far). And in the case where you want to end up with just a static package that you can host on a CDN, there is an option for that. You loose server-side rendering, but that allows you to serve you website as a static website.

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.

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