Front End Development Topics to Learn in 2019
zendev.com
zendev.com
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.
And while we’re on the subject of package managers; do we really need so many? I know npm is terrible but it seems like everyone has decided to create their own now. I swear to god I had to use a package manager to install a package manager the other day.
NPM is the package manager built by the NPM company. It's included with Node. Primary selling points: it's "official", and NPM has included the package auditing tech they purchased.
Yarn was created by a team from Facebook, at a time when NPM (v2/v3) was known for being slow. Currently developed by a somewhat broader group of contributors. Primary selling points: more consistent installation behavior, "offline mirror" installations.
Both tools install packages from the same servers run by the NPM company. The speeds are relatively similar these days, but that's at least partly because the competition pushed NPM to improve. And yes, Yarn is often installed via NPM, although you can install it other ways too.
Both teams are working on solutions to the `node_modules` size issue. NPM is building a new package manager called "Tink" from scratch. Yarn has come up with a technique dubbed "Plug 'n Play". Both look potentially interesting.
There's other package managers out there, but they're rarely used. For example, PNPM uses symlinks in each project to a global package cache, rather than installing a separate copy of a package for each project.
I happen to favor Yarn myself, largely because the offline mirror feature makes it easy to have consistent, fast installs in CI builds and across platforms [0].
[0] https://blog.isquaredsoftware.com/2017/07/practical-redux-pa...
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..
Going to continue working with Go
As you create it, new complexity looks "free" because the creator understands it perfectly (they are creating it!) and their nearest peers understand it too (they have the same immediate problem as the creator!). But it's a one way path - like navigating through a complex maze - going forward is easy and you come out the other size eventually, but nobody will ever be able to retrace those steps. In the longer term the complexity has an enormously high price, and eventually it collapses in on itself - new developers just won't use it.
Other ecosystems are complex but not at the same scale as those two IMHO, because different ecosystems seem to put a different price on complexity.
I don't have any direct experience but I also assuming sharepoint is awful.
I mean it takes far less than 15 minutes to install a module, so why should I implement it myself?
By adding more 3rd party dependencies (and theirs) you're increasing risk.
It means there's less leaks through the cracks because everything is better integrated instead of loosely tied together.
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 just to save a few minutes writing a simple function and maybe a test or two doesn’t scale very well. At best, it is replacing a superficial problem with a deep set of extra and ongoing responsibilities.
This is before we consider the time required to find and evaluate a suitable package, and even then, there is no guarantee that some random small NPM package from a source you’ve never heard of will be any better than what you’d have written yourself if you’re a halfway decent programmer.
Thats the issue with frontend.
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.
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.
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.
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?
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.
Typically, I've seen it come about because often package creators have no interest in maintaining their invention. Their PR list is huge, all the tickets are just questions about "why isn't my PR merged?". So someone else creates an alternate or a fork, but so does everyone else.
I don't think anyone _wants_ a thousand packages, but there's a disconnect or miscommunication that's holding us all back.
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.
I don't see how you could possibly say this in such general terms. Every app is so different. Even simple crud apps of any size are not running on "just one machine." Even most small backends have at least an API server and a job server, plus database(s) and queue(s) for communicating, plus DNS, TLS certs, etc.
Sometimes the front end is much more complicated, sometimes it's not. There's really no way to generally compare without being wrong 50% of the time.
Edit: and for the record, xcode is a 13.8GB install
Not to take anything away from your post, but you're comparing a complete IDE & Simulator with dependencies for building a website.
Front-end web dev now consists in large part of building highly interactive applications, not just static sites. That requires tooling. Therefore, it's not unreasonable to expect that the necessary tools will take up space, and there's plenty of prior precedent from other languages.
> 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.
This is the main reason node_modules grow so quickly. Many authors are careless on what files they include in their published packages.
The npm cli now makes the package files and size visible during publishing, but I guess we need some way to shame authors publishing big packages, maybe by including size info on the npm website and downranking them in searches.
+ 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... but I guess I (or someone else) can do better.
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.
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.
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...
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...
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.
You just made up a fictional scenario and used it as the evidence for your case.
It's possible you are not aware of that and just wanted to let you know.
Hey, has anyone else noticed how bloated Electron is? I bet it's all those rootin tootin NPM packages!
I think a lot of us are spending too much time troubleshooting dependency nightmares versus actually solving problems for our clients/employers.
The popularity of projects like Laravel Mix indicate that there may be a problem grokking all this stuff.
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"?
> Vue 3 is being written in TypeScript
This is such great news. Just did my first Vue2/ts app and it's so much nicer. Wasn't easy to find all the info, there should a good Vue2/ts tutorial somewhere.
I imagine it could be better with a different state management library or maybe ReactReason or TypeScript. The other thing I really like about Vue is how the layout and logic stay separated. With React and JSX there's always code all over the place: class methods, regular methods, lambdas, inline '&&' throughout the JSX. The way Vue handles events is far simpler.
I do however see the value in all of this with React when working on a large team. It all adds up to safety. I haven't yet worked on a Vue app that has grown complex enough to feel any of that necessary as where even a simple React app's structure is already complex.
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 and let us know how much it helps you.
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.
Meanwhile front-end has been changing continuously without adding much benefit.
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.
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 problems and still isn't as mature as other languages approaches, disk size explosion due to each individual application storing their own dependencies (and dependencies often storing different version of libraries in their dependencies).
You don't see nearly as many arguments with say, Bundler and the gem ecosystem in ruby.
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.
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.
> 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.
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.
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.
Then it's time for PostCSS, because now we use JS to write CSS.
I'm very familiar with Bootstrap though, so I'll personally continue to use it for a long time to come, unless there is a really compelling reason to use another framework.
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.
By not having to set up every single example anew, I hope this saves people some time in allowing them to learn things quicker.
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...
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?
- 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.
If you like “pythonic” simplicity, use Vue.
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.
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.
Wow you're right. And a lot of devs can't resist that temptation.
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.
Do you mean Twitter Bootstrap, the CSS framework? I've never considered it a 'hack'?
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.
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.
BTW, GraphQL is more of a backend thing. The frontend part is simple.
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.
Simple example: your new dev changes layout or an ID or classname, and some code somewhere that relied on it via jquery breaks.
Not using jQuery doesn’t suddenly make that problem go away.
You seem to assert Angular is growing from a position of weakness? It's a very popular framework. Very structured, and with the introduction of the new Ivy rendering engine, I think it will get a bump in popularity.
Edit: well, parent was a question that is now edited
Maybe not Elm then
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.
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.