13 ms·

Why I don't use web components

257 points by catacombs 7y ago

5trokerac3 7y ago
Everything is a give and take. At large organizations I've been at, web component frameworks - especially strictly typed ones like Angular - have tremendously helped to standardize web development across a large team of varying skill levels. When there's only one standard way to make a GET request and a defined interface that the result has to meet, output is much more stable. On the other hand, these frameworks can be completely unnecessary overhead for one or two person teams. I'm currently using Preact for personal work, just because of how simple and lightweight it is. To the author's point on site's that work in older browsers or without JS, unless you're building a product for government use or for an org that has really archaic IT requirements, the chances of needing polyfills that aren't provided by default in the framework are really low. The chances of someone needing your site to work without JS is also really low, especially if you're providing any sort of complex functionality.
- tyingq 7y ago
  "site's that work in older browsers or without JS" I'm curious about this. A graph of say, what percentage of the top 500 websites can't run without JS, over time, would be interesting. My assumption is that it's a non-trivial percentage, and growing.
  - 5trokerac3 7y ago
    I think you're right, but that number should be correlated with number of users running browsers with JS turned off, which I suspect is trivial and shrinking. The biggest issue I've seen with virtual-DOM sites is SEO. Google's crawler started using JS a number of years ago, but there are others that don't.
  - jbarberu 7y ago
    As a past user of NoScript and current user of uMatrix, I can tell you a lot of sites do not degrade gracefully without javascript...
  - HelloNurse 7y ago
    "The top 500 websites" aren't relevant. Their needs and tradeoffs are different, and of course they tend to be negative examples. Does your site work without JS? If not, what justifies the more complex development and the degraded user experience for you and your audience?
    - tyingq 7y ago
      This has nothing to do with my site. I'm curious what the trend is amongst the most visited sites. You sure read a lot between the lines that isn't there.
- murphysbooks 7y ago
  > older browsers or without JS For sites that just convey text, they should work without JS. This would mostly solve accessibility (a11y) issues if sites looked to use simplicity wherever possible instead of adding complexity to solve issues caused by complexity.
- jerf 7y ago
  I think you're reading "web component" as a generic term, but the author is using it to specifically refer to Web Components as a specific browser technology: https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components You can sort of imagine it as another generic "web component" framework, but blessed into full, native browser support, and getting some features/technologies that required browsers to implement new features to support them.
sdegutis 7y ago
I've never considered #9 (global namespace) until yesterday, but it seems like a show stopper for dynamic web components, whereas a system like React has components simply being JavaScript objects that can be imported and whose name is largely irrelevant except at JSX (or HTM[1]) parsing time. [1] https://www.pika.dev/packages/htm https://www.pika.dev/packages/htm
- spankalee 7y ago
  It's being worked on: https://github.com/w3c/webcomponents/issues/716 https://github.com/w3c/webcomponents/issues/716 The fundamental difference here is that HTML needs to know what class to instantiate when it sees a tag. Supplying that unlocks a lot of power, like custom elements in the main document, Markdown support for free, easy integration with existing CMSes. We can and will solve the single namespace problem though.
  - sdegutis 7y ago
    Thanks for the link. By the way I just noticed you're the maintainer of lit-html. How does it compare to HTM[1]? They both look like they accomplish the same goal but HTM's implementation looks smaller. [1] https://github.com/developit/htm https://github.com/developit/htm
    - spankalee 7y ago
      htm is a nice bridge, because it works with React and Preact and both allows for development in standard JavaScript as well as being a runtime perf boost because strings are a lot faster to parse than nested function calls. But htm is just a shell over VDOM (that's why it's small, you still need the real VDOM implementation). React + htm still suffers from its use of VDOM and the diff that necessitates. lit-html doesn't do a diff because it remembers where the dynamic expressions are located in the DOM, so it can directly update them.
      - sdegutis 7y ago
        Oh so lit-html has the incremental DOM update feature built-in? It's a full-fledged replacement for the VDOM? I thought it was just a syntax parser like HTM. (Hence my question.) [Edit] Oooh, I see where I got mixed up: in your README, the only part where I can find mention of this feature is in the very last part of this line: > "lit-html templates are plain JavaScript and combine the familiarity of writing HTML with the power of JavaScript. lit-html takes care of efficiently rendering templates to DOM, including efficiently updating the DOM with new values." Specifically the "including efficiently updating the DOM with new values" part, that's the only mention on this page, and it's literally right after where I started to skim due to (incorrectly) assuming the rest of the sentence was just a continuation of the first part. That feature should probably be mentioned more prominently. Also, if it has the ability to re-render based on state updates (e.g. from onclick callbacks), an example would be really important to know how to make use of that feature.
gildas 7y ago
On my side, the criticism I could make to web components is that there is no standard to serialize their shadow roots and, therefore, they are not deserializable without using JavaScript. I have been maintaining SingleFile [1], a web extension to save complete web pages, for 9 years and this is the first time I have had to include JavaScript code [2] to attach and display the shadow root of the web components (e.g. embed tweets) included in the saved page. [1] https://github.com/gildas-lormeau/SingleFile https://github.com/gildas-lormeau/SingleFile [2] https://github.com/gildas-lormeau/SingleFile/blob/93d1e7c000946800866730c5763e3d0af0a033ef/lib/single-file/single-file-core.js#L940 https://github.com/gildas-lormeau/SingleFile/blob/93d1e7c000...
- dmix 7y ago
  Thanks for your work on this and good job not having to inject JS for so long. I’m surprised there hasn’t been other nasty web stuff that required it.
  - gildas 7y ago
    Thanks! You can find web components in a lot of unexpected places. For example, this page [1] contains more than 10K web components... The good news is that once the Pandora's box is open, I had the idea to code SingleFileZ [2] which also requires JavaScript to be enabled but frankly uses it! [1] https://bugs.chromium.org/p/chromium/issues/detail?id=4 https://bugs.chromium.org/p/chromium/issues/detail?id=4 [2] https://github.com/gildas-lormeau/SingleFileZ https://github.com/gildas-lormeau/SingleFileZ
    - dmix 7y ago
      It’s always interesting what we volunteer ourselves to become experts in through our work in software. I respect any OSS developer that dedicates themselves to this type of thing. I’m curious what google used to create that chromium bug report page (internal framework or a custom job). The internal tools targeting devs with good browsers will always have the most advanced stuff it seems.
thrownaway954 7y ago
I find it so funny how people use to make fun of ColdFusion cause of it's tag syntax and the ability to create your own custom tags. Seems we have come full circle now on the frontend. ColdFusion was truly ahead of it's time.
- cheschire 7y ago
  I'm not sure that paradigm ever ceased. ASP.NET webforms XAML had custom namespaced tags, now ASP.NET Core has custom tag helpers.
- sergiotapia 7y ago
  WPF was react before react was an blob idea in someone's brain. Damn I wonder how 40+ year old engineers feel about tech. "We've seen this shit when your dad was in his teens!"
  - pjmlp 7y ago
    We largely ignore it, until it actually becomes a project requirement, and then we learn hands-on. If we are lucky, most of them die in a space of 5 years, and then you get to enjoy project contracts to port all those shiny apps to boring sound, long lasting technology stacks.
    - sergiotapia 7y ago
      my man
    - snaky 7y ago
      Contracts to port all those truly ancient proprietary stuff to truly ancient non-proprietary stacks are fine too. http://www.tpfug.org/pdf/2019/2019-TPF_Modernization.pdf http://www.tpfug.org/pdf/2019/2019-TPF_Modernization.pdf
- jchw 7y ago
  I think this is missing the forest for the trees. The key innovation behind most modern frameworks is DOM abstraction and reactive data flow. The main reason JS apps were, at one point, ugly spaghetti directly manipulating DOM structures using jQuery is because JS was dog-slow at a point and was not really capable of doing the cool object oriented stuff you could do on desktop apps. jQuery answered to the problems of the time: it was relatively fast, provided a terse interface (vs DOM,) and probably most importantly, it smoothed over browser bugs and inconsistencies. Angular.js finally popularized components, in the post IE6 era when JavaScript execution was a lot less slow and unreliable, then React popularized reactive data flow and virtual DOM. I think most good ideas in software engineering have already been discovered, and primary innovation has long been applying existing ideas more effectively. Hard to argue Angular.js or React does anything that has genuinely never been done before, and same to ColdFusion.
pier25 7y ago
My biggest issue with WCs is that they only solve a small part of the problem. You get custom tags but without data binding and some form of reactivity these are not very helpful. Lit, Skate, Stencil, etc, solve those limitations, but if you are already using a complicated toolchain and third party code for doing the heavy lifting I don't see much value in WCs.
- petilon 7y ago
  You don't need a complicated toolchain. This 200-line lib let you create and use Web Components using JSX syntax, just like React.js: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder
  - pier25 7y ago
    And that library requires TypeScript and you probably will need to minify afterwards. Also: > Unlike React.js UIBuilder does not do incremental screen updates. Which means you now have to start worrying about which parts you have to update. So again, you probably need something like MobX.
  - labrador 7y ago
    Good stuff. I would recommend VSCode over Visual Studio.
- derefr 7y ago
  It’s a bit like having a stdlib type specifically for Sets or URIs or Rational numbers in a programming language. It’s not that any given library couldn’t make its own. It’s that having a single implementation “canonized” in the stdlib means that every library that wants this functionality will be using the stdlib’s implementation, and stdlib functions will also be able to consume or produce that type when it makes sense, and so you’ll have an ecosystem that all interoperates by passing around and transforming this shared type. Also, standardizing Web Components also means changing the semantics of DOM parsing for user-agents other than browsers. My random Python HTML crawler lib isn’t going to parse some third-party library’s implementation of Web Components; but it is going to parse standardized HTML Web Components.
danShumway 7y ago
Good article. This articulates a number of issues that I wasn't able to put into words, particularly around this idea that the DOM can be a really inconvenient way to track state. I still kind of feel like I need to sit down and figure out exactly what my issue is with the current spec, but roughly speaking I guess I'd say that the DOM should be a standardized display layer, not a way to store internal application state. Or put it another way, the DOM is for your users, not for your application. I don't think that fully captures the problem, but it's a bit closer. Regardless, I often flail when people ask me why I'm a little skeptical about the way web components are currently designed, so at least now I have something to point them towards.
- interlocutor 7y ago
  When you use radio buttons, checkboxes and text inputs, they have state and that state is in DOM. Web Components don't change this.
  - danShumway 7y ago
    Again, this is tough to articulate, and I'm not sure I'm going to do a good job, but: Good design seeks to limit the amount that we rely on that state in the DOM. Typically speaking, I try to listen for events on input elements. I don't rely on them as a state store. Text inputs in particular here are kind of a good example, because they often get used in combination with validation and autofill. I've seen a lot of bugs and spaghetti code come out of running validation on field update, and using that validation to update or fill in other fields, and needing to track which update will trigger another event, and so on. I'm not saying we should get rid of interactive elements on the web, but I think they fall into something of a grey area that shouldn't necessarily be encouraged. I use inputs to get the current user state, and to respond to user input -- I try very hard not to use them as a state store for application-level data. I kind of think I would still say the same thing about inputs as I would about regular HTML elements -- input elements are for your users, they're not for you. They're not your interface, they're just the way your users communicate with you.
EGreg 7y ago
Can someone succinctly tell us what problem Web Components actually solve? Is it about avoiding namespacing your CSS? Is it about shipping reusable components for many sites, hosted on some other domains? Loading JS on demand? What? It just seems overly complex and limited with its slots etc.
- derek1800 7y ago
  The big advantage from my perspective is component reusability independent of Framework (React, JSP, Angular, none, etc). A couple scenarios come in mind, you have many teams working on web app(s) that need to have the same styling, CX, controls. You can distribute them this way without tying them to a framework. Another example is complex controls that can be downloaded to speed up development.
  - interlocutor 7y ago
    There is also robustness. Today you can't take a React component from one application and drop it in another React application and expect it to just work. You may need to also copy CSS classes, make sure the class names are unique, remove any conflicting ids, global variables and so on. Thanks to Shadow DOM, web components are much more robust. You can just drop a web component in an existing application and expect it to just work, regardless of what framework (Angular, React etc) it is using.
    - iaml 7y ago
      Except you can, just use styled-components. If you don’t have any other deps except styling, it works quite nicely.
    - EGreg 7y ago
      How is it better than using, say, iframes and postMessage? Is shadow DOM more efficient? Can Web Components work across domains? I want to have Shadow DOM that encapsulates trust, so the enclosing parent javascript cannot access its contents!! https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144
traverseda 7y ago
It's a problem of mixing data and visual elements. In a good model of the web, html is your data, css is your styling, and javascript doesn't really exist. In another model of the web, your data would be your data, html/css would work together to form a scene-graph. Javascript defines the relationship between your data and it's scene graph. That friction, are we using html as data or as part of our scene-graph, is what causes a lot of these problems. I like web components because they bring you closer to having html be just your data. I like react because it brings your html closer to being just your scene graph. Both solve the same underlying problem from different directions.
- shooner 7y ago
  Well, I thought the 'good' model of the web was schema-based XML was your data, XSLT was your representation structure logic, HTML was your representation structure, and CSS was your representation styling. But the ship sailed on that one a while ago...
  - miohtama 7y ago
    The road to hell is paved with XSLT. It was a good idea, but early 00s X-everything were terrible implementations.
    - HelloNurse 7y ago
      XSLT is an unpleasant language (particularly for beginners) but implementations I've seen tend to be correct and stick to the standard; what trouble did you find yourself in?
  - dragonwriter 7y ago
    > Well, I thought the 'good' model of the web was schema-based XML was your data, XSLT was your representation structure logic, HTML was your representation structure Not XSL:FO?
tanin 7y ago
I like the abstraction that web components provide. An encapsulated of logic, view, and namedspaced style is great. I can build things like a button with a loading icon. But I can use Vue's component which don't care about the standard and just compile everything down to a plain JS, so it works well with any browser. On the other hand, PolymerJS tries too much to utilize the web component standard. I didn't originally thought that this would be a bad thing. Svelte does look good. I checked it out a year back and thought that Vue should've moved more stuff into its compiler if it could.
namelosw 7y ago
The Web Component API is too imperative. It's hard to composite, and too easy to let data out of sync (not being reactive). For a broader meaning of Web Component (plain React, Vue, etc), they provide good encapsulation and some degree of local reasoning. But harder to communicate and stay sync with other components/server. For Web Component with a centralized store approach (Redux, Mobx Vuex, etc), it breaks local reasoning, and it requires the user to manage the life cycle of data instead of just reuse the life cycle of components. So there is still quite some space to improve. I found the idea of GraphQL co-location is pretty interesting. And I also found there's a ClojureScript library named Fulcro[0] specifically trying to provide the ability to have a global data store while keeping the ability to local reasoning. [0] https://github.com/fulcrologic/fulcro https://github.com/fulcrologic/fulcro
- spankalee 7y ago
  Web components APIs are low level. They allow code to know where to do things (the element instance, the shadow root) and when to do them (constructor, the lifecycle callbacks). They are not a direct analog to modern frameworks, and it's completely expected that developers will use helper libraries to get better DX like declarative and reactive components. I work on two such libraries: lit-html and LitELement. Combined they give you just as much declarative and reactive power as frameworks, much better DOM and style isolation, better performance, and smaller size than just about anything else out there. Compare a styled Hello World example to React or any other framework: import {LitElement, html, css, property, customElement} from 'lit-element'; @customElement('hello-world') class HelloElement extends LitElement { static styles = css` :host { display: block; } p { background: pink; } `; @property() name; render() { return html`<p>Hello ${this.name}!</p>`; } } (this example uses decorators because I think it's clearer, but we support plain JS as well)
  - arve0 7y ago
    > ... and smaller size than just about anything else out there. Compare a styled Hello World example to React or any other framework: Compared with svelte from the article: <script> export let name; </script> <style> p { background: pink; } </style> <p>Hello {name}!</p> # Size comparison ## lit-element lit-element.js?module: 8421 bytes lit-hello.js: 340 bytes ## svelte bundle.js: 2628 bytes bundle.css: 72 bytes
ww520 7y ago
I've started using web components in my last project and it has been very helpful in compartmentalizing functionality and promoting resue. Things are a bit different in my experience than what're described in the blog. Here're the points as seen differently. 1. Good point, though someone is going to write a server side renderer to pre-generate the custom tags into regular html tags. 2. A web component can import its own CSS file, no need to put styles in JS code or string. <style> @import "/css/shared-styles.css" @import "/components/my-widget/my-widget.css" </style> 5. Composing with sub-components works just fine with or without slotted content. What's wanted in item 5 was a special case for dynamically including content at runtime. That's best left to Javascript when triggered with property setting. 6. For properties and attributes, it's simplest to just reflect all property get/set calls to attributes, using attribute as the only storage. I have some helper function to do that. attrAsProp(comp, attr, property) Object.defineProperty(comp, property, { get: function() { return comp.getAttribute(attr) }, set: function(v) { comp.setAttribute(attr, v) } }); 9. Global namespace is a problem but it also makes things simple to use. We don't want complicate stuff like xmlns.
ken 7y ago
> (The three spec editors are all Googlers. Webkit seem to have some doubts about some aspects of the design.) Here's my issue with a browser monoculture. With 3 or 4 major browsers, it was easy to tell what features would survive. The specs were never great at that -- there were some early spec'd features that never got widely implemented. But any feature that could convince people at Google + Microsoft + Apple + Mozilla to all implement it would be around for a long time. With Microsoft switching to a Chrome-based engine, this is a valuable data point we've lost. Essentially, instead of new features being opt-in by default, they're opt-out. We've seen it before: when one browser has a majority market share, nobody else can afford to tell them an idea is bad.
- nickthemagicman 7y ago
  Doesn't Chrome follow w3 standards though?
  - alexisread 7y ago
    Kinda, the W3C are now following WHATWG, so as Google are the major stakeholder by marketshare it's more like the tail wagging the dog. - https://www.neowin.net/news/w3c-and-whatwg-agree-on-single-html-and-dom-specs https://www.neowin.net/news/w3c-and-whatwg-agree-on-single-h...
    - nickthemagicman 7y ago
      Haha that's nuts. I see your point.
- munificent 7y ago
  This is a good point, but I do feel you're missing a step, and it's one open standards folks sort of gloss over because it's kind of icky. A feature doesn't directly "convince" other browser teams to implement itself. The process, instead, is more like: 1. Browser A adds new non-standard feature. 2. Users like it enough to start using it widely in their apps. 3. Other browsers are now motivated to implement the feature so that those apps work in their browser too. 4. Because of that, there is now incentive to standardize. Finally, the feature becomes a standard. The sketchy part is that step 2 only works when users deliberately choose to build apps that only work in a single browser. That idea anathema to standards folks, but as far as I can tell, the consensus process does rely on it most of the time. That's how we got JavaScript, XHR, <canvas>, etc. It's very hard to convince several independent implementation teams that a feature is a good idea if no one is using it yet.
nickthemagicman 7y ago
I feel like web components are more true to the original intent of the web instead of these SPA frameworks in javascript. You define your page with an XML document of UI components and javascript exists for animation and data fetching. I could be wrong but that's just what it seems like to me.
- dmitriid 7y ago
  Nope. You define your page with custom html tags that won't even render properly without Javascript. And then you need Javascript for literally everything: initialising the component, data fetching, inserting data into the DOM, updating data in the DOM etc.
  - nickthemagicman 7y ago
    When I used SPA's it was basically web components inside of javascript so seemed like a layer of unnecessary indirection? I'm SURE web components allow a non-js fallback, or that should be introduced into the spec. See here for progressive enhancement of web components https://googlechromelabs.github.io/howto-components/howto-tabs/ https://googlechromelabs.github.io/howto-components/howto-ta... Dont' SPA's require defining multiple components? A non-js component inside of the html page and a JSX component or whatever inside of the SPA.
    - dmitriid 7y ago
      > When I used SPA's it was basically web components inside of javascript so seemed like a layer of unnecessary indirection? In vast majority of cases it's nowhere near "basically web components". > I'm SURE web components allow a non-js fallback, or that should be introduced into the spec. They don't. All they can do is render static content inside if they have any. > See here for progressive enhancement of web components I fail to see where you see progressive enhancement. It's literally dozens of lines of Javascript code. If you disable JS on that page, you'll get just the static content with no functionality. > Dont' SPA's require defining multiple components? A non-js component inside of the html page and a JSX component or whatever inside of the SPA All you do is attach the root node of an SPA to any element in the DOM. A common approach would be: <body> <div id="app"></div> </body> // elsewhere in JS code X.render(document.getElementById('app'), rootNode) where X is your framework of choice.
sureaboutthis 7y ago
I've said this here, and elsewhere, before and I'll say it again. Any article on dev.to is by a frustrated redditor trying to make a name for himself. It won't be worth the click to see what it's about so don't waste your time.
- TehShrike 7y ago
  This article was written by the developer who wrote Rollup and Svelte
  - draw_down 7y ago
    And Ractive!
  - sureaboutthis 7y ago
    Someone needs to inform him of the error in his ways of getting published and how low he has sunk.
    - TehShrike 7y ago
      https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman
- draw_down 7y ago
  Madness! This was written by Rich Harris.
- labrador 7y ago
  Why not reconsider and stop saying it.
JMTQp8lwXL 7y ago
I manage a web application with hundreds, if not thousands, of screens written in Angular, Vue, React, and server-side JSPs -- all of it developed over a decade-plus worth of time. While old UIs will be continually be re-platformed into the new, we will always have a legacy monolith. That's the reality of our world. If I want to introduce a design system, where all users of these technologies can work with a basic set of bread-and-butter buttons, input fields, etc., Web Components are the lingua franca of all of these technologies. That's why I use Web Components. Now of course, not everyone is developing on monoliths globbed together with newer tech. But the reality is, most of the software used today is written this way. It isn't pure, functional, isolated modules / apps that startups going from scratch have the privilege of beginning with. Technology stacks slowly become the consequence of business acquisitions, etc. You can exert some control over things, but it will always be a moving target.
- tracker1 7y ago
  Personally, I just find the lack of being able to declaratively pass state and/or event handlers to child components painful. Not to mention that testing with a full DOM (virtual or real) is really slow by comparison. React + Redux + JSS just really matches how I've always conceptualized about building web based applications. I absolutely favor material-ui as a component library. I've been building web applications for almost two and a half decades. React is the first framework that felt "right" to me, and still did after using it. I've used a LOT of options over the years. I do think WC can be used with React in some cases, and that it's probably a better approach if you're building mostly static content and wanting to add additional interactive features outside of core display. I also think in 5+ years there will be a couple library options that makes using WC a better option for application style development.
  - JMTQp8lwXL 7y ago
    Web Assembly will maybe change everything.
    - erikpukinskis 7y ago
diminish 7y ago
If www was invented in this decade we would have a dozen mobile and touch-friendly events and html element types. And if we had those element types mobile web would be easier to use. So Chrome and Firefox please invest in new HTML elements for mobile touch web..
RocketSyntax 7y ago
Looking forward to the day when Django templates can observe realtime changes in user input (aka the equivalent of R Shiny).
carapace 7y ago
(This might sound snarky so I apologize in advance for that.) Just use Elm-lang. In all seriousness, what is the business-value argument against using Elm?
- officialchicken 7y ago
  Hiring/staffing/ramp-up expenses for a team are the majority in comparison to most other expenses the typical SMB will incur. Choosing a widely used technology (or a specific one that is very common in a particular industry) will normally provide greater long-term benefits and potentially reduce risk. "Nobody ever got fired for buying IBM" was a truism 50+ years ago - and still is today in many industries. Edit: grammar, speeeling
  - carapace 7y ago
    I'm not sure I understand exactly what you're saying, but it sounds like a kind of argument I used to encounter back in the day when trying to get people to pick Python over Java, to wit: there are so many more Java programmers than Python programmers, it might be hard to find people. My response was, why would you hire a Java programmer who is unwilling or unable to learn Python? In this case, I would hire a normal person who was good at Sudoku and teach them Elm before I would hire, say, a React specialist who refused to pick up Elm.
- kryptiskt 7y ago
  Terrible backwards compatibility. No escape hatches: The only one who is allowed to do bindings to Javascript is the maintainer. No typeclass mechanism or similar.
  - carapace 7y ago
    Thanks for replying. :-) > Terrible backwards compatibility. At version 0.19... > No escape hatches: The only one who is allowed to do bindings to Javascript is the maintainer. I trust Evan Czaplicki. Did you read his thesis[1]? M'boy can think. > No typeclass mechanism or similar. Okay, but then my question becomes what business value are you unable to realize without a typeclass mechanism? In other words, what is the vital use-case or feature that is so much easier to implement with a typeclass (relative to some other, less elegant solution) and that is so valuable that it counter-balances or outweighs all the benefits of using Elm? (Same question applies to JS escape hatches. And, in theory, if the payoff was high enough you could fork Elm and patch it to do what you needed.) [1] "Elm: Concurrent FRP for Functional GUIs" https://www.seas.harvard.edu/sites/default/files/files/archived/Czaplicki.pdf https://www.seas.harvard.edu/sites/default/files/files/archi...
kls 7y ago
I have a bit of a contrary view on a few of the items, not that I am defending web components, I have my own issues about them but my point is to offer a different perspective on a few of these items: 1. Progressive enhancement - but I think that websites should work without JavaScript wherever possible At a certain point, backwards compatibility becomes more a of hindrance than a help, in an effort to support an ever shrinking demographic. Now I will give the author the fact that they used the word website, where my frame of reference is building modern web applications, falling back to no-javascript to me would be going back to server rendering and the dumpster-fire of page-post AS/JS/PH/P's. 2. CSS in, err... JS Separation of technology, is not separation of concerns. This has been argued over JSX and it has been shown to be a huge productivity improvement. If everything for a component is internal to that component and does not need to be reused in a way other than using that component then there is no reason to separate the technology. As both of their concerns are the UI component. In that regard, where everything is encapsulated to the component (HTML, CSS, JS) it is actually a better pattern to not separate technologies as it makes the component easier to reason about.

257 points by catacombs 7y ago

Everything is a give and take. At large organizations I've been at, web component frameworks - especially strictly typed ones like Angular - have tremendously helped to standardize web development across a large team of varying skill levels. When there's only one standard way to make a GET request and a defined interface that the result has to meet, output is much more stable. On the other hand, these frameworks can be completely unnecessary overhead for one or two person teams. I'm currently using Preact for personal work, just because of how simple and lightweight it is. To the author's point on site's that work in older browsers or without JS, unless you're building a product for government use or for an org that has really archaic IT requirements, the chances of needing polyfills that aren't provided by default in the framework are really low. The chances of someone needing your site to work without JS is also really low, especially if you're providing any sort of complex functionality.

tyingq 7y ago
"site's that work in older browsers or without JS" I'm curious about this. A graph of say, what percentage of the top 500 websites can't run without JS, over time, would be interesting. My assumption is that it's a non-trivial percentage, and growing.
- 5trokerac3 7y ago
  I think you're right, but that number should be correlated with number of users running browsers with JS turned off, which I suspect is trivial and shrinking. The biggest issue I've seen with virtual-DOM sites is SEO. Google's crawler started using JS a number of years ago, but there are others that don't.
- jbarberu 7y ago
  As a past user of NoScript and current user of uMatrix, I can tell you a lot of sites do not degrade gracefully without javascript...
- HelloNurse 7y ago
  "The top 500 websites" aren't relevant. Their needs and tradeoffs are different, and of course they tend to be negative examples. Does your site work without JS? If not, what justifies the more complex development and the degraded user experience for you and your audience?
  - tyingq 7y ago
    This has nothing to do with my site. I'm curious what the trend is amongst the most visited sites. You sure read a lot between the lines that isn't there.
murphysbooks 7y ago
> older browsers or without JS For sites that just convey text, they should work without JS. This would mostly solve accessibility (a11y) issues if sites looked to use simplicity wherever possible instead of adding complexity to solve issues caused by complexity.
jerf 7y ago
I think you're reading "web component" as a generic term, but the author is using it to specifically refer to Web Components as a specific browser technology: https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components You can sort of imagine it as another generic "web component" framework, but blessed into full, native browser support, and getting some features/technologies that required browsers to implement new features to support them.

sdegutis 7y ago

I've never considered #9 (global namespace) until yesterday, but it seems like a show stopper for dynamic web components, whereas a system like React has components simply being JavaScript objects that can be imported and whose name is largely irrelevant except at JSX (or HTM[1]) parsing time. [1] https://www.pika.dev/packages/htm https://www.pika.dev/packages/htm

spankalee 7y ago
It's being worked on: https://github.com/w3c/webcomponents/issues/716 https://github.com/w3c/webcomponents/issues/716 The fundamental difference here is that HTML needs to know what class to instantiate when it sees a tag. Supplying that unlocks a lot of power, like custom elements in the main document, Markdown support for free, easy integration with existing CMSes. We can and will solve the single namespace problem though.
- sdegutis 7y ago
  Thanks for the link. By the way I just noticed you're the maintainer of lit-html. How does it compare to HTM[1]? They both look like they accomplish the same goal but HTM's implementation looks smaller. [1] https://github.com/developit/htm https://github.com/developit/htm
  - spankalee 7y ago
    htm is a nice bridge, because it works with React and Preact and both allows for development in standard JavaScript as well as being a runtime perf boost because strings are a lot faster to parse than nested function calls. But htm is just a shell over VDOM (that's why it's small, you still need the real VDOM implementation). React + htm still suffers from its use of VDOM and the diff that necessitates. lit-html doesn't do a diff because it remembers where the dynamic expressions are located in the DOM, so it can directly update them.
    - sdegutis 7y ago
      Oh so lit-html has the incremental DOM update feature built-in? It's a full-fledged replacement for the VDOM? I thought it was just a syntax parser like HTM. (Hence my question.) [Edit] Oooh, I see where I got mixed up: in your README, the only part where I can find mention of this feature is in the very last part of this line: > "lit-html templates are plain JavaScript and combine the familiarity of writing HTML with the power of JavaScript. lit-html takes care of efficiently rendering templates to DOM, including efficiently updating the DOM with new values." Specifically the "including efficiently updating the DOM with new values" part, that's the only mention on this page, and it's literally right after where I started to skim due to (incorrectly) assuming the rest of the sentence was just a continuation of the first part. That feature should probably be mentioned more prominently. Also, if it has the ability to re-render based on state updates (e.g. from onclick callbacks), an example would be really important to know how to make use of that feature.

gildas 7y ago

On my side, the criticism I could make to web components is that there is no standard to serialize their shadow roots and, therefore, they are not deserializable without using JavaScript. I have been maintaining SingleFile [1], a web extension to save complete web pages, for 9 years and this is the first time I have had to include JavaScript code [2] to attach and display the shadow root of the web components (e.g. embed tweets) included in the saved page. [1] https://github.com/gildas-lormeau/SingleFile https://github.com/gildas-lormeau/SingleFile [2] https://github.com/gildas-lormeau/SingleFile/blob/93d1e7c000946800866730c5763e3d0af0a033ef/lib/single-file/single-file-core.js#L940 https://github.com/gildas-lormeau/SingleFile/blob/93d1e7c000...

dmix 7y ago
Thanks for your work on this and good job not having to inject JS for so long. I’m surprised there hasn’t been other nasty web stuff that required it.
- gildas 7y ago
  Thanks! You can find web components in a lot of unexpected places. For example, this page [1] contains more than 10K web components... The good news is that once the Pandora's box is open, I had the idea to code SingleFileZ [2] which also requires JavaScript to be enabled but frankly uses it! [1] https://bugs.chromium.org/p/chromium/issues/detail?id=4 https://bugs.chromium.org/p/chromium/issues/detail?id=4 [2] https://github.com/gildas-lormeau/SingleFileZ https://github.com/gildas-lormeau/SingleFileZ
  - dmix 7y ago
    It’s always interesting what we volunteer ourselves to become experts in through our work in software. I respect any OSS developer that dedicates themselves to this type of thing. I’m curious what google used to create that chromium bug report page (internal framework or a custom job). The internal tools targeting devs with good browsers will always have the most advanced stuff it seems.

thrownaway954 7y ago

I find it so funny how people use to make fun of ColdFusion cause of it's tag syntax and the ability to create your own custom tags. Seems we have come full circle now on the frontend. ColdFusion was truly ahead of it's time.

cheschire 7y ago
I'm not sure that paradigm ever ceased. ASP.NET webforms XAML had custom namespaced tags, now ASP.NET Core has custom tag helpers.
sergiotapia 7y ago
WPF was react before react was an blob idea in someone's brain. Damn I wonder how 40+ year old engineers feel about tech. "We've seen this shit when your dad was in his teens!"
- pjmlp 7y ago
  We largely ignore it, until it actually becomes a project requirement, and then we learn hands-on. If we are lucky, most of them die in a space of 5 years, and then you get to enjoy project contracts to port all those shiny apps to boring sound, long lasting technology stacks.
  - sergiotapia 7y ago
    my man
  - snaky 7y ago
    Contracts to port all those truly ancient proprietary stuff to truly ancient non-proprietary stacks are fine too. http://www.tpfug.org/pdf/2019/2019-TPF_Modernization.pdf http://www.tpfug.org/pdf/2019/2019-TPF_Modernization.pdf
jchw 7y ago
I think this is missing the forest for the trees. The key innovation behind most modern frameworks is DOM abstraction and reactive data flow. The main reason JS apps were, at one point, ugly spaghetti directly manipulating DOM structures using jQuery is because JS was dog-slow at a point and was not really capable of doing the cool object oriented stuff you could do on desktop apps. jQuery answered to the problems of the time: it was relatively fast, provided a terse interface (vs DOM,) and probably most importantly, it smoothed over browser bugs and inconsistencies. Angular.js finally popularized components, in the post IE6 era when JavaScript execution was a lot less slow and unreliable, then React popularized reactive data flow and virtual DOM. I think most good ideas in software engineering have already been discovered, and primary innovation has long been applying existing ideas more effectively. Hard to argue Angular.js or React does anything that has genuinely never been done before, and same to ColdFusion.

pier25 7y ago

My biggest issue with WCs is that they only solve a small part of the problem. You get custom tags but without data binding and some form of reactivity these are not very helpful. Lit, Skate, Stencil, etc, solve those limitations, but if you are already using a complicated toolchain and third party code for doing the heavy lifting I don't see much value in WCs.

petilon 7y ago
You don't need a complicated toolchain. This 200-line lib let you create and use Web Components using JSX syntax, just like React.js: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder
- pier25 7y ago
  And that library requires TypeScript and you probably will need to minify afterwards. Also: > Unlike React.js UIBuilder does not do incremental screen updates. Which means you now have to start worrying about which parts you have to update. So again, you probably need something like MobX.
- labrador 7y ago
  Good stuff. I would recommend VSCode over Visual Studio.
derefr 7y ago
It’s a bit like having a stdlib type specifically for Sets or URIs or Rational numbers in a programming language. It’s not that any given library couldn’t make its own. It’s that having a single implementation “canonized” in the stdlib means that every library that wants this functionality will be using the stdlib’s implementation, and stdlib functions will also be able to consume or produce that type when it makes sense, and so you’ll have an ecosystem that all interoperates by passing around and transforming this shared type. Also, standardizing Web Components also means changing the semantics of DOM parsing for user-agents other than browsers. My random Python HTML crawler lib isn’t going to parse some third-party library’s implementation of Web Components; but it is going to parse standardized HTML Web Components.

danShumway 7y ago

Good article. This articulates a number of issues that I wasn't able to put into words, particularly around this idea that the DOM can be a really inconvenient way to track state. I still kind of feel like I need to sit down and figure out exactly what my issue is with the current spec, but roughly speaking I guess I'd say that the DOM should be a standardized display layer, not a way to store internal application state. Or put it another way, the DOM is for your users, not for your application. I don't think that fully captures the problem, but it's a bit closer. Regardless, I often flail when people ask me why I'm a little skeptical about the way web components are currently designed, so at least now I have something to point them towards.

interlocutor 7y ago
When you use radio buttons, checkboxes and text inputs, they have state and that state is in DOM. Web Components don't change this.
- danShumway 7y ago
  Again, this is tough to articulate, and I'm not sure I'm going to do a good job, but: Good design seeks to limit the amount that we rely on that state in the DOM. Typically speaking, I try to listen for events on input elements. I don't rely on them as a state store. Text inputs in particular here are kind of a good example, because they often get used in combination with validation and autofill. I've seen a lot of bugs and spaghetti code come out of running validation on field update, and using that validation to update or fill in other fields, and needing to track which update will trigger another event, and so on. I'm not saying we should get rid of interactive elements on the web, but I think they fall into something of a grey area that shouldn't necessarily be encouraged. I use inputs to get the current user state, and to respond to user input -- I try very hard not to use them as a state store for application-level data. I kind of think I would still say the same thing about inputs as I would about regular HTML elements -- input elements are for your users, they're not for you. They're not your interface, they're just the way your users communicate with you.

EGreg 7y ago

Can someone succinctly tell us what problem Web Components actually solve? Is it about avoiding namespacing your CSS? Is it about shipping reusable components for many sites, hosted on some other domains? Loading JS on demand? What? It just seems overly complex and limited with its slots etc.

derek1800 7y ago
The big advantage from my perspective is component reusability independent of Framework (React, JSP, Angular, none, etc). A couple scenarios come in mind, you have many teams working on web app(s) that need to have the same styling, CX, controls. You can distribute them this way without tying them to a framework. Another example is complex controls that can be downloaded to speed up development.
- interlocutor 7y ago
  There is also robustness. Today you can't take a React component from one application and drop it in another React application and expect it to just work. You may need to also copy CSS classes, make sure the class names are unique, remove any conflicting ids, global variables and so on. Thanks to Shadow DOM, web components are much more robust. You can just drop a web component in an existing application and expect it to just work, regardless of what framework (Angular, React etc) it is using.
  - iaml 7y ago
    Except you can, just use styled-components. If you don’t have any other deps except styling, it works quite nicely.
  - EGreg 7y ago
    How is it better than using, say, iframes and postMessage? Is shadow DOM more efficient? Can Web Components work across domains? I want to have Shadow DOM that encapsulates trust, so the enclosing parent javascript cannot access its contents!! https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144

traverseda 7y ago

It's a problem of mixing data and visual elements. In a good model of the web, html is your data, css is your styling, and javascript doesn't really exist. In another model of the web, your data would be your data, html/css would work together to form a scene-graph. Javascript defines the relationship between your data and it's scene graph. That friction, are we using html as data or as part of our scene-graph, is what causes a lot of these problems. I like web components because they bring you closer to having html be just your data. I like react because it brings your html closer to being just your scene graph. Both solve the same underlying problem from different directions.

shooner 7y ago
Well, I thought the 'good' model of the web was schema-based XML was your data, XSLT was your representation structure logic, HTML was your representation structure, and CSS was your representation styling. But the ship sailed on that one a while ago...
- miohtama 7y ago
  The road to hell is paved with XSLT. It was a good idea, but early 00s X-everything were terrible implementations.
  - HelloNurse 7y ago
    XSLT is an unpleasant language (particularly for beginners) but implementations I've seen tend to be correct and stick to the standard; what trouble did you find yourself in?
- dragonwriter 7y ago
  > Well, I thought the 'good' model of the web was schema-based XML was your data, XSLT was your representation structure logic, HTML was your representation structure Not XSL:FO?

tanin 7y ago

I like the abstraction that web components provide. An encapsulated of logic, view, and namedspaced style is great. I can build things like a button with a loading icon. But I can use Vue's component which don't care about the standard and just compile everything down to a plain JS, so it works well with any browser. On the other hand, PolymerJS tries too much to utilize the web component standard. I didn't originally thought that this would be a bad thing. Svelte does look good. I checked it out a year back and thought that Vue should've moved more stuff into its compiler if it could.

namelosw 7y ago

The Web Component API is too imperative. It's hard to composite, and too easy to let data out of sync (not being reactive). For a broader meaning of Web Component (plain React, Vue, etc), they provide good encapsulation and some degree of local reasoning. But harder to communicate and stay sync with other components/server. For Web Component with a centralized store approach (Redux, Mobx Vuex, etc), it breaks local reasoning, and it requires the user to manage the life cycle of data instead of just reuse the life cycle of components. So there is still quite some space to improve. I found the idea of GraphQL co-location is pretty interesting. And I also found there's a ClojureScript library named Fulcro[0] specifically trying to provide the ability to have a global data store while keeping the ability to local reasoning. [0] https://github.com/fulcrologic/fulcro https://github.com/fulcrologic/fulcro

spankalee 7y ago
Web components APIs are low level. They allow code to know where to do things (the element instance, the shadow root) and when to do them (constructor, the lifecycle callbacks). They are not a direct analog to modern frameworks, and it's completely expected that developers will use helper libraries to get better DX like declarative and reactive components. I work on two such libraries: lit-html and LitELement. Combined they give you just as much declarative and reactive power as frameworks, much better DOM and style isolation, better performance, and smaller size than just about anything else out there. Compare a styled Hello World example to React or any other framework: import {LitElement, html, css, property, customElement} from 'lit-element'; @customElement('hello-world') class HelloElement extends LitElement { static styles = css` :host { display: block; } p { background: pink; } `; @property() name; render() { return html`<p>Hello ${this.name}!</p>`; } } (this example uses decorators because I think it's clearer, but we support plain JS as well)
- arve0 7y ago
  > ... and smaller size than just about anything else out there. Compare a styled Hello World example to React or any other framework: Compared with svelte from the article: <script> export let name; </script> <style> p { background: pink; } </style> <p>Hello {name}!</p> # Size comparison ## lit-element lit-element.js?module: 8421 bytes lit-hello.js: 340 bytes ## svelte bundle.js: 2628 bytes bundle.css: 72 bytes

ww520 7y ago

I've started using web components in my last project and it has been very helpful in compartmentalizing functionality and promoting resue. Things are a bit different in my experience than what're described in the blog. Here're the points as seen differently. 1. Good point, though someone is going to write a server side renderer to pre-generate the custom tags into regular html tags. 2. A web component can import its own CSS file, no need to put styles in JS code or string. <style> @import "/css/shared-styles.css" @import "/components/my-widget/my-widget.css" </style> 5. Composing with sub-components works just fine with or without slotted content. What's wanted in item 5 was a special case for dynamically including content at runtime. That's best left to Javascript when triggered with property setting. 6. For properties and attributes, it's simplest to just reflect all property get/set calls to attributes, using attribute as the only storage. I have some helper function to do that. attrAsProp(comp, attr, property) Object.defineProperty(comp, property, { get: function() { return comp.getAttribute(attr) }, set: function(v) { comp.setAttribute(attr, v) } }); 9. Global namespace is a problem but it also makes things simple to use. We don't want complicate stuff like xmlns.

ken 7y ago

> (The three spec editors are all Googlers. Webkit seem to have some doubts about some aspects of the design.) Here's my issue with a browser monoculture. With 3 or 4 major browsers, it was easy to tell what features would survive. The specs were never great at that -- there were some early spec'd features that never got widely implemented. But any feature that could convince people at Google + Microsoft + Apple + Mozilla to all implement it would be around for a long time. With Microsoft switching to a Chrome-based engine, this is a valuable data point we've lost. Essentially, instead of new features being opt-in by default, they're opt-out. We've seen it before: when one browser has a majority market share, nobody else can afford to tell them an idea is bad.

nickthemagicman 7y ago
Doesn't Chrome follow w3 standards though?
- alexisread 7y ago
  Kinda, the W3C are now following WHATWG, so as Google are the major stakeholder by marketshare it's more like the tail wagging the dog. - https://www.neowin.net/news/w3c-and-whatwg-agree-on-single-html-and-dom-specs https://www.neowin.net/news/w3c-and-whatwg-agree-on-single-h...
  - nickthemagicman 7y ago
    Haha that's nuts. I see your point.
munificent 7y ago
This is a good point, but I do feel you're missing a step, and it's one open standards folks sort of gloss over because it's kind of icky. A feature doesn't directly "convince" other browser teams to implement itself. The process, instead, is more like: 1. Browser A adds new non-standard feature. 2. Users like it enough to start using it widely in their apps. 3. Other browsers are now motivated to implement the feature so that those apps work in their browser too. 4. Because of that, there is now incentive to standardize. Finally, the feature becomes a standard. The sketchy part is that step 2 only works when users deliberately choose to build apps that only work in a single browser. That idea anathema to standards folks, but as far as I can tell, the consensus process does rely on it most of the time. That's how we got JavaScript, XHR, <canvas>, etc. It's very hard to convince several independent implementation teams that a feature is a good idea if no one is using it yet.

nickthemagicman 7y ago

I feel like web components are more true to the original intent of the web instead of these SPA frameworks in javascript. You define your page with an XML document of UI components and javascript exists for animation and data fetching. I could be wrong but that's just what it seems like to me.

dmitriid 7y ago
Nope. You define your page with custom html tags that won't even render properly without Javascript. And then you need Javascript for literally everything: initialising the component, data fetching, inserting data into the DOM, updating data in the DOM etc.
- nickthemagicman 7y ago
  When I used SPA's it was basically web components inside of javascript so seemed like a layer of unnecessary indirection? I'm SURE web components allow a non-js fallback, or that should be introduced into the spec. See here for progressive enhancement of web components https://googlechromelabs.github.io/howto-components/howto-tabs/ https://googlechromelabs.github.io/howto-components/howto-ta... Dont' SPA's require defining multiple components? A non-js component inside of the html page and a JSX component or whatever inside of the SPA.
  - dmitriid 7y ago
    > When I used SPA's it was basically web components inside of javascript so seemed like a layer of unnecessary indirection? In vast majority of cases it's nowhere near "basically web components". > I'm SURE web components allow a non-js fallback, or that should be introduced into the spec. They don't. All they can do is render static content inside if they have any. > See here for progressive enhancement of web components I fail to see where you see progressive enhancement. It's literally dozens of lines of Javascript code. If you disable JS on that page, you'll get just the static content with no functionality. > Dont' SPA's require defining multiple components? A non-js component inside of the html page and a JSX component or whatever inside of the SPA All you do is attach the root node of an SPA to any element in the DOM. A common approach would be: <body> <div id="app"></div> </body> // elsewhere in JS code X.render(document.getElementById('app'), rootNode) where X is your framework of choice.

sureaboutthis 7y ago

I've said this here, and elsewhere, before and I'll say it again. Any article on dev.to is by a frustrated redditor trying to make a name for himself. It won't be worth the click to see what it's about so don't waste your time.

TehShrike 7y ago
This article was written by the developer who wrote Rollup and Svelte
- draw_down 7y ago
  And Ractive!
- sureaboutthis 7y ago
  Someone needs to inform him of the error in his ways of getting published and how low he has sunk.
  - TehShrike 7y ago
    https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman
draw_down 7y ago
Madness! This was written by Rich Harris.
labrador 7y ago
Why not reconsider and stop saying it.

JMTQp8lwXL 7y ago

I manage a web application with hundreds, if not thousands, of screens written in Angular, Vue, React, and server-side JSPs -- all of it developed over a decade-plus worth of time. While old UIs will be continually be re-platformed into the new, we will always have a legacy monolith. That's the reality of our world. If I want to introduce a design system, where all users of these technologies can work with a basic set of bread-and-butter buttons, input fields, etc., Web Components are the lingua franca of all of these technologies. That's why I use Web Components. Now of course, not everyone is developing on monoliths globbed together with newer tech. But the reality is, most of the software used today is written this way. It isn't pure, functional, isolated modules / apps that startups going from scratch have the privilege of beginning with. Technology stacks slowly become the consequence of business acquisitions, etc. You can exert some control over things, but it will always be a moving target.

tracker1 7y ago
Personally, I just find the lack of being able to declaratively pass state and/or event handlers to child components painful. Not to mention that testing with a full DOM (virtual or real) is really slow by comparison. React + Redux + JSS just really matches how I've always conceptualized about building web based applications. I absolutely favor material-ui as a component library. I've been building web applications for almost two and a half decades. React is the first framework that felt "right" to me, and still did after using it. I've used a LOT of options over the years. I do think WC can be used with React in some cases, and that it's probably a better approach if you're building mostly static content and wanting to add additional interactive features outside of core display. I also think in 5+ years there will be a couple library options that makes using WC a better option for application style development.
- JMTQp8lwXL 7y ago
  Web Assembly will maybe change everything.
  - erikpukinskis 7y ago

diminish 7y ago

If www was invented in this decade we would have a dozen mobile and touch-friendly events and html element types. And if we had those element types mobile web would be easier to use. So Chrome and Firefox please invest in new HTML elements for mobile touch web..

RocketSyntax 7y ago

Looking forward to the day when Django templates can observe realtime changes in user input (aka the equivalent of R Shiny).

carapace 7y ago

(This might sound snarky so I apologize in advance for that.) Just use Elm-lang. In all seriousness, what is the business-value argument against using Elm?

officialchicken 7y ago
Hiring/staffing/ramp-up expenses for a team are the majority in comparison to most other expenses the typical SMB will incur. Choosing a widely used technology (or a specific one that is very common in a particular industry) will normally provide greater long-term benefits and potentially reduce risk. "Nobody ever got fired for buying IBM" was a truism 50+ years ago - and still is today in many industries. Edit: grammar, speeeling
- carapace 7y ago
  I'm not sure I understand exactly what you're saying, but it sounds like a kind of argument I used to encounter back in the day when trying to get people to pick Python over Java, to wit: there are so many more Java programmers than Python programmers, it might be hard to find people. My response was, why would you hire a Java programmer who is unwilling or unable to learn Python? In this case, I would hire a normal person who was good at Sudoku and teach them Elm before I would hire, say, a React specialist who refused to pick up Elm.
kryptiskt 7y ago
Terrible backwards compatibility. No escape hatches: The only one who is allowed to do bindings to Javascript is the maintainer. No typeclass mechanism or similar.
- carapace 7y ago
  Thanks for replying. :-) > Terrible backwards compatibility. At version 0.19... > No escape hatches: The only one who is allowed to do bindings to Javascript is the maintainer. I trust Evan Czaplicki. Did you read his thesis[1]? M'boy can think. > No typeclass mechanism or similar. Okay, but then my question becomes what business value are you unable to realize without a typeclass mechanism? In other words, what is the vital use-case or feature that is so much easier to implement with a typeclass (relative to some other, less elegant solution) and that is so valuable that it counter-balances or outweighs all the benefits of using Elm? (Same question applies to JS escape hatches. And, in theory, if the payoff was high enough you could fork Elm and patch it to do what you needed.) [1] "Elm: Concurrent FRP for Functional GUIs" https://www.seas.harvard.edu/sites/default/files/files/archived/Czaplicki.pdf https://www.seas.harvard.edu/sites/default/files/files/archi...

kls 7y ago

I have a bit of a contrary view on a few of the items, not that I am defending web components, I have my own issues about them but my point is to offer a different perspective on a few of these items: 1. Progressive enhancement - but I think that websites should work without JavaScript wherever possible At a certain point, backwards compatibility becomes more a of hindrance than a help, in an effort to support an ever shrinking demographic. Now I will give the author the fact that they used the word website, where my frame of reference is building modern web applications, falling back to no-javascript to me would be going back to server rendering and the dumpster-fire of page-post AS/JS/PH/P's. 2. CSS in, err... JS Separation of technology, is not separation of concerns. This has been argued over JSX and it has been shown to be a huge productivity improvement. If everything for a component is internal to that component and does not need to be reused in a way other than using that component then there is no reason to separate the technology. As both of their concerns are the UI component. In that regard, where everything is encapsulated to the component (HTML, CSS, JS) it is actually a better pattern to not separate technologies as it makes the component easier to reason about.