This is it. This is what writing javascript is like in 2020. It& #39;s not framework fatigue. It& #39;s none of the parts fitting together anymore, and all the defaults being ones to support legacy systems.
http://lea.verou.me/2020/05/todays-javascript-from-an-outsiders-perspective/">https://lea.verou.me/2020/05/t...
http://lea.verou.me/2020/05/todays-javascript-from-an-outsiders-perspective/">https://lea.verou.me/2020/05/t...
And all the blog posts you can find are from developers building what will eventually, hopefully, become the status quo but right now is terribly broken or wide-eyed code-school grads trying desperately to write relevant content to seem competent enough to get a job.
In either case none of it reflects the industrial reality that everything is terribly, terribly broken.
I& #39;ll admit I& #39;m part of this problem. I& #39;d rather use the new stuff, the status quo I& #39;m hoping is coming, than deal with the legacy. At points I feel justified because the legacy is broken too, in its own ways.
I don& #39;t know how to fix it.
Honestly, I think part of the appeal of deno is that it& #39;s not compatible with node. It& #39;s _hard_ to port. Lots of tools are missing. It& #39;ll be a greenfield hell for a while.
Maybe that& #39;s what we need: make backward compatibility a shim, not default.
Honestly, I think part of the appeal of deno is that it& #39;s not compatible with node. It& #39;s _hard_ to port. Lots of tools are missing. It& #39;ll be a greenfield hell for a while.
Maybe that& #39;s what we need: make backward compatibility a shim, not default.
Maybe this will make it clear when something is not yet solved. The answer to "can I use X yet?" is actually no. It& #39;d be nice if it _looked_ like no when you investigated.