Close

Entries with tag web components .

JavaScript datagrid comparison

Data grids are some of the most commonly used components in business apps. But at the same time they are some of the most complex components to implement well. There are many aspects that the component needs to get right – customizability, performance, usability, accessibility, and cross-platform support.

 

After recently releasing Vaadin Grid 2, we wanted to see how it stacks up against other JavaScript grids out there. We selected four grids that are all framework agnostic – that is, they can be used together with any framework. The grids we selected for comparison are Vaadin Grid, bwt-datatable, ag-Grid, and the classic jQuery DataTables.

  Testing JavaScript grid perfomance with Chrome DevTools

So whether you're looking for a grid for your upcoming Polymer project, or are looking for the best alternative to jQuery DataTables, head on over to the comparison and see how they compare.

  Read the data grid comparison

Vaadin Core Elements 2 Roadmap

Polymer 2 support, more components, and theming support

Vaadin Elements 2 Polymer 2 support

These are exciting times for Web developers. More and more browsers have shipped native support for Web Components, allowing us to rely less on polyfills and finally realize the full potential of Web Components. You might have seen that Google released a new Polymer-based version of Youtube a couple weeks ago. Several other large companies like General Electric and McDonald's have also showcased production applications built with Web Components. We're finally seeing Web Components move from "cool future technology" to something that's running business critical apps and sites for large companies.

Announcing Polymer 2 support

One of the major highlights of Google I/O 2017 is the release of Polymer 2.0. This new version of Polymer is both faster and more interoperable than before because it is able to use browser native Web Component implementations and new ECMAScript features.

Vaadin Elements is being updated to support Polymer 2.0, with the most elements already offering hybrid support (works both with Polymer 1 and 2). We are working to add support for the remaining components within the next few weeks. You can follow the implementation status on our GitHub repo or browse the components at vaadin.com/elements.

Looking ahead – building a cohesive, themeable set of components for the next generation of Web apps

While Web Components as a technology has matured, the ecosystem is still young. When it comes to cohesive component sets, Polymer's Paper Elements is still the gold standard. When we started building Vaadin Elements, we understood that it would take us some time to get a complete enough set of components to allow our users to build complete applications. That's why we designed the first iteration to work as an extension to the Polymer Paper Elements set.

One of the most common issues we hear from our users is that the Paper Element set and our components follow Material design and that they want their project to follow their own design. That's why we are evolving Vaadin Elements into a stand-alone set Web Components that you can easily theme to match the look and feel of your organization.

Vaadin Elements theming support

The theming support will allow you to easily customize the look and feel of all Vaadin Elements with CSS custom properties and standard CSS.

Roadmap

Building a new set of components is no small task, especially when you pay as much attention to detail, quality, and accessibility as we do. Getting the entire set of components completed will take some time. Our plan is to work from most commonly used components to more specific use case components. The goal is to have a set of components that is on par with and then going beyond the Vaadin Framework's current set of components. By starting with the most common components, we can cover the majority of use cases as soon as possible.

The roadmap below outlines our current priorities and schedule. We'll keep you updated on progress and show demos as soon as we have something that's ready enough for you to start trying out and giving feedback on.

May

  • vaadin-button
  • vaadin-text-field
  • vaadin-form layout

June – July

  • vaadin-list-box
  • vaadin-dialog
  • vaadin-dropdown-menu

August – October

  • Theming support for all components
  • vaadin-text-area
  • vaadin-checkbox

Later

  • vaadin-menu-button
  • vaadin-progress
  • vaadin-details
  • vaadin-radio-button
  • vaadin-slider
  • vaadin-spinner
  • vaadin-tabs
  • vaadin-tab
  • vaadin-toggle-button

What do you want to see next?

Although we have a clear vision of what we want to build next, we welcome all your comments and suggestions. Are there specific components or features you'd like us to add? Reach out to us on Twitter, Gitter for a chat, or file an issue on GitHub for enhancements you'd like to see.

Browse all Vaadin Elements

Do we still need web frameworks?

The past, present, and future of component-based development on the web

In my previous two posts, I’ve compared Polymer and Angular on performance and developer experience. In this final post of the series, I want to take a step back and look at how we ended up in a situation where Google has two models for building components for the web, what that means for developers today, and what the future might bring. 

A brief look at history

Polymer and Angular are perhaps more similar than you realize. For starters, both are Google projects. Both also take a component-based approach to building apps.

The Polymer project got started in late 2013 as a library and browser polyfill to help developers get started using the Web Components standards that had been introduced two years earlier. Work on Angular 2 began about a year after Polymer, in late 2014. Among the goals for Angular 2 were improved performance and a more scalable, component-based development model. Initially, the Angular team was planning to base the component model on standard components.

Angular 2 plays nicely with web components built using other libraries (Polymer, X-Tag, and others), allowing you to pass data into them as easily as if they were written in Angular. Angular components use web standards (such as shadow DOM and the HTML5 template tag) in browsers that support them.
angular.io, March 2015.

The Angular team later changed their position and built their own component model that is very similar to Web Components, just not tied to the Web Platform. They did this to not be dependent on the DOM. For performance reasons, they wanted to offload some of the browser work to a Web Worker, do pre-rendering on the server and support platforms other than the Web. The downside of this was added complexity — both runtime and development time.

While both Polymer and Angular have a relatively similar take on what the role of a component is, they differ significantly in how prescriptive they are. Polymer is a small library that builds on top of Web standards. Its component model scales from the use of a single Web Component on a static page to building entire applications. It includes helpers for data binding, routing, and localization, but they are all optional. There are some emerging best practices for how to structure applications, but Polymer doesn’t force any of them on the developer.

Angular is the enterprise Java of front-end frameworks

Angular, on the other hand, is much more opinionated. It’s also more than just a framework; it’s a platform of its own. Angular is the enterprise Java of front-end frameworks. It provides enterprise developers the tools and patterns they are used to when building complex apps. It has support for routing, dependency injection, localization, pre-rendering and testing. It gives developers a well-defined way of structuring their apps and dealing with data flow, removing a lot of the uncertainty from building an app.

Why is Google building both Polymer and Angular?

Why is it then that Google has these two separate projects for building component-based Web applications? Wouldn’t it make more sense for Angular to use Web Components as it’s component model? After all, that’s what the Angular 2 team tried to do at first, right?

I think that Google’s end goal is to make the Web as attractive as it can be for app developers. The Web is after all where they make their money. 

One of the obstacles they identified was that the Web needed a component model to support the building of more complex applications. They needed a quick solution, so Angular 2 was created with its own component model. 

Meanwhile, Google worked with the W3C and other browser vendors to pass standards for adding a component model to the Web platform itself. The standardization process is slow, so they created browser polyfills and the Polymer library to help developers get started using the upcoming features.

By having both Angular and Polymer, Google can offer a way of building component-based Web apps in the short term while working on a more elegant solution for the long term. It wouldn’t surprise me if future versions of Angular moved over to use (or at least support) Web Components when browser support is universal.

Community engagement

When it comes to community size and engagement, there’s no question about which one is more popular among developers. Angular has become one of the most popular web frameworks over the last five years, while Polymer and Web Components have remained a very niche technology.

Google Trends for Angular (blue) and Polymer (red) over the last five years.

Polymer is mostly aimed at component developers. The fact is that Web Components alone are a too low-level construct in most cases when building complex apps. Developers want more structure and help, which means that they are looking for frameworks when building larger applications.

Angular’s popularity also means that there is much more community-generated documentation, courses and other learning material available. You are also more likely to find answers to your Angular questions on Stack Overflow and similar sites. For developers looking for a well-established tool for their next project, especially if they need to get buy-in from their management, Angular looks more appealing at the moment.

Paving the way for the next generation of Web frameworks

Looking at the developer adoption of Polymer and Angular makes it fairly evident that developers want to use frameworks when building apps. The way I see it, Angular represents the current generation of Web frameworks while Polymer is paving the way for the next generation.  

Building on Web Components, future Web frameworks can be built leaner and faster as they no longer need to build and run their own component models in the browser. The shared component model also means that frameworks can be made more modular. Some projects only need a router; others may additionally need dependency injection, localization or a testing library. Being able to choose only the parts you need will make development easier and the end user experience faster.

While Web Components are a very powerful concept, I think their biggest impact for most developers is that they are paving the way for a new generation of faster, more light-weight frameworks and tools — a future where every new framework doesn’t need to build its own component set.

— 3 Items per Page
Showing 1 - 3 of 7 results.