If anyone is interested in getting started with web components, I recommend taking a look at Google's Polymer[1] library. It's a fairly opinionated approach, but has a relatively small learning curve.
The documentation could be better, and you pretty much have to like Material Design, and there could be a richer set of standard widgets available, and it desperately needs a CDN, but other than that I found it really pleasant to use.
What I haven't tried is building any kind of reactive interface. It's got some support for binding elements to data, but I didn't explore that much. Anyone care to comment?
Here is a question I asked back then: http://stackoverflow.com/questions/25856324/iterating-throug...
You'll see in the answer the complexity around dealing with children that come and go (vs in React you'd actually write it declaratively once and be down with it -- kind of interesting that Polymer has so much "templaty" stuff and is ultimately less declarative than the pure JS approach React).
Another classic approach I've seen is to create an "<x-app>" element which contains the entire site, which also handles the various application state and binding tasks. The Polymer Starter Kit[1] follows this approach, and it also includes tools for building/minification using Vulcanize[2] and gulp[3].
[1] https://github.com/polymerelements/polymer-starter-kit
I've waited a looong time for that.
It does seem like we're getting close to being able to work on the web like I did on my Mac in 1990!
What are the actual software engineering principles Polymer enables developers to apply?
Similarly for CSS selectors and class names - I mean, BEM and SMACCS and stuff are cool and all, but it's also nice to know that my CSS styles won't leak outside the component, so I can just do div class="main" or something and not worry about how other developers name their classes on other branches of the DOM.
It's just a library, so it won't do magic but it's a big improvement.
Before the Polymer rewrite the trivial amount of interactive stuff on my site was raw jquery.
1. JSX tags simply compile to calls like React.createElement("a", { href: url }, ["content"]) and if you just create a short alias for that function, you don't need JSX at all.
2. If you're anything like me, things like Flux scare you by being weirdly ideological and requiring unnecessary boilerplate. You can ignore it and just use a single object to store all your state, according to the "keep it simple, stupid" philosophy. That said, I would recommend that you look at the Redux library, which is a simple and rational approach to the nebulous "Flux" concept. Redux is simple—it's just a certain design pattern that makes sense in the React context.
3. I find React.addons.update to be the most obvious and simple way of doing immutable updates to nested structures—which is what most React programs are doing all the time. People have come up with various libraries for more sophisticated immutable data structures, but you're unlikely to need them, and React.addons.update gives you 90% of the bang.
Next time I have a bit of non-stressed free time, I'd like to make a repository with an example React application that's extremely simple, requiring no tooling and as much as possible avoiding "lockin" to various newfangled libraries and paradigms...
Those tools make it painless to sculpt out a UI in real-time, using the latest ES sugars and a sane module system. Webpack has Uglify built-in, so you can target a minified file for production.
With Babel and JSX, you're still writing idiomatic JS, so you don't have the same lock-in problems you might with something like CoffeeScript. In my mind, it's a clear value-add with no observed downside.
What's your hesitation?
The flip side is simply that it's more technology, more stuff to learn, more stuff to keep running on your computers, and more potential bugs and strange interactions to run into.
I don't like to talk about it in a negative way, because it can sound like I'm disparaging the technology. But, there are nice things about having your project be written in the actual language that the browser already supports. Like simply never having to think about transpilers.
Of course once you've learned about tools like Webpack and Babel, you can use them to your heart's content if they make you more productive. I just wanted to emphasize to the person I replied to that you don't NEED any of them. Especially not to just get started.
You don't need minifying until there's a problem with your page load time and until you actually know that minifying will help with that -- until then, it's strictly speaking a premature optimization. (Writing less complex code may be more important!) And so on.
And "no observed downside" is not strictly true if you consider the cost of added complexity.
For someone who is overwhelmed by infrastructural proliferation, it should be nice to hear that you can develop actual applications with just plain JavaScript and maybe a small Makefile.
Your point about perceived complexity/intimidation is a good one, but for me, removing cross browser inconsistencies simplifies development more than Webpack complicates it.
I like Babel too and the bulk of my new development is in ES6, but ubiquity is a really nice feature for development tools, probably the nicest of all.
[0]: https://facebook.github.io/react/docs/tooling-integration.ht...
I personally hate bindings now, apart for using them with forms, but React offers a mixin for that. What I am interested is if Polymer is worth it or not.
React (with a flux-like control flow library, such as Redux) has a higher cognitive load to start. Where it shines is as additional features are added, there is very little additional complexity. Where with Polymer (or Angular) your application as will see a curve of additional complexity as features are added.
I started a pretty basic setup for React + Webpack with hot reloading[1]. I'm going to add in Redux next, then Router... At which point I'm planning on adding in material-ui[2]. From there, I'll try to keep it updated or forked to use as a base application.
I started it off by following te SurviveJS book[3], but my direction is a bit different. I'd also recommend reading the full stack redux tutorial[4].
While it can admittedly lend itself to a very Java Swing-feeling development flow, that's a breath of fresh air compared to the traditional mess of web code I usually end up with.
WebComponents in general (and Polymer as a particular library on top of them) I feel are going to be a 10x force multiplier for web development.
Web Components to the rescue!
Double-u. Tee. Eff.
Docs.google.com, with a spreadsheet open? 617/585MB. Still entirely unacceptable, but lower than an empty Inbox. The difference between the two should be more than enough to run both, even with a comically generous bloat allowance.
(I'd written then deleted something snarky about Google notoriously rigorous hiring practices really shines when we look at software that results, but seriously, all those smart people and this is what comes out? All their web software is embarrassingly bloated. Chrome's battery drain versus Safari? Android, which seems to take Do the Worst Thing that could Possibly Work as its guiding principle? What is going on in there? Is it some sort of organizational problem?)
The products have gotten bloated, slow, unusable on older devices, and the quality of the actual service has gotten worse, too.
This is just... impossible to use.
Google already is the new Microsoft, and Chrome the new IE. With this, they’re also losing any other reputation they had left.
Google products once used to be about the tiniest and fastest solution, working everywhere, and using the least possible resources, without any bullshit features.