33 ms·
Ways to make a web component
- alfonsodev 6y agoIt is very interesting that it includes the build size including compressed size, it makes me thing that one of the reasons that we don't have a popular repository of interchangable Webcomponents yet, is that if you commit to a framework to make things easier, then the size of the bundle is easier to justify if you keep all the components made within the same framework. Importing components that have been made with different framework come with their extra bunde overhead, at least that what looks to me at first glance.
- spankalee 6y agoThis is a fine state to be in now. The first priority of web components is to make components interoperable, so that at least you can use components built with different libraries together. Meanwhile, the size of modern rendering libraries has dropped significantly, an order-of-magnitude less than React/Angular. This will continue as JS and web platform APIs advance. Proposals like Template Instantiation would finally give the DOM a good pattern for fast updates and reduce sizes even further.
- slim 6y agounless you use HTMLElement
- nend 6y agoAlternate title: The fractured state of web UI design explained using a simple counter. I say that only slightly in jest, as it is a neat way to show all (or most) of your options. Although it doesn't have my at-the-moment favorite way to make web components, blazor/web assembly. For me, it's made front-end development fun again, which I haven't enjoyed in a long time.
- spankalee 6y agoThis isn't a collection of ways to "build components for the web" though, it's a set of ways to build "web components" the W3C component standard that ships natively in all modern browsers. Even those these components are built with different libraries, they are all interoperable and require no framework to use them, so I'd say this points to the defragmented future of web development.
- hn_throwaway_99 6y agoEdit: D'oh, I misread it, sorry. You misread this post. The left panel has all the different popular libraries and frameworks that can be used to build a web component, including things like React, Svelte, Vue, etc.
- spankalee 6y agoI actually helped contribute to this list. If you look at the React, Svelte, and Vue, examples, they are specifically being wrapped as standard web components.
- deleted 6y ago[deleted]
- ceo_tim_crook 6y agohttps://fsbolero.io https://fsbolero.io
- afarrell 6y ago> fractured Compared to the myriad ways for different cultures to make chicken with rice, this is nothing.
- deleted 6y ago[deleted]
- georges_gomes 6y agoHi nend, co-author of the blog post here. I had blazor/webassembly in mind for quite some time, we will try to have it in on the next update :thumbsup: IMHO Web Component is the opposite of fractured because whatever "helper" you use to make a Web Components, they sit on the same Custom Element standard. Somehow it's more convergence then having components in Vue and components in React that can't (without massive cost) be used together.
- kgwxd 6y agoI've been working on project with Blazor for a few months. I still find myself feeling a little dread when I need to start work on a new big component and then I remember, not only will it not be painful, it will be pleasantly supersizing how easy it was compared to the 5 other time I built something similar in various JS frameworks over the years. Only Clojure(Script) with Reagent gives me a similar good feeling, better actually, but I've never had a chance to use it at work. If Razor markup could somehow also be C# instead of HTML, like how Reagent markup is just Clojure, that would be neat, but I'm not sure that could be done in a pleasant way.
- bob1029 6y agoBlazor is fantastic. We've been using Blazor server-side for about 8 months now. The part that still hurts my brain is when I realize I am basically done with a new feature after I finish writing my business service. I can just inject & call it from the blazor component and directly draw whatever data without any mapping layer required. I may have forgotten how to write controllers and juggle headers/query strings... It's really nice. Remember, every hour you spend writing some controllers or debugging query strings/serialization/status codes/et.al. is an hour not spent on your core business features.
- CivBase 6y agoThis is neat, but I wish there were more examples than just a counter. I would never use something like Angular, React, or Vue to implement something so trivial.
- illumanaughty 6y agoThis distills the differences into the simplest possible example, which given the number of examples is incredibly useful. Also if you're in a React project, yes, you would use it for a counter. Obviously you wouldn't use React for just a counter, but it's a great way to show the basics of working with each option.
- M2Ys4U 6y ago>Obviously you wouldn't use React for just a counter You probably shouldn't, but there are a lot of people who reach for a React component to do anything on the web.
- spankalee 6y agoYeah, the example is far too simple to exercise the libraries and would be much better implemented without a library at all. But then, this is a great part about web components: you can implement a single component however you want, including with no dependencies, and still use it like you would have if you built it with a full-featured library. You can use it in Angular or React even.
- georges_gomes 6y agoYes, the counter is simple. One reason is obviously that writing something in 30+ different framework that you need to "learn" is quite some work :) (10x more that I initially thought :D) The other reason is that a simple component actually amplify the cost of the framework. And if you think about it, with a more complex component, what you have is more HTML, more CSS and more JS but they are essentially always the same. Only the binding are different from one framework to another. So in the end, the counter is actually a good representation of the cost related to the technology. This been said, to be correct, the benchmark component should use more capabilities like slots and events to really cover the wide range of capabilities. This is something we have in mind for a future update of the blog post...
- Blackthorn 6y agoI saw at least one that uses "style scoped", which I still can't believe is deprecated.
- srameshc 6y agoI love the simplicity of StencilJS. Not sure why it's adoption is so low but those guys have put a lot of work. Much better than what Google is doing with Lit Element.
- marvindanig 6y ago'cuz Facebook spent a bazillion dollars to push the developer community towards React? They are really good at––how should I say this––controlling the 'community direction and sentiments'. Even countries for that matter.
- dmitriid 6y agoYup. Unlike the poor desolate folks at Google who ... checks note ... dominate the narrative on Web Components. And are, for example, consistently adopting a general aggressive anti-framework, and a specific extremely aggressive anti-React stance.
- yesimahuman 6y agoThanks! I wouldn't say Stencil's option is low. It's being used in some pretty major apps today, like Apple Music, Amazon music, and powering the next version of AWS Amplify components. Not to mention powering every Ionic Framework component which is upwards of 15% of the app stores (not all use latest w/ WCs however). One downside to that is npm stats won't show dependency network effects with stencil because it is compiled out for component collections like framework.
- yesimahuman 6y agoWhoops, meant popularity, not option
- hitekker 6y agoCurious: how does Stencil compare to Lit Element?
- 6y ago
- asutekku 6y agoSuper cool, thanks for this! Now regarding the results: Are there any actual usecases where one would choose Angular over some other library? From what i’ve seen from before and now this, i am not aware of a single reason why would anyone choose to use it, if they are not constrained by legacy codebase or if there are no stubborn developers who swear by it.
- Kuinox 6y agoVue is great to make small webapp. Also wikipedia chose Vue to remake their UI IIRC. React is even simpler, but I really hate it for technical reasons.
- EGreg 6y agoWe are working to document Q.js out of our entire platform becauss it can be used to make much simpler to understand web components, which work seamlessly with SPA pages, events and more: https://qbix.com/platform/guide/tools https://qbix.com/platform/guide/tools https://github.com/Qbix/Platform https://github.com/Qbix/Platform
- yitianjian 6y ago1) These are benchmarks just using a counter - a lot of libraries perform really well using these minimal POCs but fail complete in real world applications (whether due to library performance, missing features, etc.) 2) This is sticking Angular inside a WebComponent with the minimal amount to make a counter - but you wouldn't take a heavy library to make a counter. Imagine React + Redux + Redux-Observables + StyledComponents just to make a counter. It's like hitting a nail with a ICBM.
- sillysaurusx 6y agoGPT-3 has an interesting contribution to this: https://twitter.com/sharifshameem/status/1284095222939451393?s=21 https://twitter.com/sharifshameem/status/1284095222939451393... Tell it what you want in plain English, then it builds you a web component in a random language that happens to be React. I wonder if in the future we’ll be comparing the size of components generated by an ML model...
- Bjartr 6y agoIt's not random, it would have been part of the prompt, like his earlier prototype https://twitter.com/sharifshameem/status/1282692481608331265?s=19 https://twitter.com/sharifshameem/status/1282692481608331265...
- deleted 6y ago[deleted]
- clairity 6y agois there any reason you can't write a web component with a <style> block, a <script> block, and a bunch of html? the wedging everything into js is messy, to say the least. it seems the main benefit is being reusable and tightly scoped, but with randomized class names, you could tightly scope the aforementioned bundle as well. even better would be if html added 'for' attributes to <style> and <script> tags, like labels have, so you could target nodes in the dom by id. perhaps being composable is a bigger challenge, but is it insurmountable with this approach?
- olex 6y agoThis is exactly how vue.js "single file components" work - a <template> with the "bunch of html", <script> and optional <style> blocks.
- clairity 6y agothat's pretty close to what i'm thinking of, but still has some limitations (from https://vuejs.org/v2/guide/single-file-components.html https://vuejs.org/v2/guide/single-file-components.html): • Global definitions force unique names for every component • String templates lack syntax highlighting and require ugly slashes for multiline HTML • No CSS support means that while HTML and JavaScript are modularized into components, CSS is conspicuously left out • No build step restricts us to HTML and ES5 JavaScript, rather than preprocessors like Pug (formerly Jade) and Babel
- shhsshs 6y agoYou may be misunderstanding (or I’m not understanding your intent). Single-file components were made specifically to overcome those issues, as mentioned on the page you linked.
- clairity 6y agoapologies, i did misread the page i quoted from. it does seem like i need to explore these single-file vue components more.
- staycoolboy 6y agoIt would be great to include metrics on: 1. size of framework javascript required to load first 2. tooling to compile. For example, the Vue.js works without tooling, but the React w/Class requires command line tools to build before the site is ready. That's a HUGE difference, IMHO.
- georges_gomes 6y agoco-author here. 1. The bundle size barcharts shows the component size (in light blue) and the framwwork size (darrk blue) 2. The Bundle Analysis chapter contains a description of the build tooling use for each component. Vue can be used without build tooling if you choose to use the Vue lib with the compiler included but we use the pre-compiled way for max performance and smaller Vue runtime (without compiler).
- aylmao 6y ago> Vue can be used without build tooling if you choose to use the Vue lib with the compiler included but we use the pre-compiled way for max performance and smaller Vue runtime (without compiler). +1. And likewise, you can use React without a build step too, though of course it is slower. [1] [1] https://shinglyu.com/web/2018/02/08/minimal-react-js-without-a-build-step-updated.html https://shinglyu.com/web/2018/02/08/minimal-react-js-without...
- Spunkie 6y agoCan you go into any detail why vue components are so large in comparison to every other example in the `Estimated Bundle size` chart?
- staycoolboy 6y agoThank you. I failed reading 101: My fingers ran ahead of my brain. Very good analysis. I can see it took a lot of work and precise attention.
- badsectoracula 6y agoI'm not into web development at all so this sounds very new to me, but aren't components in general meant to be self-contained so that they can be reused as "building blocks" for larger applications (or pages, i guess)? Doesn't using a framework in this case mean that you also have to at least bundle that framework with the component? What happens if you want 10 components that each use a different framework? Or some of them use the same framework but different versions? What about the same version, does that get duplicated for each component or they get shared? Also are these components meant to be "bundled" with your code or you are supposed to source them from their "home" server? In the latter case does that mean that a site using 10 components will open connections to 10 different servers (one for each component, assuming all components are from different developers)? Or am i missing the point completely? TBH i think of "components" as in Lazarus, Delphi, .NET, etc (where you have reusable components like buttons, labels, input boxes, etc but also nonvisual stuff like timers, imagelists, etc).
- tashoecraft 6y agoSo for the angular implementation, the compiler will only include the necessary parts of the framework with the web component. So you’re only including the bits you need for the component to be usable. There are ways you can coordinate the components and their dependencies to rely on the same versions, but this will probably assume they are your components. Svelte does something kind of similar where it doesn’t share the same bits between components, but according to the creator it the theoretical point at where it would be more beneficial to have share is so far off to be pointless. So presumably if you have something that efficient you won’t have to worry so much, I think we are a ways away
- weaksauce 6y ago> Doesn't using a framework in this case mean that you also have to at least bundle that framework with the component? yes something like react would be the main framework on the page. i guess this is showing how much overhead there is in each of the different of frontend frameworks and also what the code to do a relatively simple but not trivial example looks like.
- sillysaurusx 6y ago
- mshenfield 6y agoFirst contentful paint (FCP) is basically the same (+-10ms) from React down to a raw HTMLElement. I guess at some point appending elements to the DOM is the bottleneck, rather than the overhead of parsing JS and the efficiency of said JS. To get a faster FCP, statically rendering the component to HTML and re-hydrating it in the client (using Gatsby, for example) seems like it will have a bigger impact than the WebComponent library used. Unless the client is bandwidth constrained of course.
- georges_gomes 6y agoCo-author of the blog post here. My mistake is to call it FCP. This local benchmark only shows the performance of: - parsing the javascript code - creating the DOM node That was the only goal. We should have network simulation for the next update of the blog post to show some additional color. Good idea :thumbsup: Static + re-hydrating is actually built in Web Components (technically). "Only" tooling like Gatsby or Next.js is missing to make it more developer friendly.
- mshenfield 6y agoThanks for clarifying! That's a fair point about web components having the capacity to be statically rendered and re-hydrated.
- hoten 6y agoWould you consider comparing the results of a Lighthouse report?
- georges_gomes 6y agoSounds good. Like have some sort of generic page with components and look for lighthouse score. I'm adding to the list!
- hoten 6y agoSweet, thanks! Feel free to DM me if you need any help. twitter is in bio.
- eeJah9to 6y agoI've rewrote the frontend of one of my personal apps from react to webcomponents lately. For me, the most interesting aspect was that it's part of standards, requiring no dependency, so it means that I can use this app for decades without having to maintain it. For the same reason, only the first example in this page would do for me (the one based on standard without using any library). But I suppose that for actually publishing something, such library would be needed, if anything for polyfills for older browsers (but then again, we don't expect published work to stand for decades without changes, so maybe the call for standardized technology is not as strong there).
- the-dude 6y ago> so it means that I can use this app for decades without having to maintain it. That seems highly optimistic to me.
- mekkkkkk 6y agoConsidering all mothballed APIs still supported in modern browsers I'd say it's accurate.
- k__ 6y agoDid they improve the SSR story lately?
- infinityplus1 6y agoIsn't React itself still basically written using standard JavaScript? Why won't it run in the future?
- ohmaigad 6y ago> For me, the most interesting aspect was that it's part of standards, requiring no dependency, so it means that I can use this app for decades without having to maintain it. Doesn't really make sense because for JS frameworks and for the "pure" component the dependency is the same - browser. If i don't have to maintain a project i can just pick whatever is the current version of React/Vue/Other and have the project running as long as the browser doesn't break/change something.
- ragerino 6y agoWhen I was a young web-developer, I joined the WHATWG group. And one of my few contributions was asking for custom HTML elements. I actually developed a framework myself in LotusScript ;)
- notJim 6y agoCan't wait for 2–5 years from now when most of these have failed, and the One True Way emerges.
- squeral 6y agoDon't bother waiting. By that time there will be another set of frameworks.
- notJim 6y agoI kinda disagree, I think people are more pessimistic about fracturing than is warranted. For greenfield work, it seems like people have mostly converged on React and Vue, which are conceptually fairly similar. State libs have changed, but again the concepts translate pretty well. Similarly, webpack is the lingua franca. Years ago, we had a new build tool every week, and multiple competing frameworks (backbone, angular, and ember) with very different approaches.
- wishinghand 6y agoI don't think any One True Way will emerge. Svelte is coming out to challenge React and Vue, Alpine+Laravel LiveWire/Phoenix LiveView challenges the concept of needing a front end framework, WASM is challenging needing Javascript at all, and Snowpack/Parcel/Rollup are coming for Webpack's crown.
- rishav_sharan 6y agoIt infuriates me that the concept of composable web pages using small templates/components is not baked into the html spec and supported by browsers. Every bit of code that we write in any programming language is made of composable bits which can be imported into other bits of code. But we cannot do anything similar with html. every time any attempt at having composable component based html is made, it gets mired down in arguments, and we end up with Frankenstein monsters like Web Components, Shadow DOMS etc. Web shouldn't be this hard. but the html governing bodies and the browsers have done a horrible of taking it forward.
- staticvar 6y agoI appreciate how Web Components are not opinionated meanwhile Component libraries are free to innovate and build on the Web Component foundation.
- staticvar 6y agoThere are also simpler ways to write vanilla Web Components. Here's an example of the counter component written in what I find a simpler fashion. https://gist.github.com/rjsteinert/779d94dfc886723c2967a6f5f56beecd https://gist.github.com/rjsteinert/779d94dfc886723c2967a6f5f...
- akersten 6y agoWow, that's so much cleaner - why don't they just do it like this in the example? I'd be much happier learning standard web components if they were all a breath of fresh air like this. Personally I'd miss the JSX syntax, but this more than makes up for it by removing the entire whacky state vs. props thing. Although- how do you represent custom props here - arguments to the constructor? That'd be really elegant. Do those styles and query selectors leak out of the component? I'm assuming they don't since that's the entire point of the idea of a component, but just want to be sure.
- tshaddox 6y ago
- sequoia 6y agoWeb components to me represent the architecture I’d like to have. I think a good arch could be: 1. Build a rails/django type site, make everything work vanilla http+html etc. 2. Create standalone web components for the places you need some more interactivity, like type-ahead search box, “click to add” type thing, or a datatable So most of your performance stuff could be handled/improved on the server, focus on aggressive caching etc. and most of the complexity would be on the server with small stand-alone parts on the client (ideally without a lot of interconnection, i.e. without a big client side state manager). This would not allow full-spa but I am not convinced SPA is the answer in many/most of the cases it’s used.
- edisonywh 6y agoHave you heard about Phoenix LiveView? Sounds like what you want. It's a Rails-like framework written in Elixir (piggyback-ing off 30 years of BEAM), and LiveView changes the game by allowing you to build rich front-end application from your backend. The way it works is that it serves you static HTML on initial load (yay SEO), and then it establishes a websocket connection to the server (very efficient thanks for BEAM), and every subsequent user interaction sends a event_name which you handle on the backend, and the backend respond with only the changed data (Phoenix can intelligently track your changes so it only sends what has actually changed), and then morphdom on the browser side patches things onto front-end. You get the full power of interactivity but you barely have to touch any front end at all (and if you really do, it plays super well with AlpineJS, so you still get that escape hatch). All in all, LiveView is amazing (and the surrounding technology), I just wish more people know about it!
- dpweb 6y agoBeen working on this off and on for the last 15 years. Pretty much ended up where I started. Except the newer JS syntax is nicer than in 2005. Control: controls.hello = e => e.innerHTML = `Hello ${e.getAtttribute('x-who')}` <hello x-who='world' /> "Framework" just cycles thru the dom and calls control def with the element as the param. To handle data, there's a window.data object, which is global data for the app. Its a proxy object. So when window.data is changed, for instance from the results of a fetch, any controls that specify that key - their set() function is called. <button onclick='data.count++'>Click me</button> <counter x-datafield='count'></counter> data.count = 0 controls.counter = e => e.set = () => e.innerHTML = data.count
- georges_gomes 6y agoco-author of the blog post here. Thank you @kjhughes for sharing our work here :pray: I don't know you but I love you already :heart: :) I'm trying to comment where I have something to bring. If you have questions or maybe a list of things that you would like to see in the next update, please shoot at me! Many thanks
- Joeri 6y agoMany thanks for this, it's an excellent resource. A suggestion for a next iteration: it would be nice to see which approaches work in IE11 / legacy edge. From looking into web components it seems those browsers are the major stumbling blocks, and I know stencil has an ability to polyfill things on those browsers, but I don't know about the other solutions.
- georges_gomes 6y agoThanks for the nice words :thumbsup: I'm adding polyfills/IE11 analysis in the TODO list! Great idea.
- fouc 6y agoI wanted to suggest that you could consider adding mithril.js to the list of libraries perhaps. It's a nice alternative to preact/svelte, and it's been around awhile. - BTW, When I go to https://webcomponents.dev/edit/uLX8C4bJf4Kmg2jWu1dL?pm=1 https://webcomponents.dev/edit/uLX8C4bJf4Kmg2jWu1dL?pm=1 it doesn't load the component in the "Stories" tab for latest Safari or an old Chromium v68. Works fine in latest Firefox. I see error message "Unhandled Promise Rejection: SyntaxError: Invalid character '\ud835'" on the worker.helper file in Safari. Chromium 68 ends up with "Unknown worker: undefined"
- georges_gomes 6y agoAdding Mithril.js to the list :thumbsup: Thanks for reporting the issues we will look into it. How to you install a Chrome v68?
- sunseb 6y agoIt's too complicated. Just look at how Svelte is doing components. It's way better and easier.
- nonbirithm 6y ago"Compare coding style, bundle size and performance of 33 different ways to make a Web Component." I thought this was a joke at first. But it suddenly made sense in the context of modern web frameworks and micropackages and all these different ways of doing the same thing. But wait, I thought. Surely it was a typo and they meant to type "3" and fat-fingered it instead? But no. It really is 33. Which one of those 33 would be the best way of doing things for me? How much time would I have to spend evaluating enough of them? I'm going back to HTML 4.
- agquick 6y agoOur company had been looking to move our project away from Knockout.JS and on to Vue/React. I started playing around with native Web Components just because I like the idea of not being locked into a single framework. However, I also wanted to keep using observables/computeds so I wrote a quick library that ties MobX with Native Web components, but has a Vue-like binding syntax. Yes I know it’s yet another library, but it mainly just provides for a simple way to use MobX (an established library) with Web Components (a browser standard), and nothing else. It’s still very new but it works and I’d love feedback. Example fiddle: https://jsfiddle.net/agquick/d0tsqar6/ https://jsfiddle.net/agquick/d0tsqar6/ Github: https://github.com/agquick/elemx.js https://github.com/agquick/elemx.js
- georges_gomes 6y agoI love this creativity :) We should have you in the next update of the blog post!
- agquick 6y agoThanks, that would be awesome! It really makes state management within custom elements a breeze. I'm hoping others who appreciate observables/mobx will take interest and help me grow/maintain it :)
- alex7o 6y agoYou might not have to replace knockout.js the solid framework author actually has implemented a html rendering lib that has bindings for both knockout.js and mobx. You might find it useful https://github.com/ryansolid/dom-expressions https://github.com/ryansolid/dom-expressions.
- aylmao 6y agoNote: if you're building your whole page on top of a library, a larger library isn't necessarily bad. If a library is larger because it does more, useful things, and this means you have to write less and/or smaller components, in a complex app the tradeoff is probably worth it.
- dmix 6y agoWebpack tree-shaking and automatically chunking into multiple tiny js files, which can be selectively loaded only when needed, is also super helpful here.
- martini333 6y agoWhy would you ever have the logic in methods in Vue? Just keep it simple <button @click="count--"> <button @click="count++">
- preommr 6y agoBecause templates should be declarative. Error checking code becomes much more difficult because of the ambiguity and special parsing that has to be done. Its not just the loader, but things like the ide extensions used. Allowing small bits of logic like this makes for very nice one-liners and demos, but in the long term its well worth it to make the template as declarative as possible - ideally just a method name.
- bob1029 6y agoI have a server-side rendering approach that can get instantaneous paint of arbitrarily-complex views after pulling down index.html and exchanging a single pair of websocket messages. Once the initial page is loaded, redraws are as fast as you can get packets between the machines plus 2-3ms for decoding. It involves some very unorthodox methodologies and has latency constraints (similar to Google Stadia hosting model), but there are serious upsides. Including completely untouchable load & response times. I strongly believe we are stuck in a Malthusian Trap regarding the use of HTML/iOS/UWP/Android for clients and then an entirely separate stack of things for the server - Go/.NET/Rust/Python/C++/etc. This separation adds such a huge burden to the development and maintenance of any application. I argue that if we must have some division between client & server, lets move as much of the complexity to the server as we possibly can. It's so much more manageable when you have all of your state in 1 domain like that. If the client doesn't have to track state or reason about its views, the application implementation for each device can be trivial. I don't think that HTML/JS/CSS/JSON APIs represent a good boundary layer. I think final rasterized views, viewport dimensions and client events do. JPEG/MPEG can be decoded incredibly quickly on most mobile client devices due to availability of hardware acceleration. You will never be able to write a website in the traditional sense that can outperform the speed at which you could decode a full-screen JPEG image and display it. Server hardware is also getting insanely powerful with the new generations of AMD CPUs rolling out. Encoding JPEGs using something like LibJpegTurbo on TR/Epyc is ridiculously fast. This is also a type of application that does trivially parallelize across many cores. As bandwidth becomes ever more ubiquitous, and services more geographically-distributed, there is a good chance something like this could become practical in the general case. For now, this is all just a crazy experimental thing that only works for a narrow range of applications. But, I would strongly encourage other developers to start thinking outside of the box. As networks get faster and latency gets lower, we will begin to encounter new "step function" opportunities that fundamentally shift how we do business.
- MH15 6y agoI'd be very interested in hearing more about your work on this technology.
- appleflaxen 6y ago
- jjcm 6y agoI've been working on a webcomponent based reddit/patreon competitor for about a year now, and one thing I found was how incredibly easy it was to spin up my own micro framework. I would highly encourage people to give it a shot. It's just going back to basics and working with class-based inheritance. It will take you a day to write out the basic functions you will need for 95% of your components, and you'll be left with a tiny library that not only solves your needs, but you know inherently. If you're curious, lines 1-26 are all you need to easily bind an html block, a style block, and to do event/attribute binding via @/? statements: https://github.com/jjcm/soci-frontend/blob/master/components/soci-component.js https://github.com/jjcm/soci-frontend/blob/master/components... . The rest of the file are just shared helper functions.
- BigJono 6y agoDon't be stupid, how do you know those 26 lines of code are free of bugs? They're not battle tested and you're just re-inventing the wheel instead of following best practices.
- DonHopkins 6y agoThat's right, we should all follow best practices and use 26,000,000 lines of Angular code, which has been written and debugged by thousands of people, battle tested and wounded and scarred in wars we've never heard of and don't care about, and that we will never get around to reading all of.
- BigJono 6y agoThose 26 million lines of code have been engineered over the better part of a decade to perfectly cater to every possible use case. To not leverage those productivity gains would be insane. You wouldn't build your own car would you? (/s, btw)
- tinco 6y agoA friend of mine did the same thing, I did a small project in his framework and it was really fun. https://github.com/ruphin/gluonjs https://github.com/ruphin/gluonjs I'm not sure if he still maintains it or it's just done, it grew to about a hundred lines but it's quite comfortable. He used it himself to create a quite amazing portfolio page that unfortunately is down right now.