* 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.
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.
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.
It all just seems like a massive wasted effort.
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 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.
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.
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)
Disclaimer: I'm one of the authors
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.
Actively refusing pull requests that make the framework responsive is a bit of a downer for me, but overall I like what the author(s) did
haha can you imagine if desktop users had different resolutions and aspect ratios on their screens? oh wait...
( http://mint-ui.github.io/ )
Note: I'm not affiliated with them, just using them on my latest project.
<input type="radio" />
*I switched from Bootstrap 4.
What framework + feature-complete component library is recommended in 2017?
React? Vue? Polymer? Plain JS with intercooler.js? I feel a bit overwhelmed.
Don't care about details and just want things to work? Vue could be nice.
Prefer sticking as close as possible to the W3C specifications? You will like Polymer.
Telling you want you should use is like telling you what things you should value. Again, all the options are great. All of them have mature tooling, and will 'just work' if you buy in to their way of doing things. Just try them and figure out which one you like.
From egghead.io to online documentation, you will see that while webpack has a lot to it, it is easy to understand in chunks and each part of webpack serves a purpose to better optimize and structure your workflow.
I understand where you're coming from (Webpack initially got a bad reputation as being complex and folks are working hard to improve it) but my note about complexity was relative to simply dropping a script in the page to get Vue.js up and running.
To all the Webpack maintainers, and to all contributors of open-source projects, I can't thank you enough for your efforts. You open doors and expand the minds of developers like me and I'm forever indebted to you.
The current Webpack docs, which have been completely re-written and are _vastly_ better, are at https://webpack.js.org/ .
I find vue to be an amazing library, got started within a week
And there are other individual Vue component libraries like VueTable etc.
I've had very good experience with it - if you know html/JS you will feel at home.
As for being "feature complete" - it has probably best implementation of material design elements and you can find a ton of other element on https://www.webcomponents.org/.
It is also interoperable with other solutions like jquery/angular/aurelia and others.
I think the time for Polymer is gone, and it is better to forget that it exists.
If angular 1.5 was OK for thousands of devs over recent years then Polymer that is comparable to ng2 or react is more then enough.
Not to mention that for a world without polymer - some of biggest enterprises in the world are betting on it (and I don't mean just google here).
If you still want to use it, use it without Vue or React.
I did bundle my components into single file - even throwing in sass compilation so I think the problem is elsewhere ;-)
Polymer 2.0 looks to be much better.
https://github.com/vuejs/vue-element - this might give some hints.
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.
Best way to do that is start with this template:
Which is based on this library:
ClojureScript is fantastic. Being immutable as a baseline makes it work so much better in the React world of things. That said, if you haven't used any Lisps it can be a bit intimidating (for me it still is, a bit), but you get to the point fairly quickly where things can be both daunting and productive at the same time.
If you prefer to stick with more raw JS, I recommend React without a data-framework until you find you need one. Raw react components are plenty to get you started.
ClojureScript gives you the opportunity to write code that's somewhat imperative, just with plenty of extra parentheses.
A smaller leap from a OO language to JS than to ClojureScript, surely you agree there.
That's largely why you can get productive reasonably quickly, even with the intimidation factor still present.
You will find 10 People that tell you use X, 10 use Y, 10 use Z, any suggestion is right and any would be wrong.
Look at the frameworks and features and decide which one come close to your prefered development style. It is not easy and it took time.
In the last 24 month i tried many: backbone, ember, aurelia, react, react redux and currently vue and many of which i forget the name ;-). All have there pros and cons.
If you always look for a newer thing, then you will never find one. To myself: Lesson learned ;-)
I don't know vue well enough to comment, but a lot of people seem to like it.
And to conjure it alive with data: http://stackoverflow.com/questions/39905586/how-to-consume-r...
vue or riot would be a good choice to play and develop something quickly I think.
If you broaden the scope to 'let's use anything', then I'd suggest Ember since I like their model layer better.
The React ecosystem is a bit fractured at the moment, so jumping into it is a full-time job.
In a year or two, I expect it to settle down when some framework rises out of the morass and gains credibility amongst the majority of dev's.
Always got quick response when i had issues.
Great advantage, which is not so exposed, is, that the form system has a good (i think well known) validation system integrated.
Developers did not need to build own hacky solutions or search other libraries that work mostly not good with an external UI.
- How can you be sure you won't be asked for a mobile or responsive version down the road? People change requirements all the time.
- If you want to ever work on other type of projects you now have to learn two when one may have sufficed
- Community size is a huge factor for contributions and momentum, and desktop only limits your community size
For this framework it would be more useful if they offered a single component for a data grid. That's more work than the rest of the framework combined.
In my opinion you'll run into issues with these kitchen sink frameworks once you try to do something custom - customizing elements and components feels like fighting the framework at a certain point and once you realize that it's hard to get out.
I don't recommend using Bootstrap or any other framework unless you're very certain about future requirements.
Here's a nice talk on the topic: https://www.youtube.com/watch?v=Mea2jIXQEFk
I have my own bootstrap.scss, with my own variables/utils... the rest point to the framework versions... It's pretty easy to do and works out really well imho. Of course, I often only change a few colors, and tweak some of the font defaults.
It's a project by Ele.me, a Chinese food delivery company. Alibaba and Ant Financial invested $1.25B in it last year .
UPDATE: Just realised this is developed by a Chinese food delivery service ele.me (饿了么). I visited their website and found its developers made it completely without RWD in mind. This explains things…
> Thanks for contributing, but Element is not for mobile web apps, so the changes here may seem a little weird. Maybe you can just override its CSS in your own project.
Most UIs are Desktop or Mobil based, a UI which fits all is hard to find and sometimes not really good.
The biggest benefit is that you can target specific screen sizes with different html font-size values using @media queries, so for example for bigger displays you can set html font-size to 120% and it will result in automatic increase of size of all the elements where font-size or paddings etc are set with rem. Same goes for mobile devices, for examples all the headers will go from being 40px font-size to say 25px, just by changing an html tag font-size value, you don't have to target any elements individually, it will be automatic.
For me it was one of the best discoveries to increase productivity, when building responsive designs.
I was going to give Vue.js a try for my next project anyway, so I'll be giving serious consideration to using this instead of my default choice (Bootstrap).
And of the people that CAN pay that money, what happens is they send a notice of their newly-established IP being used in a domain and they get it with the help of the registrar.
It's ridiculous to expect a person pay $1000+ for a domain when they go 'oh, we'll just use another domain name!'
People are dumb.
Sorry for bringing this issue here and I'm sure many may not understand my point... but, after reading some posts about objectification of women (like this one: http://www.heroicgirls.com/de-objectify-women-comics-guide), could the woman in the homepage picture be drawn differently?
I'm sure it was not intentional and it may be seem as a small issue for some people, but I know women who do not like to be represented that way.
Thanks for understanding =)
Btw, I really like the page design! It is great =)