Front End Development Topics to Learn in 2019(zendev.com)
zendev.com
Front End Development Topics to Learn in 2019
https://zendev.com/2019/01/15/frontend-development-topics-to-learn-in-2019.html
142 comments
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
Edit: and for the record, xcode is a 13.8GB install
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.
> 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.
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... but I guess I (or someone else) can do better.
+ 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.
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.
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.
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.
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.
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...
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...
> many NPM packages do include unnecessary files in the published artifacts
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.
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.
>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...
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.
> 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.
Not to take anything away from your post, but you're comparing a complete IDE & Simulator with dependencies for building a website.
visual studio code and browser are about 50 mb each. That brings a complete web dev setup to maybe 300-400 mb. Oh and I can build desktop apps and mobile apps too with web tools, still never coming close to 10+gb.
Yeah, it is completely missing me how web application dependency libraries relate in any way to an IDE for building applications. I don't get this argument and it doesn't seem to me like it makes sense. Perhaps I'm wrong and there's a connection I'm not seeing. Can anyone clarify this?
The point is that build tools take up disk space, and need to be installed. IDEs like XCode and Visual Studio bring along large quantities of libraries, headers, and other aspects of a C++ / C# / Swift / $LANG build toolchain.
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.
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 lion's share of my node_modules are related to my development environment -- Webpack, Typescript, Babel, SASS, Jest, etc. A very small portion actually gets bundled into the dist.
Wait a second.
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.
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.
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.
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.
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’re doing either.
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.
ASP.NET has changed to stay modern. Microsoft didn't just get a hair up their ass and decide to reinvent the wheel. If anything the TWO major changes in the last TWO decades (forms to MVC and MVC to Core MVC) have been reactions to popular development trends of their day and changes in computing environments.
Meanwhile front-end has been changing continuously without adding much benefit.
Meanwhile front-end has been changing continuously without adding much benefit.
So current front-end is bad, but old .NET was worse?
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.
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 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.
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.
> 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.
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.
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.
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.
It's possible you are not aware of that and just wanted to let you know.
I appreciate the way you relayed this. My intention wasn't to troll or beat a dead horse.
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.
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.
Honestly I think it's just a meme at this point. Don't fight it. Just mention something about Electron being bloated and rake in that sweet sweet karma.
Hey, has anyone else noticed how bloated Electron is? I bet it's all those rootin tootin NPM packages!
Hey, has anyone else noticed how bloated Electron is? I bet it's all those rootin tootin NPM packages!
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..
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..
Ha! Good points. Glad to see Typescript on this list, it's JS for adults.
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.
This is exactly my gripe with it all. There's always 10 different solutions to the same problem, often in 10 different packages.
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.
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.
Hence I prefer opinionated, convention over configuration solutions. It exists in Javascript world also. It called Ember.js. ;)
why?
I mean it takes far less than 15 minutes to install a module, so why should I implement it myself?
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 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.
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.
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.
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.
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.
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.
> 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.
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.
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?
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?
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.
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.
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.
Thats the issue with frontend.
Like left-pad?
By adding more 3rd party dependencies (and theirs) you're increasing risk.
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 written in a language like e.g. Python with Django framework, where theres generally one or only a few accepted best implementations.
It means there's less leaks through the cracks because everything is better integrated instead of loosely tied together.
It means there's less leaks through the cracks because everything is better integrated instead of loosely tied together.
Not if it's something that takes 15 minutes to implement :)
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"?
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'm primarily a back-end dev but do some front end work which is mostly React. I didn't like it much and thought there should be something better. Learned Vue on my own time, which was only a few hours. Did a super simple side project to work around some common gotchas. So glad I did, now use Vue for all new work and encourage people at work on greenfield projects. Now, I'm playing around with alternate state management, vue-stash looks good so far, haven't run into any issues with it but it's early on.
> 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.
> 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.
What did you dislike about React? What does Vue do better?
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 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.
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.
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 and let us know how much it helps you.
https://redux-starter-kit.js.org
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.
https://redux-starter-kit.js.org
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 <template>, 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.
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.
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.
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.
We can't even integration test all our team's portion of the system on one machine with kafka and datastores mocked out. Production is up in the thousands; I added about a dozen for the weekend just for a backfill.
> 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.
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.
Yep, sometimes the front end is more complicated - it depends on the application. Generally speaking though, the hardest problems in the backend are much harder than the hardest problems in the front-end. Like, I'm sure the PhD's Google are hiring are not working on front-end stuff.
[deleted]
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.
Actually, Java / JEE / Spring is the analogy I use when talking to people about the massive of complexity that is being created in the JavaScript ecosystem at the moment.
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.
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.
Had a colleague try and show me, a non Java guy, modern Java + maven + archetypes... It did a lot of downloading, a lot of building and then built something which, when we ran it, hung. I still have no idea what the demo was supposed to show me.
Going to continue working with Go
Going to continue working with Go
.NET has some warts but it's pretty plug and play. Exception are xamarin, which I give them a pass for because most cross platform technologies are a little rough getting started, and office 365 add-ons.
I don't have any direct experience but I also assuming sharepoint is awful.
I don't have any direct experience but I also assuming sharepoint is awful.
I use ASP.NET Core MVC, and it's wonderful. ASP.NET has really matured well, and it's honestly a joy to use.
npm hell, I assume it's still a thing?
Oh, yeah, it is. I used to love npm and then didn’t use it for several years. I’ve gone back to it lately and find myself screaming “what have you people done?!” on a regular basis now.
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.
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.
There's only two primary package managers for Javascript that are in common use. (For point of comparison, Java and Python are in a similar situation: Maven and Gradle, pip / pipenv / poetry / pip-tools, etc.)
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...
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...
There is a third alternative with a clear advantage over these two. PNPM is an NPM client that installs versioned packages into a central location and uses file system links within the 'node_modules' folder of individual projects. For a typical developer with many local projects this is a huge disk space saver. It also uses the original and much clearer nested structure of node_modules. I don't know why NPM didn't adopt the shared package approach, or why yarn didn't either, but PNPM gets it right.
I did list that one in my comment :)
Thanks for the write up! I used yarn when NPM was very slow, but I ran into some issues when I would use yarn, then later use npm or vice versa. I eventually went back to NPM and have been happy with the results. But I don't mix the two at all. So that is a question going forward - will mixing npm and yarn in the same installation result in problems and will the result be exactly the same? If not, it would be helpful to understand how the results differ.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
That's the point exactly, when you're building a public facing website, depending on your client audience it's very likely that you're not building only for modern browsers. Heck, the same holds for a large part of non-public projects as well.
Progressive Enhancement takes care of an acceptable fallback for browsers that don't support the standard.
In that case, that’s what is called “graceful degradation”, progressive enhancement goes the other way around (code for older browsers, then provide cool features for newer browsers). Like desktop first vs mobile first.
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.
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.
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.
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?
Unless you want to create your own styles for components like buttons from scratch, yes, you will still need a CSS framework. There are a plethora of such frameworks available today, many of which are lighter than Bootstrap (and don't require JQuery).
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.
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.
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
By not having to set up every single example anew, I hope this saves people some time in allowing them to learn things quicker.
By not having to set up every single example anew, I hope this saves people some time in allowing them to learn things quicker.
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!
Has anyone realized the wheels on the treadmill are spinning toward the carrot? Shouldn't be tough to keep up.
ah.. perhaps the aim is for the developer to escape the carrot.
edit: you have much to learn young grasshopper
Yeah, first thing I noticed. Then I was thinking, "How hard would that be?" to run backwards on a treadmill at any speed.
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...
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...
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?
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?
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.
Thanks, I’ll look into TypeScript more.
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.
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.
- 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.
Thanks, I’m leaning towards React and Vue
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.
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.
Five things I will learn just in time for them to become obsolete.
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.
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.
>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.
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.
Happy path on all of this tech rocks. It's quite impressive.
Besides Internet Explorer, what failure mode does CSS grid have?
>Right now we've got a thousand ever-changing solutions looking for a problem.
Wow you're right. And a lot of devs can't resist that temptation.
Wow you're right. And a lot of devs can't resist that temptation.
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.
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.
> hacks like bootstrap
Do you mean Twitter Bootstrap, the CSS framework? I've never considered it a 'hack'?
Do you mean Twitter Bootstrap, the CSS framework? I've never considered it a 'hack'?
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.
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.
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.
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.
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.
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.
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.
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.
BTW, GraphQL is more of a backend thing. The frontend part is simple.
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 rendering.
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.
This peacing out is sort of exactly what I've been considering. Focusing more on algorithms or big picture things. Thanks for your perspective.
My top one is ReasonML.
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.
Fullstack dev here, I'm still happy with jquery.
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.
Simple example: your new dev changes layout or an ID or classname, and some code somewhere that relied on it via jquery breaks.
Yeah. Solve that with tests or a compiler.
Not using jQuery doesn’t suddenly make that problem go away.
Not using jQuery doesn’t suddenly make that problem go away.
Out of curiosity, are most companies/devs disregarding angular or is it slowly picking up?
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
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).
>slowly picking up?
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.
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.
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.
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
Does anyone have something for backend or even better system wide? What correlates with that "3 mos" concept.
Elm
> where I can either get paid to take it or there’s a clear market for the skill
Maybe not Elm then
Maybe not Elm then
Maybe in another year.
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.
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.
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.
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.
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.