{"id":18694372,"url":"https://github.com/csev/wc-experiment","last_synced_at":"2025-11-08T11:30:46.177Z","repository":{"id":54271767,"uuid":"340694447","full_name":"csev/wc-experiment","owner":"csev","description":"Chuck's Web Components Experiment","archived":false,"fork":false,"pushed_at":"2021-03-14T17:48:26.000Z","size":399,"stargazers_count":4,"open_issues_count":1,"forks_count":1,"subscribers_count":4,"default_branch":"main","last_synced_at":"2024-12-28T03:14:27.113Z","etag":null,"topics":["components","web"],"latest_commit_sha":null,"homepage":"https://www.dr-chuck.com/wc-experiment/","language":"HTML","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/csev.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2021-02-20T16:03:34.000Z","updated_at":"2024-06-25T08:34:56.000Z","dependencies_parsed_at":"2022-08-13T10:40:15.984Z","dependency_job_id":null,"html_url":"https://github.com/csev/wc-experiment","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/csev%2Fwc-experiment","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/csev%2Fwc-experiment/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/csev%2Fwc-experiment/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/csev%2Fwc-experiment/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/csev","download_url":"https://codeload.github.com/csev/wc-experiment/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":239552450,"owners_count":19657914,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["components","web"],"created_at":"2024-11-07T11:10:31.886Z","updated_at":"2025-11-08T11:30:46.145Z","avatar_url":"https://github.com/csev.png","language":"HTML","funding_links":[],"categories":[],"sub_categories":[],"readme":"Dr. Chuck's Web Components Experiment\n=====================================\n\nThis is a place where I will develop code to figure out how I want to use\nweb components in my own development.\nI see the future of web applications as increasingly web components based.\nI see web components and JSON APIs as a great coding pattern regardless of your\nfront-end approach and back-end approach.\n\nIf web components are truly ready\nfor the \"big time\" they should work in static HTML and you should be able\nto view source and understand what is going on.\n\nYou can see my playground at https://www.dr-chuck.com/wc-experiment/\n\nIt is simple, static, and crude.  I will add more sample code over time as I learn more\nabout the way *I* want to use web components.\nI don't want to adopt a framework - I want to use browser functionality as it comes from the browser.\nIn a way all I see all of the front end and back end frameworks as doing research in how web components\nneed to function and informed the design and development of web component\nimplentation in modern browsers.  So that is a good thing.\n\nBut I do not want to develop code to any framework.   I want to develop a pattern that can work with\nPHP, JQuery, and Bootstrap 3 or Java and Velocity.   I support far too much code that cannot afford\nto rewrite itelf completely every time a framework development team sneezes.\n\nHow I want to go about this\n---------------------------\n\n* I want it all in the markup\n\n* It is OK to download a static asset from a CDN - like a polyfill for older browsers - this needs\nto be pretty static - if it did not change for a year things won't break\n\n* I am OK with extending *one* thing like LitElement or HTMLElement - as long as that code is\nso old and boring that it is in maintenance mode and will only issue new releases if something\nin browsers breaks it.  (kind of like JQuery).\n\n* I could tolerate a simple templating library that is old and rusty and not\nchanging much anymore like Handlbars.   Cool, hip, recent and getting better rapidly are\nall negative aspects of any framework\n\nJQuery is mature enough for me - but I want to move to vanilla JavaScript because JQuery did its job\nand shamed vanilla JavaScript into fixing itself.  #ThanksJQuery\n\nNo Thanks\n---------\n\nMany interested in web components are advocates of one or more \"crutch\" technologies that to me\nare fine ways to \"prototype\" web applications but not a good way to build a web application that\nneeds to last 5-10 years without major rewrite.  If you are a VC-funded startup - you are trashing and\nrewriting your code constantly - I can't afford to waste that kind of money on my software.  So I avoid\nquick \"feel-good\" solutions.\n\n* Please don't suggest that I use React or any other client side framework. Backbone and Angular 1\nare probably mature enough for me - but that only makes my point.\n\n* Please don't suggest that I use Polymer, Node, or any other slick way to \"manufacture\" web components.\nIf we are still at the point where it is *impossible* to do web components without these\n\"helper\" technolgoes - I will wait.\n\n* No npm, bower, or other component manager - eventually I might be willing to so some kind of\nserver side packaging / path patching to make a large number of web components easier to maintain\nand more efficient to download.  But for my experiments, I want to see simple solutions that\nyou see and fully understand when you \"view source\" in a browser.\n\n* Please don't suggest I use your webcomponent library like PatternFly. Patternfly 3 was\nmarkup or React based based - PatternFly 4 is React based - because they got lazy.  I don't\nwant to depend on a framework builder remaining aligned with my philosophy over time.\nI don't want a framework I adopt to force me to do a complete rewrite on their schedule.\n\n* Please don't suggest I use a CSS library like Material Design - the approach should\nwork with any markup themeing.   It won't surprise you that I like Bootstrap 3 and think\nBootstrap 4 is a complete waste of time.\n\n* Please don't suggest I rewrite everything in Ruby on Rails and use HAML.  I am\nsimilarly disinclined to use Scala or Rust.  The server side should not matter.\nUsing an \"all-the-rage-at-the-palo-alto-coffee-shops\" technology is a negative\nin my book.\n\n* Don't mention GraphQL or Apollo - the markup should be data store agnostic.  These appeal to me\nbut no one can tell me how they make subscriptions / notifications scale with the back-end is a\nrelational database.  Just saying \"magic\" is not a sufficient technical description for me.\n\n* Even though I like PHP - don't tell me to use Laravel and Blade - they are impressive on paper but they\nneed write access to the htdocs folder to work because they compile their templates for performance.\nGiving the Apache process write access to the htdocs folder - what could go wrong?\n\n* I am not interested in the *amazing* web components you already have. I am sure you have the worlds\nmost impressive button.\nI already have buttons.  I use the button tag and Bootstrap 3 to style them.\nI don't need to run Doom on my buttons.\nI want to make my higher-order own extendible web components with a focus on those adopting my approach\nto be able to extend my web components to add their own flavor.  I am guessing that your\ncomponent library is a bunch of brittle spaghetti code\nthat you update furiously and in non-upwards compatible ways every time a new browser is released.\n\nIf it is not possible to build web components without resorting to these approaches - I will just\nkeep waiting.  But I am actually quite confident that web components are mature enough for\nme to adopt and use in long-lived applications.\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcsev%2Fwc-experiment","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcsev%2Fwc-experiment","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcsev%2Fwc-experiment/lists"}