This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.
The Why I don't use web components article certainly sparked a lot of passionate discussion and replies. At the top of the thread was this (respectful) rebuttal from @equinusocio:
I'm sorry, but no, most of the points you defined are extracted from a bad usage of the technology. Then:
1 is not true.
You can progressive enhance web components even with js disabled.
googlechromelabs.github.io/howto-c...
2 is not true.
You don't have to put all the style inside the shadow dom, only the style that should not be composable or accessibile. Just like private ts functions.
You have a lot of flexibility then. I suggest to check this and define the context of your web component.
css-tricks.com/making-web-componen...
Another thing, host elements are exposed and fully customizable by external css and you should work on this. Again only the private and functional/structural css should be inside the shadow tree.
codepen.io/equinusocio/pen/vMOqBO
CSS-in-JS is not a problem while you write real CSS and generate it inside a css file or embedd it inside a <style> tag. The problem of the first css-in-js tools was the fact that you had to write pseudo css json-like and put it inline. Now, any modern css-in-js solution allows you write standard css and put it inside a separated file.
3 and 4 was true until 2018
Right now all the modern browsers fully support the v1 spec. This mean all the webkit and chromium based browsers (including edge). No polyfill needed for modern development, and if you have to support old browsers you're probably already using polyfill for js things so what's the problem? You just choosed a new technology to develop for old browsers.
5 is normal and it make totally sense.
Slotted elements don't live inside the shadow-tree where you put the <slot> tag, they live in the light-dom, and as any html element in light dom (for example inside the document) they are rendered immediately. Web components are custom html element, if you want to add a lazy behaviour, you have to implement it for your component, like as you do it right now with any lazyload js library.
6 This is true for the whole HTML
These issues are related to HTML and you have them with any framework if you work with plain attributes and not on top of abstractions.
Web components are not React, Vue or Svelte components, they are not logical containers, they are true html elements that live in the document and they should be used like any other html element. Taking a web component and comparing it to an abstracted svelte component is totally misleading. They do different things.
I like sveltejs and i think it's a good framework on top of good abstraction, you don't need to write falsy things about other technologies.
I'm not here to tell web components are the solution or that they are better than other tools. But i don't like content that compare two different things and claim that one is totally bad compared to the other.
Cheers!
Replying to the news that Some US prisons are banning books on coding @joelnet talks about the very dark motivations in the prison system:
This is intentional. The for-profit prison system is designed to catch you and keep you.
Got a felony? What job can you hold now? Shit job. You are more likely to need to steal or deal just to survive. Of course you'll be back to prison.
3 strikes and you are a permanent resident. Now you are profit.
Even if you want to be better. The odds are so stacked against you.
We need prison reform. for-profit need to go.
How important are math skills for software development? @rpalo offers some insight:
I would say, they never hurt and they can provide valuable insights into problems that you might otherwise miss out on. But how necessary they are probably depends on what you are doing.
For web work, you can get away with less, because you are more focused on design, UX, networking, performance, event loops and data wrangling, which are all hard in different ways themselves, but are less directly tied to math.
For more algorithmic work, solving a more complex problem using graph theory, search algorithms, trees, etc., it is more important. It can help with the basic understanding of the methods you are applying and which algorithms may work best in a given scenario.
For data science, it’s not strictly necessary, but it really helps accelerate your learning if you can grasp and build on the mathematical and statistical concepts and not just memorize what libraries to use and what methods to call. It also helps you evaluate your results rather than blindly accepting them because the “algorithm” says so. This is getting more and more ethically important as more and more decisions are being made with heavy AI and machine learning and big data driven insights.
For lower level systems programming, at least a little number theory (binary, hex, and decimal representations of things and how to mentally convert back and forth) is critical. Luckily, while number theory is intimidating, it’s not super duper complicated at the end of the day if you approach learning it slowly and with the right examples. I’ve got a couple articles about that.
Lastly, if the domain you are in is math heavy, like software for physics, engineering, chemistry, biology, genetics, statistics, probability, etc., then you’ll probably want to have a bit of a grasp on that particular domain.
That’s all I can think of. My philosophy is that math always helps make you a better developer, but treat it like anything else we have to learn. Learn it as you need it or as your interest strikes, and don’t feel like an imposter if you don’t know everything right now. Just put it on your list to learn and watch some numberphile videos on YouTube in your downtime. 😁
This is a relatable feeling and question. What do you do if you're in the middle of a project and you realize it already exists in the world? @nektro shares some wisdom about the value of different perspectives coming at a similar project:
A fair amount of the things I've made, I started because it already existed and I wanted to have my take on it. Everyone has a unique perspective, and new approaches to old tasks can revolutionize them forever. Stay strong 💗
@jaakidup talks about the impact of frequent changes to frameworks in VueJS is dead, long live VueJS!:
It feels to me like all the front-end frameworks are constantly trying to scratch an itch that "maybe/probably doesn't exist".
It's all good that everyone is striving to make things better, but these types of changes don't only affect the projects you are still going to do, but also those you've already done. Then a few months later there will be another change, further removing various Vue (or any other FE framework) projects from one another.
In that respect I don't like that the whole development community is the guinea pig for framework development. ie. just as you figure out how a pencil works, someone goes and changes it :)
I guess I want the option to use the current or the next version whenever I want, to infinity. To much to ask?
See you next week for more great comments ✌
Top comments (2)
Congrats to @equinusocio , @joelnet , @rpalo , @nektro , and @jaakidup for making the list this week!
I love these recaps! They always lead me to interesting content 😊.