Even though unfortunate to loose support of good people like him, it would be in the interest of the foundation to honer the PM to make biggest impact for their efforts.
Not an explanation or saying its right or wrong, just a comment - anything under 100mb (on my personal computer or smartphone) to me is small enough as to be statistically insignificant in my mental model. I saw 43mb and thought it was kind of slim.
Born in '88 for context, the smallest primary storage device I can remember using was a 20mb HDD on a hand-me-down 486 I got one birthday.
I doubt you’ll be able to buy a personal level 4 anytime soon, it doesn’t make sense to use them as anything but fleet/taxi vehicles since they can just come to you whenever needed.
Buying a L4 car may be not possible. Because I don't even think they will start selling them initially. May be we can bet on number of L4 cars in operation after 5 years.
Any likelihood of this vehicles being at times(say on the highway) autonomous and at times remotely driven ? Does this work technically , and maybe legally ?
Similar background and profession - putting aside whether an individual would ever want to own one, general purpose passenger autonomy won't happen for probably another decade. Limited domain autonomy will be here in before 5 years, though. It'll just suck.
But the first step to getting good at something is sucking at it.
This is similar to what React.js or Vue.js does on the browser. I always thought of this, very nice to see it running.
I worry about the following..
1. How we do complex objects like Trees and Tables?
2. How efficient are these Native nodes over DOM nodes in Browser?
Polymer is built for the world without Vue.js or React. They are slow and heavy weight compared to very very optimized DOM operations done by Vue.js or React.
I think the time for Polymer is gone, and it is better to forget that it exists.
I mean, custom elements just shipped in Chrome a few months ago and are shipping in Safari soon. Firefox is in active development. So a bit too soon to say a technology's time has passed when it hasn't really had a chance up until this point.
Chrome has had Custom Elements since v33, almost 3 years ago. Maybe you're thinking of the latest (v1) iteration of the spec? http://caniuse.com/#feat=custom-elements
We did use in production. And it sucks to support it.
Problems..
* Dynamic components wont work with Vue. Lists etc.
* Loading individual html files for each component. Could not figure out how to bundle the components with Webpack.
If you still want to use it, use it without Vue or React.
The performance benefits of virtual DOM / DOM diffing are way, way overrated IMO. You can use that stuff with Polymer where you really need it, but I just use plain Polymer for everything and it's awesome. I think the time for React is gone :-P
No you can not. Telling from experience. Here is the reason..
Vue is optimized to create/update your DOM elements based on data. Polymer does create a DOM node and internally implement lot os JS to create their own shadow DOM. Each Polyer component can have different life cycle (for Example and Table Component can actually creat TR,TD elements after some time of creating your Custom Table Polymer component). And Vue does not know this. Once the Dom for parent tag is created, Vue assumes its work is done. And if data change mean while it will remove it or update it. But Life Cycle of prevously create Polyermer component may still in progress...and you will get lot of exceptions in console.
How to burn your fingers and see this problem..?
Try to use OnsenUI Polymer components with Vue.JS. Mainly any List and Table tags with dynamic children bound to data.
Weird, vaadin made a compat layer for polymer/angular and it works well. I would expect vuejs would also work reasonably well with proper compat. shim, there is one for vue 1.x.
I have actually tried to use this to build an enterprise application. Here is what we found.
* Most of the components they provide are very basic and does not actually require them to provide it. Couple of lines of wrapper on any CSS framework like bootstrap can make half of those components.
* Most of the advanced components like DataGrid, DropDown Menus, etc are aither not available or buggy. You will get better support from thirdparty Vue components.
* There are lot of silly components like footer and header etc. There is no need for defining them except to show that it is complete UI framework. Trying to be 'Complete UI Framework' is bad choice for any UI on Web. HTML is too flexible and requirements are too diverse that no one UI library can provide everything.
We finally replaced all Element Components with standard bootstrap code. Every thing works perfectly. And we get the benefit of 1000s people testing bootstrap.
Was surprised on mobile that the InputNumber field doesn't spawn a dialer pad (tapping it brings up the alpha keyboard). There are some elements here, for sure, that just seem to be minimally skinned and not fully thought out. Bummer, because I have a lot of work based around enterprise design systems and I love seeing fresh takes on these types of components... not much depth in this library, unfortunately.
The date/time input was particularly disappointing... the time being absolutely hideous even on the desktop. These days I consider material-ui.com (react components) to be one of the best component libraries I've seen. Short of that, I'd just assume use something like Bootstrap for the (s)css and control most of it myself, which is easy enough.
In fact, I'm half surprised they didn't just do a nice set of components meant to be used with Bootstrap, considering the style choices are very close.
I've never used Element, but I share your sentiment. For a library like Vue which doesn't yet (!) have the adoption of React, I tend to avoid 3rd party component libraries especially if they are full of fluff like footer/header components.
I looked at using Vue 2 with bootstrap 4 this past weekend and it seems most Vue+bootstrap integrations are for Vue 1.x while the Vue 2.x bootstrap libraries are incomplete. Instead I just included bootstrap's CSS and for the most part things just work. For things that require JS like modals I found the official bootstrap JS code was very easy to read and had a Vue modal component up and running pretty quickly. I wish the bootstrap docs were a bit clearer as to where JS is used to enhance components. The foundation docs in comparison have the tiny "JS" badge next to all the JS enhanced components, but I'd like to see something more along the lines of "JavaScript is required to disable the body element's scrollbar and to dynamically add the modal backdrop to the DOM".
One thing I find tiring in the JS ecosystem is the constant rewriting of vanilla JS libraries so they play nicely with virtual-dom based libraries and all of the framework specific component libraries which too often play a major role in determining our tech stack. It all just seems like a massive wasted effort.
I think many of us pursue new tech to ensure the chore of doing our work remains fun and engaging, the most important priority! Probably billions of dollars got spent last year just so startups could migrate between one pointless stack and another to entertain their developers instead of their users, and the punchline is the developers still aren't comfortable enough.
Hah. I realize that problem exists in the industry, but for us there's certainly tangible benefits to switching from our current 6 year old UI framework to Vue or React (see my other comment down below).
I was mainly referring to the wasted developer effort of making wrappers for bootstrap, foundation, semantic UI, etc. of varying quality for every framework (react, vue, ember, etc).
In addition, while I realize this isn't a realistic goal :) I wish that our choice in component library was independent of our framework of choice. For instance, it would be nice to use ionic with Vue without spending 2 years writing a vue-ionic wrapper.
I've used it in multiple projects, it's not perfect but overall I'm happy.
There are other component frameworks, but in my experience they are crap, even the ones based on bootstrap.
If you want total control, you are better of writing your own and picking thirdparty vue components trying to solve one problem.
Thanks for writing this, as I was just browsing through and wondering how it would look/work in practice. I got impression that a lot of components really don't need Vue that much.
I am not against having things packaged like this, but like you said, Bootstrap, Foundation etc specialize in this, it seems like overkill not to use them.
We implemented our own. We don't need more than 10 different type of fields. So basically it will take couple of hours to create those base components to our requirements.
The main lession I learned in JS world is, when the requirement is small, better write it from scratch using code we find on net. Trying to integrate different incompatible libraries will just waste our time.
not vue, but I use ReactStrap + Bootstrap4 for that, and it works good.
Bootstrap 4 has some small rendering artifacts (like datetime inputs in inputGroups) but they are pretty fast about fixing them. (Though my input group example, the fix will be in the next release, beta1)
This is one of the reasons I'm working on Bootparts[1]. I needed components to build websites that were JS agnostic. Its based on Bootstrap 3 and under active development. Check it out and let me know of any feedback you may have. Its fairly new (v0.4) but have a 5 year commitment to it.
I was looking at Vue for our enterprise app primarily because our frontend UI code is very complex and difficult to reason about (built on an older tech stack). Thus far I've only ported one of our more complicated UIs to Vue and as I expected the code is far simpler to understand. I pretty much knew this going in though. We would get similar benefits from React, but I do prefer Vue.
There's still some unknowns for me. I have this integrated into our existing app so that on route start it creates the Vue instance and on route change it destroys the vue instance and while that works fine for now I'm not sure if it will cause issues as we migrate the rest of our app.
I also rolled my own validation (which is pretty easy), but I need to evaluate the existing solutions to see what benefits they give.
