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.)
Related
This is a basic question, rather then using Javascript I would like to use Dart to write a firefox extension. Even if I could do it, I might not be able to do it, it might take ten times the effort of using javascript thus not be practical.
Well in the end you're compiling to JavaScript. If the extension is small then it would not be practical as the compiled version will have a lot of lines of code and the size will be bigger than normal.
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
I've been browsing the DeHL repository on GoogleCode, and it looks really good to me.
Many interesting features that make basic programming tasks easier; Some neat things that are in the DotNet FCL, but are missing from the Delphi RTL can be found in this library;
Coded in a modern way, making good use of new language features;
Each class, record type, member function and parameter is documented in such a way that it'll show in the code completion of the Delphi IDE;
Well-organized and clean code;
Plenty of unit tests;
Open source and Free;
Basically, it looks like this library should've been included with Delphi, as part of the RTL.
One major drawback: The project has been discontinued. :-(
Now my question is:
Would it be safe to rely on this library for future projects, and use it as a base framework to build upon?
Basically I'd like to hear from somebody who's actually used this library whether or not it's worth it to invest time in getting to know this library, and why.
IIRC the project was discontinued because it was an over-engineered first attempt and a lot of its features turned out really messy and bloated. You should look at Alex Ciobanu's second attempt, which is simply called Collections. It contains most of the interesting features from DeHL, but leaner.
Be careful, though. It still makes heavy use of generics, which will make your binary size really big if you use it a lot, because the compiler team hasn't implemented a way to collapse duplicate code yet.
Besides the obvious differences between JavaScript and Java, what are the relevant differences in using either SmartClient or SmartGWT?
SmartGWT is the GWT wrapper for SmartClient, which, as you say, means that you're able to write your SmartGWT app using java.
From my experience the only difference that matters when you're programming is that the GWT wrapper is a bit more restrictive than using the js components directly. For example, programmatically scrolling a TreeGrid from java is hell, since the body of the underlying table (that you need to get at in order to scroll the blasted thing) is not exposed through SmartGWT, while it of course is easily reachable from js.
Overall I wouldn't base the choice between the js components and the gwt wrapper soley on these differences, but I would look at other factors in your project. Which techniques are you most comfortable with? How much custimization are you planning on doing?
In my case, code maintainability.
We are a Python house. But for client-side code we opt for GWT, initially with GXT, but now with SmartGWT.
We don't like Java, but we don't like JS much more, Order, maintain libraries for several widgets, extends objects to give custom functionality, etc. between doing this in JS or Java, the option was obvious, Java side. We write reusable components here, and now we write very minimal code for client side, only reuse components and use REST to comunicate with ours Python backends.
We know that SmartGWT is more verbose than SmartClient, but, with Netbeans autocompletion (some coleagues here use Eclipse) we have direct access to every method, documented, instead to go to the showcase or google every time that we need to test and try new functionality.
SmartGWT provides you the advantage that you may use powerful editors.
You can debug your own code easily (however it's not very helpful for diving into the smartclient code itself).
You have all the auto completion stuff of eclipse/netbeans at hand. When starting to work with SmartClient/Gwt it helps you find the things you are looking for because the editor can list you classes or the available methods and some basic documentation what the class/method actually does. Saves you a lot of time crawling through the docs
Banang : API's to access ListGrid / TreeGrid body are now exposed in Smart GWT.
We chose to use Javascript (no SmartGWT) ... I prefer it that way, although some of our team members (newer to Javascript) would have preferred the SmartGWT way. Both have their pros and cons :
One of the advantages of using SmartGWT, is that you get to have compile time errors since everything gets compiled first by the Java compiler, before it gets rendered to Javascript.
One of the drawbacks of SmartGWT, is that it doesn't expose the full underlying Javascript Smartclient API. This means, if you want to do more advanced stuff, you might end up needing to do it in Javascript anyways.
Another drawback of SmartGWT, productivity wise, is that every single change you do and want to test, needs to go thru the painful Java EE compile/deploy process, whereas if you do it in Javascript, you can alter client side code faster by changing .js files directly without the need for the whole compile/deploy process.
SmartGWT is based on java code and when compiled it transforms it into java script, is a
heavy since it transforms java code into js
SmartClient is a framework based on js, you can use its components in an xml page and you manipulate them in Js, and it’s light
le showcase de smartclient
I recommend smartClient
I've been having this discussion with my brother, and it looks like none of us is well qualified to answer the question.
n fact, since I've been learning ASP.Net MVC, I've the impression that I should create all my .aspx pages using HTML/CSS. He (my brother) sustains that - in the modern day - we should not spend to much time on HTML/CSS because there are software (like Dreamweaver) which do just that.
Although I do more of the server side coding, I think it's important to settle this matter for further orientation.
By the way, in case I should use Dreamweaver-designed pages, how would I integrate them in my ASPNET-MVC project?
Thanks for helping
This is the classic discussion pro/against html generation, and just by asking the question you risk the post being closed as "subjective" =)
Basically, you have to decide whether you want simplicity in your work creating the code, or in the code itself.
Dreamweaver (and every other WYSIWYG HTML tool I've ever encountered) will generate a lot of extra code, which will make it harder to incorporate your server side code - simply because there's a larger mess to navigate in.
On the other hand, creating the HTML page might be a lot faster than writing the code by hand.
If you're good at using a WYSIWYG editor, be it Dreamweaver, the built-in one in Visual Studio or some other one, you might benefit from drawing up the rough scetches in that. I would recommend, though, that you always do the finishing by hand, in the code. That's the only way you can retain complete control over your output.
From a purist perspective, unless you can already code your HTML, CSS and JavaScript by hand you shouldn't use a tool that does it for you.
Tools are very valuable at making your more productive, but the experience to know when they screw up is more valuable.
Well, the answer is pretty simple. Dreamweaver is just a glorified code editor with autocomplete, the ability to connect to FTP and upload your work within the program, and a unique "design view" which lets you move coded objects around with your mouse and also give you a visual representation of what your work looks like without opening a full browser. It doesn't matter if you use Notepad, Dreamweaver, or another code editor to create your code. For a fact, I know a lot of ASP/.NET programmers just use MS Visual Studio to do their work because ASP/.NET is simply a MS language and Visual Studio supports a lot of tools which ASP/.NET programmers find useful. That said, you can still code ASP/.NET with any other code editor, it just may be more manual or time consuming on your part to do so. You said "Dreamweaver-designed pages" and all this is is just a document coded with Dreamweaver being used as the code editor, there are no Dreamweaver specifics that would add to the document. Unfortunately, your bother does not seem to understand the differences or the complexities between programs or programming languages and vice-a-versa where they are similar. Whether you are programming for HTML or ASP/.NET, making a stylesheet with CSS, your project being server-side or client-side, it is always good practice to use standard markup and make sure all your work is cross-browser compatible with a strong influence on being compatible with IE. Just remember that most of all code is done by hand, and the reason for this is because the programmer needs to fact check everything he/she is doing to minimize errors and create an efficient document or program. Unfortunately again, a program just cannot do as good a job of realizing the ultimate coding goal than that of a human brain can achieve. Oh, and by the way, unless you are creating a simple document and utlizing only CSS to design that document, leave the design up to the designer.
Tomas is on the money with his comments. Your brother's notion that in the "modern day" you shouldn't have to mess with the code is sadly not true. The tools that we have for html/css/web development will get you only so far. You will likely be able to build a "functioning" site with any of them individually or in combination but to get the real fit and finish that you see in a excellent application you will be working in code as well.
Moreover, you have chosen ASP.NET MVC which for ASP is a pretty thin abstraction layer and works pretty close to the metal. It was designed as a framework for folks who do a lot of the code by hand and with minimal wizardry. The tooling at this point reflects that. The tooling will stub you out a basic application, but the rest you do either outside VS2008 or by hand in the VS2008 editor.
If you are "starting to learn" MVC as you said, your workflow will probably start off by using the framework code generated by VS, so now are working in VS2008. The html editor in VS2008 is limited to say the least, so if you want some more wizard driven development of css or html for your views you may work on a view page or a html snippet in Dreamweaver, Expression or your some other editor. You'll then be dropping that code back in VS2008 and doing more work there to link up the view to the controller.
As you get more of an understanding of the css and html you will use the wizards and dialog driven stuff in Dreamweaver less and less simply because it is faster to just open up the code and make the change.