You said "The modern approach appears to be to spend years patching every hole with JS without thinking about how that might make its way into standards and into browsers" which seemed to imply you had some problem with it. I'm just wondering what other way even exists.
-
-
Replying to @AdamRackis @justinfagnani and
There is, but not "better than JS" per se. The modifiers are critical. "Years" and "without thinking about how that might make its way into browsers." Think of maintaining a CSS in JS library for years without having even a strawman pitch for a new CSS feature or a DOM API.
1 reply 0 retweets 9 likes -
Replying to @morewry @AdamRackis and
(Unless the DOM API results in effectively eliminating CSS or the strawman pitch is to JS to standardize embedding CSS in JS.)
1 reply 0 retweets 2 likes -
Replying to @morewry @AdamRackis and
@morewry is getting at a critical principle for how our teams design libraries: We have to empathize with the platform, specs, and standards bodies, then attempt to predict the future in which the library isn't necessary anymore and design the library to be compatible with *that*1 reply 4 retweets 23 likes -
Replying to @justinfagnani @morewry and
It's very hard and very imperfect, but still leads to better long-term outcomes. It's also important to engage standards and make proposals early so we don't languish in userland-only solutions for far too long.
2 replies 0 retweets 15 likes -
Replying to @justinfagnani @morewry and
Node really should have done this with CommonJS, and I particularly wish more Webpack loaders were written with this in mind. Some of the CSS loaders for instance do things that a spec would never do, making them a barrier to modernizing the platform, rather than helping.
4 replies 0 retweets 25 likes -
Replying to @justinfagnani @morewry and
Node sure. but I feel completely at a lose as an avg dev making libraries to help build products, on how to find the _years_ needed to shephard some idea through a web standards body. No lib starts off being heavily used, the investment up front seems infeasible
1 reply 0 retweets 5 likes -
Replying to @monasticpanic @justinfagnani and
Sounds very true to me. What I'm advocating is practicing platform thinking for the benefits it has for you and your projects. Participating in standards and successfully standardizing a specification is a whole 'nother mountain to climb. I've never done it and I'm afraid of it.
2 replies 0 retweets 6 likes -
Replying to @morewry @monasticpanic and
You're both right. It takes a lot of time and energy, but you shouldn't be afraid of it. The groups I've participated in have been very open to both newcomers and users, especially users. It's also quite easy to propose ideas to most groups via GitHub issues these days.
1 reply 0 retweets 4 likes -
Replying to @justinfagnani @monasticpanic and
True! I got the impression is that the migration of some W3C stuff to GitHub was an intentional step to make that easier and more accessible--an attempt to meet the web development community where they are.
1 reply 0 retweets 3 likes
Yep. Very intentional for exactly those reasons.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.