I'm just starting to write a web application, and I thought it would be fun to use Dart and Angular.dart for it. I've used Dart and Angular.js both a little bit, and I like them.
I'd like the application to actually be useable by most internet users, though, and it seems like maybe Angular.dart (or at least some of Angular.dart) relies on the shadow dom. From what I can tell, Chrome is the only major browser that supports the shadow dom at all, and even if Firefox, IE, and Safari all implement it, that could be years from now.
I actually tried running Chapter 3 from the Angular.dart tutorial with the dart2js compiler, and the page it made seemed to work fine in Chrome, but failed in Firefox and IE11.
Is my assessment here accurate? Will it probably be a couple years at least before Angular.dart will be useful outside of Chrome? Are there plans for Angular.dart to allow alternatives to its dependency on the shadow dom?
I fear I'll be forced to chose between Angular.js (not nearly as much fun), and Dart with maybe only Polymer.dart (not as nicely / easily structured).
Using Shadow DOM on browsers that don't support it isn't a problem in most cases. There is a polyfill that adds support for Shadow DOM to every modern browser.
I'm not sure about the state of Angular.dart, but at least Polymer.dart is automatically including the Shadow DOM polyfill at the moment.
Using Shadow DOM shouldn't be a problem at all.
Shadow DOM will be an issue on some mobile browsers. The Shadow DOM patch/work around with JavaScript (to provide the functionality to browsers without it built in) isn't quite there yet and constantly suffers from bugs. I even had to use the debug version of it for a while.
While I'm using Angular.dart (and therefore Shadow DOM) in production, I would not recommend it if you can avoid it. For now. It will be pretty awesome though in the future.
So, actually, I do consider it an issue. Polymer and now Angular.dart are looking toward the future and that's great...But they should not be used unless you really can control things a bit. If you can build an app where you know people are using specific browsers only, then you won't have a problem. Otherwise, you most definitely will. At some point.
You have to consider the differences in styling content within the shadowDOM.
This may be a advantage or disadvantage depending on your requirements.
A Guide to Styling Elements
Related
I'm migrating to Bootstrap 5.0.2 and cleaning up the bundling for optimization. With deprecated support for various older browser versions and the fact that Modernizr.js hasn't been updated since 2017, is this line even still necessary?
#Scripts.RenderFormat("<script type=\"text/javascript\" src=\"{0}\" async></script>", "~/bundles/modernizr")
There is browsers that does not support all HTML5 and CSS3 features.
Also more than users, Older versions of a browser are still in use,
To display your website properly in users' old browsers, should of Modernizr.js use
This is more project-specific question.
Maybe it's not necessary at all, thus complete waste of time & efforts when you know who exactly is going to use your work (for example, a closed group of clients with modern hardware and operating systems).
Besides that, it is absolutely wise decision to use Modernizr.
Ask yourself:
do you / how do you know you can use some modern (or even not-so-modern) browser feature without leaving a share of your users with nothing
can you afford angry user because nothing happens when he clicks on "Start application" or shaming layout failure happens
Case: you are okay with testing and providing fallback but Modernizr seems to you like overkill. You want just "feature" in document.body simple test.
is it a good decision to reinvent a wheel of feature testing even if it seems to you that what you are up to is a simple true/false test. Remember, Modernizr often goes way beyond simple tests, because, well, that's precisely what it is made for.
preamble: I'm an advanced Vaadin developer (I've used 6, 7, and now all my project are migrated to Vaadin 8).
I'm starting to study Vaadin 10 / Flow, but I find myself in some hot waters.
What I'm actually struggling with is the "project" itself.
The more I deep into, the more I feel like this framework is moving into a css / html based framework, which requires more css/html knowledge than java.
What I mean is that if you don't perfectly know how css and html works, you can't use this framework easly anymore.
The problem is that I don't know if I'm totally missing the point here and I'm losing into a glass of water, or if that's if really a totally different framework.
Here is where I'm asking an opinion from you, and some confrontations.
I'm finding some very good stuff like #Router and all new navigation paradigms and new Mobile First components, but in example I really can't find a rapid way to build a nice look and feel layout without working with css and html.
Easy stuff done with Vaadin 8 looks now for me very hard to understand... like Templates: working with Vaadin 10 Designer is really, really weird.
I hope I'm simply missing the point, and some of you can help me clearing my thoughts.
I share your concerns about Vaadin Flow. Here are some impressions I have gathered in learning about Vaadin 6-14, studying the doc, reading the forums, watching the Vaadin Ltd YouTube videos. While I do not cite technical proof for every point below, this might help you orient to the purpose and new reality of Vaadin Flow.
Web browsers have matured
The years in developing HTML5 are paying off with huge rewards now.
One of the major goals of the leaders of WHATWG was to rewrite the specs from the practical viewpoint of programmers trying to actually build real browsers. As a result, the modern browsers have far more behavior in common than ever before, with far less “quirks”. Web apps nowadays behave much more predictably across the major browsers.
Also, note that the web browser makers have consolidated in their use of engines. Every major browser has abandoned their own engine to use either Apple WebCore/WebKit or its spin-off Blink/Chromium. Even Microsoft has given up on its own browser engine Trident/EdgeHTML, and has switched to Chromium for their line of Microsoft Edge browsers. So Safari, Edge, Chrome, Opera, Brave, Vivaldi, and so on are all using much the same engine now, for much closer behaviors. Only Mozilla Firefox continues to use its own web browser engine, Gecko (except for Firefox for iOS which uses WebKit per Apple policy). So, we are down to two main browser engines: WebKit/Chromium & Gecko.
This means a major burden on the previous versions 6, 7, and 7 of Vaadin, making up for behavior differences between browsers, has greatly eased. Vaadin’s internal design can now work more directly with the web's own HTML/CSS/DOM model without having to create it's own intervening layer of behavior.
CSS
CSS has improved radically in recent years with CSS3 finally getting fleshed-out and widely adopted.
For decades the experts said “don’t use HTML table for layout” yet offered no page layout in CSS except for the anemic float feature. Finally, CSS 3 offers real layout, feature-rich and robust. And more amazingly, apparently the browsers have broadly supported these features with very compatible implementations. These new layout technologies are Flex-box and Grid-layout.
By the way, there will be no “CSS 4”. Each of the functionality areas comprising CSS 3 is now its own project with its own development and versioning. This is explained well in one of the excellent videos by Jen Simmons on YouTube channel LayoutLand though I cannot locate it at the moment.
Flexbox
Arrange items in a 1-dimensional horizontal row or vertical column. Control stretching-shrinking, inbetween-spacing, left-centering-right positioning, and relative aligning including baseline.
See this excellent visual guide and tutorial.
Sound familiar? CSS flex-box provides the same kind of functionality as the Vaadin HorizontalLayout and VerticalLayout classes. Indeed, in Vaadin Flow those classes have been rebuilt to directly use this CSS functionality rather than recreating that behavior within Vaadin. Vaadin Flow has changed its terminology to match that of the CSS standard, such as setExpandRatio becoming setFlexGrow.
See what versions of what browsers support Flexbox.
Grid Layout
Arrange items in a 2-dimensional grid of rows and columns. Features are similar to to arranging data in cells in an HTML table. Contents can be aligned up-down or left-right within the cell. Contents can optionally span across multiple cells. You can control gap-spacing and justification.
See an excellent tutorial by the same CSS-Tricks.com site as mentioned above.
Sound familiar? CSS grid layout provides the same kind of functionality as the GridLayout in previous versions of Vaadin. The GridLayout class in no longer built for Vaadin Flow, but you can get much the same behavior using a Vaadin Div object combined with direct CSS commands.
See what versions of what browsers support CSS Grid.
Roll-your-own AbsoluteLayout
On a related note, CSS now provides for on-the-fly pixel-oriented layout. Again, this seems to be well-supported across browsers in a consistent matter. So in Vaadin Flow, they decided to drop the AbsoluteLayoutwhich provided this ability to layout widgets in a x-y coordinate system.
In place of AbsoluteLayout, you can make your own simple little layout class by extending the new Div component. In that subclass, for any given widget, you can extract the Element object that represents the HTML element for that widget within the rendered web page. With that Element in hand, you can specify the left & top (x-y) coordinates to be respected.
CSS can be updated dynamically now, so you can change positioning around, or add/drop widgets, within this layout dynamically during runtime.
For an example of such a CSS layout subclass of Div, see Replacement for AbsoluteLayout from Vaadin 8 Framework in Vaadin 10 Flow?.
Web Components
The emerging Web Components technologies are a game changer, having replaced GWT. They allow web pages, and web apps, to be assembled as a collection of chunks each with their own little world of HTML, CSS, and DOM. This encapsulated scope lets a chunk be added without affecting the rest of the chunks. For example, no namespace collisions in naming of CSS classes and identifiers.
This has meant a huge re-write of the Vaadin internals. And so we must be patient (or just keep using Vaadin 8), as some parts we rely on in previous Vaadin are gradually added to Flow. See the page in the manual on Components in Vaadin 10 for a comparison of v8 versus v10/11/12 components. This page has been kept up to date. For example MenuBar changed from being unplanned to now being expected in Vaadin 14.
On the downside, some features of previous Vaadin may not appear. But read that page carefully and research. Some parts that Vaadin previously created on its own are now directly represented as now-reliable HTML or CSS features.
Conclusion
Like you, I have mixed feelings about Vaadin Flow.
The recent talk from Vaadin Ltd about “mobile first” is worrisome. That seems tangential from their legacy of building serious business apps, enterprise-style invoice/purchase-order/accruals kinds of apps, “boring” software as I call it (and make my living from), as opposed to startup-of-the-week web app with severe design and wacky interfaces.
Some parts important for enterprise business apps such as menu bars are currently missing with no good workaround. The Web Components technologies are relatively new in the industry, and will likely have some rough edges and problems in these next few years. The nice safe Vaadin-only bubble I enjoyed is now porous, with app development likely to have some need to involve a bit more CSS or other web tech.
On the other hand, it looks like the enterprise/business features may come, either from within Vaadin or from outside as web-components wrapped as Vaadin objects. The Web Components technologies and their various polyfills are not new, and have been worked on seriously for some years by many people, and seem to be workable now. As for CSS or other web tech leaking into Vaadin, I do not minding learning a bit more about these given how robust and well-designed they are now and how that means much more documentation and stability may come with them, with Vaadin not having to re-create features across squirrelly browsers.
And some of that porousness of CSS/HTML leaking-in may be closed where it makes sense and provides convenience to the Vaadin programmer. For example, I noticed in the Vaadin-12 Releases page, there is a new Java API for choosing an alternative built-in component style from Lumo or Material theme for any of the components that have a variant, along with convenient Java constants defined for naming those variants. Ex: primaryButton.addThemeVariants( ButtonVariant.LUMO_PRIMARY ) ;. This alleviates the need to access the inner Element and manipulate CSS.
I believe in the long run, the future for Vaadin is bright. As a server-side stateful application server able to auto-generate web app clients from (for the most part) non-web programming leaves it as an amazing tool in a position with no direct competition (save Xojo Web Edition, using a similar architecture).
Resources
Should you upgrade to Vaadin 14?by Marcus Hellberg 2019-08-21 on Vaadin.com blog
V8 vs. V10 - two maintained Vaadin versions, which one to choose?by Matti Tahvonen 2018-06-13 on Vaadin.com blog
Vaadin 10 keeps the same philosophy of previous versions: Implement the UI with Java. No need to use HTML or JavaScript at all. Vaadin 10 added some support for HTML templates, but it's an optional feature.
This video can help you to understand Vaadin 10: https://www.youtube.com/watch?v=Un8zKzw6twM
The Wikipedia page for Vaadin is also useful: https://en.wikipedia.org/wiki/Vaadin
Read the documentation chapter on migrating from Vaadin 8 to Vaadin 10.
Is there (or does it make sense for it to be) a reactive-banana over webkitgtk3's DOM? Originally I was looking for reactive-banana-gtk but then realized the widgets were to rigid and I saw no easy way to define new widgets from Haskell. DOM together with css on the other hand could satisfy my needs. Hope this justifies the use case.
What would I need to do to get reactive-banana working over Graphics.UI.Gtk.WebKit.DOM?
I haven't found anything on hackage, github, nor by googling it.
My library Threepenny-GUI is a GUI library that uses the web browser as a display, so you can use HTML+JavaScript from Haskell. This may be what you are looking for.
It has FRP built-in as well. (It doesn't depend on reactive-banana just yet, but I expect to change this in a future release.)
I am starting out a new project that involves the use of JSF 2.0.
From my initial reading, the Mojarra and Apache Implementation of the
project covers the basic components that you will need.
But I know that user's would seek gui with better presentation such as
panel tab, accordion, slider etc... Currently, there are other implementation that I am seeing, the Primefaces, RichFaces and Icefaces.
But I cant find a good article that discusses which among the three are the best.
I have used Spring MVC before but I use JqueryUI for those widget.
Now that I am into component based framework, I would like to use the best JSF Implementation.
I would like to know metrics such as performance/interoperability/ease of use/support.
Sorry if my question might be vague but I would like to hear comments before I select my JSF Vendor Implementation.
Thanks.
I happily use Primefaces as it is by far the most rich set of open source JSF2 controls out there, but they can be infuriatingly buggy at times. It is best to operate under the assumption that component X will not work correctly in a dialog without heavy tinkering.
I would avoid Primefaces if you operate in a development environment with strict UI design requirements as getting everything exactly the way you would like it to look and operate may not be a possibility.
Further I would avoid Primefaces if you are not comfortable with JSF, HTML, JQuery, JavaScript and CSS as you will need a good bit of JQuery trickery to work around the bugs that crop up.
But on that note, I haven't run into a problem yet that a couple lines of custom Javascript haven't fixed for me, and I have one of the most feature rich applications I have ever wrote in the shortest amount of time.
The speed of development is very fast in this area, and any article gets outdated quickly. I used Primefaces for a new project almost a year ago, because at that time it was the only one that was fully compatible with JSF 2 (both Icefacves and Richfaces have had JSF 2 compatible releases in the meantime).
Primefaces has a lot of powerful components that automatically use AJAX, and even more were added in version 3. Unfortunately this focus on new features led to a lot of bugs, but the developers said they would focus on bugfixing after release 3; I can't say anything about the current status since I left the project after 3 months.
There is one thing against Icefaces: a lot of components and functionality are only available in the Enterprise version, which is commercial, not free (but that might as well be a good thing since you get support etc. if your project can afford it).
Why not play with all three libs for a short time, build a simple project and see how you are getting along with either of them. My personal taste prefers Primefaces, but I haven't tried Richfaces since it turned JSF 2 ready.
I have successfully used JBoss RichFaces on a large online B2B store. RichFaces is a quite good framework for building webapps Web 2.0 style, and have easy to use tags that help you develop features faster.
I do not have any metrics regarding performance between RichFaces and IceFaces/Primefaces, but the ease of development should be approximately the same. All three frameworks have similar components, and they are all working towards more and more logic on the client via JavaScript.
At the current state of the JSF libraries, I am fairly sure that you will be happy with whichever framework your choose. IMO RichFaces and IceFaces are the two frameworks that have been around the longest, and i would put my bet on one of these two. IIRC both frameworks have key developers in the JSF design group as well.
As a general rule of thumb, these framework should work interoperably, but I wouldn't mix and match between them. The frameworks are really ment to be used on their own.
Which is better for UI development. Are there any differences between the two UI toolkits?
I currently use Prototype/Scriptaculous, but I'm looking to migrate to jQuery. My main reason is that the developers and community behind Prototype/Scriptaculous seem to have disappeared; there haven't been any new releases in a long time, and several features are still a little buggy. The jQuery & jQuery UI teams seem to be very engaged, more open (see this, for example), and have a larger and more active community.
jQuery is better,
it has noConflict method that allows you to easy migrate, having both prototype/scriptaculous and jquery library included
jQuery is light weight especially in compare with scriptaculous
jQuery produce very simple code that easy to test/review
jQuery support CSS 2/3 selectors even browser doesn't
For ROR there is a plugin jRails
Regards,
Pavel
JQuery will be supported in Visual Studio 2010 making it a good choice for .NET developers.
Check this link - jQuery and Microsoft
See comparison of features: http://wiki.freaks-unidos.net/javascript-libraries
jQuery is very popular and well integrated in many frameworks, while the only framework in which scriptaculous is integrated is Ruby on Rails.
I just migrated all my client side scripting from Prototype / Scriptaculous to jQuery. The result is better performance (less coding + smaller footprint) and the application as a whole seems much richer. There is something really satisfying about jQuery development.
Prototype is a great library, but I got a little frustrated that, as DNS pointed out, the developers & community seem to have gone to sleep.
hmmm I find that scriptaculous is easier to use then JQ because it looks more like javascript and it has more core effects...I like that about it however yes it is a bit buggy and the comunity has started to move to JQuery...However I realy don't like JQ because it is like learning a new lanuage from scratch...it looks nothing like javascript
I've been using jQuery whenever I can. When using scriptaculous, I've found it hard to find suitable plugins that just work. Most of them have bugs or lack good documentation. For example, I went through 3 slideshows including writing my own in Scriptaculous before settling in and modifying one to suit my needs. With jQuery, I just had to go through 1 slideshow plugin because there are so many of them that one was bound to suit my needs.