Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I found lots of HTML5 UI frameworks over there, such as:
Kendo
Wijmo
jqWidgets
Zebra
Sencha
SproutCore
YUI
XUI
Shield UI
I'm kinda overwhelmed with again so much resources out there.
Looked some of them, but almost all seemed like too slow and heavyweight.
I'm getting a bit confused about which one will I learn.
Each of their websites talk about their product as if they were the best on the market. (obvious marketing strategies).
As a beginner on web apps development and client-side JS UI frameworks; you guys, based on your experience which one do you recommend for rapid desktop web apps development considering speed, widget collections, complexity, look n' feel, support, etc?
Which one do you recommend me to start learning?
I know there could be lots of answers and each one could prefer different ones, but this could help to guide me a little and have some critics of some of the most popular frameworks.
There is so much in your question, that the answer won't be easy and won't be definite at all. It'll also be very opinionated. Looking at the list of framework you brought, I see very different things that are hardly comparable with each other. I'll try to group them somehow and add more frameworks to the list.
The main question here is not the pros and cons of a particular framework. The main question is: how much do you want? Did you really mean an application like Gmail or Grooveshark? Or did you mean something like Stackoverflow - a dynamic and not at all simple, but still a website. Let's consider all of these options.
Perhaps, you just want to enhance your website with some widgets, like tabs, dialogs, some draggable/droppable elements, text editing, etc and you are not willing to change your development model. I mean, you use your favourite Java/PHP/Ruby and do not wish to write the a lot of your app's logics and behaviour in JavaScript. In this case, jQuery-based plugin-like solutions will do for you, particularly, jQuery UI and jQuery Mobile.
jQuery widgets follow its plugin system. This generally means, that they are extremely easy to use. In order to create a button, you write:
$('#myButton').button();
Now if you want to disable it, you call a method using following pattern:
$('#myButton').button('disable');
And getting or setting values, e.g. on slider or datepicker, looks like this:
$('#mySlider').slider('value');
$('#mySlider').slider('value', 42);
As you see, jQuery-based solutions have no model. All your data is kept in DOM and is obtained via quirky method calls. If you need to dynamicly process your data, e.g. do some complex validations, load something in background, filter or sort, then you see that this will soon get messy. By the way, this is the problem why jQuery UI team has not provided a grid control yet - they can't do it without a model. In jQuery Mobile you get a nice mobile UI by the means of simple markup, but there is no official way to pass data between pages.
Summing this up: if you have a multi-page website, if you POST your forms, then use jQuery UI or a lighter solution like Twitter Bootstrap.
Perhaps, you want to build something more complex, more application-like (a single-page application?). You know you will need to work with data on client side. What are your options then?
You can use one of many JavaScript frameworks that provide you with models, data binding and probably other means of creating web apps and integrate them with why not jQuery UI. Or you can use a more complete framework like Kendo or Wijmo or jqWidgets. These frameworks rely on jQuery (Wijmo relies on jQuery UI) and provide additional means of data manipulation. They have a data models. Kendo implements its own solution (I think), while Wijmo and jqWidgets integrate with the popular Knockout JS.
So Kendo and Wijmo belong to the group of frameworks that provide both widgets/controls and some backing model. There are other frameworks like these, that are not jQuery-based, e.g. Dojo Toolkit. Add some dynamic data loading and you'll get a somewhat complex web application. What more can you wish?
Actually, the most important thing is forgotten - how do you structure (organize) you application? If you try to build a single-page app that communicates with server in RESTful way, then you will soon get into a mess if your application has no architecture. The features that are usually required for this are some concern separation (MVC, MVVM), templating, routing and module management. This is where SproutCore and Sencha appear. They provide a comprehensive solution for building web apps, where widgets are just a small part.
It may seem like SproutCore and Sencha are the winners here, because they are the most complete solutions that include both UI and the business logics and also structure your application. Despite all the pros, there are some cons. Some say they are too heavyweight or will require to adhere to their development model, which you might not like. For example, in Sencha you describe your GUI in JavaScript and use Sencha's type system. This adds a sort of heavy feeling that there are abstractions and wrappers, while you really like the ease of HTML, CSS and vanilla JavaScript.
But this is not the only way. The power of web is that there are many-many frameworks, libraries, tools out there, smaller and bigger ones, that will help you craft your app the way you like it. For example, consider AngularJS. It doesn't provide a set of controls itself, but combined with Twitter Bootstrap becomes a complete solution for RIA. Or, for example, look at EmberJS, a more lightweight framework from the guy who created the heavyweight SproutCore. It doesn't provide you with a set of widgets either, but is, in my opinion, a very good base for an app.
So here is my final thought instead of conclusion. All those framework usually show you their widget set, nicely looking themes and the other visual stuff. But what really matters is how you will actually develop you application, how you will structure it, where you will implement your logic. Get to know what the framework provides and think through whether you can substitute what's missing.
Infeligo's answer is top notch. My experience may be of interest to some. I use Ruby on Rails as my server platform where the bulk of my business logic resides.
At the front end I use dHTMLX which is a JS library of 'objects' the most powerful of which is their grid object. Most of my apps have business/accounting information processing/display requirements and the grid object is my mainstay there. However their object set is comprehensive including the ability to create additional 'windows' within the single application to provide a MDI type interface to the end user. I typically have a login form which when successfully applied opens a single HTML page with a menu at the top. Based on selection from the menu new windows are opened and closed to display / manipulate information. These windows are within the scope of the single HTML page.
All the objects have very good events associated with them and I do quite a bit of validation at the front end using these events. However I usually duplicate all validation of data within the Rails Model as well. It's additional work but I'm just extra cautious. There are also a number of abstract objects that help to connect data between the front end visual objects e.g. grid and back end server. Most of the data connections can be done using XML or JSON. I use XML over JSON simply because of my experience with that structure and the fact that Rails provides a decent XML builder. So in my case I rarely use any Rails based views as all of my visual objects come from dHTMLX.
The other thing I like about dHTMLX is the speed of their objects. For example the grid object will quite easily handle 10,000+ rows at very acceptable speeds.
The BIG DOWNSIDE of the suite is it's documentation. The company is an eastern European developer and therefore it is often difficult to understand exactly what their documentation means. Also their documentation tends not to document everything completely and so a lot of time is wasted in trial and error type learning.
Hope this helps
Related
We are developing a SaaS-application and currently facing the situation that different customers ask for different customizations. I have already googled and read a lot specifically about Multitenancy. I am also familiar with the Strategy Pattern.
But this still leaves me a bit confused about a good concept for an Angular 2+ application. Business logic is not gonna be the problem, as I can use Angular's dependency injection to load and use customized services for different customers. Also theming itself is not a problem, as we use Angular Material which has a nice theming engine build in. What does give me a headache are the templates itself. Of course I can use *ngIf and *ngSwitch within the HTML templates, but this is exactly the kind of code I want to avoid, because it will become horrifying once reaching 50+ customer versions.
Let's have a real life example. On a search-page all customers can search for objects and export single objects as a file download. One specific customer asks as to implement a mass export in a proprietary file format which needs a new button in the page, which obviously all the other customer should not see.
The three options I can think of for this scenario (and none of which I really like) are the following:
as mentioned before working in the template itself with *ngIf and/or *ngSwitch*
using the theming capabilities of Angular Material and working with css-only (display: none;)
maintaining multiple versions of the component (depending on the needs using component inheritance) and loading the correct version of the component depending on the user
All of them have obvious con's, just to name a few:
Nightmare to maintain once customer numbers grow and customizations become more frequent (think of a bigger component with 6 differentiations and 50 customers ...)
for now actually my favorite, but functionality not really disabled, just hidden (of course the back-end checks for permissions, but still more information is transferred to the users then necessary)
works well for the code-part of the components, but would mean to maintain massive amounts of duplicate template-code
I am sure we are not the first to tackle this issue. Am I overseeing any solution with less disadvantages? Are there any code patterns that I could apply here?
edit: after more discussion in our company we realized that there is another important point to this: some customers are hosted on their own servers, but most of them are being served from one central server. This means that the optional features have to detected and added at run-time, which implies some kind of awkwardness.
So our approach is to extend our existing licensing database to also contain the customer specific functionalities, which then obviously only that customer has a license for. Now the easy solution is to have a license endpoint and get all the licenses the customers has acquired, then every optional function can just sit in a simple single *ngIf. I appreciate that this is a simple and clean solution, but it offers the potential to find out some business facts about other customers of our company (by unobfuscating the code and finding additional endpoints etc.pp.). So probably combining this with server-side rendering would be the best solution I can think of right now.
Of course I don't have a clear cut solution that would totally fit your scenario, but here is an idea.
Divide your page into components that act as container regions.
For each customer create a customer configuration that would say
which atomic components goes in each region.
Create atomic components in which each component can be a single function isolated from the rest of the other components. Rely more on services to communicate between them. As an example for this atomic component is the button that create the new export in your example.
Create your page dynamically using ComponentFactory.
I have used the same approach before to customize a design toolbox based on a slide template (like powerpoint slides templates).
As for the options you mentioned, here are my 2 cents:
*ngIf and *ngSwitch, you can eliminate these if u create ur components dynamically and use granular or atomic components.
I don't think this would be a good approach in terms of architecture
and design. You are just manipulating the view css
If you use transclustion, this can minimize your code base if you
can group the components efficiently.
I hope this helps.
I have come across a component in a few web applications; however, the html doesn't identify the component's name. Nor have I found it online. Anyone know what this component type is or where it comes from?
There are a number of frameworks that employ pre-packaged versions of the example image you have posted in your question, all the way from proprietary UI frameworks, such as DevExpress for the .Net Framework, to solutions implemented in a more open-source-friendly manner, i.e. you can see the code.
Without knowing the URL of the web application to which you are refering (e.g. .aspx, etc), it is difficult to know what framework the web app. is employing.
Menu
These menu types are generally called "radial menus" and a good Google would yield lots of great results. Sometimes knowing the terminology is all you need.
Some people have provided some very complex solutions to getting the type of behaviour you are looking for; however, in my opinion, re-inventing the wheel is a waste of time and money (it's great for hobbying around, though, certainly). The amount of time tooling around is perhaps better spent learning a little more about something else that will save you time in the future (and make your solutions re-implementable).
Diagram
Again, these guys are using stuff designed by people who are really passionate about web visual design. GitHub has a number of open source projects available for examination. For the record, I Googled: "circular word occurrence chart". Here is a directly relevant example from that repository mentioned, above.
The substance of my answer? A lot of these things you are seeing are employing more than just HTML and CSS to make their applications display information in such interesting ways.
Standard way of working on new API (library, class, whatever) usually looks like this:
you think about what methods would API user need
you implement API that you suspect user will need
So basically you trying to guess what your API should look like. It very often leads to over engineering stuff, huge APIs that you think user will need and it is very possible that great part of your code won't be used at all.
Some time ago, maybe few years even, I read some article that promoted writing client code first. I don't remember where I found it but author pointed out several advantages like better understanding how API will be used, what it should provide and what is basically obsolete. I think idea was that it goes along with SCRUM methodology and user stories but on implementation level.
Just out of curiosity for my latest private project I started not with actual API (some kind of toolkit library) but with client code that would use this API. Of course my code is all in red because classes, methods and properties does not exist and I can forget about help from intellisense but what I noticed is that after few days of coding my application "has" all basic functionalities and my library API "is" a lot smaller than I imagined when starting a project.
I don't say that if somebody took my library and started using it it wouldn't lack some features but I think it helped me to realize that my idea of this API was somewhat flawed because I usually try to cover all bases and provide methods "just in case". And sometimes it bites me badly because I made some stupid mistake in basic functions being more focused on code that somebody maybe would need.
So what I would like to ask you do you ever tried this approach when needed to create a new API and did it helped you? Is it some recognized technique that has a name?
So basically you're trying to guess what your API should look like.
And that's the biggest problem with designing anything this way: there should be no (well, minimal) guesswork in software design. Designing an API based on assumptions rather than actual information is dangerous, for several reasons:
It's directly counter to the principle of YAGNI: in order to get anything done, you have to assume what the user is going to need, with no information to back up those assumptions.
When you're done, and you finally get around to using your API, you'll invariably find that it sucks to use (poor user experience), because you weren't thinking about how the library is used (UX), you were thinking about what the library must do (features).
An API, by definition, is an interface for users (i.e., developers). Designing as anything else just makes for a bad design, without fail.
Writing sample code is like designing a GUI before writing the backend: a Good Thing. It forces you to think about user experience and practical effects of design decisions without getting bogged down in useless theorising and assumption.
And contrary to Gabriel's answer, this is not bottom-up design: it's top-down. Rather than design the concrete backend of your library and then force an abstract interface on top of it, you first design the interface and then worry about the implementation.
Generally speaking, the idea of designing the concrete first and abstracting from that afterwards is called bottom-up design. Test Driven Development uses similar principle to what you describe to support better design. Firstly you write a test, which is an use of code you are going to write afterwards. It is important to proceed stepwise, because you have to proove the API is implementable. IMportant part of each part is refactoring - this allows you design more concise API and reuse parts of your code.
Which presentation patterns do you think Ext favors or have you successfully used to achieve high testability and also maintainability?
Since Ext component instances usually come tightly coupled with state and some sort of presentation logic (e.g. format validation for text fields), Passive View is not a natural fit. Supervising Presenter seems like it can work (and I've painlessly used it in one occasion). How about the suitability of Presentation Model? Any others?
While this question is specifically for Ext, it can apply to similar frameworks like SmartClient and even RIA technologies like Flex. So, if you have any first-hand pattern experiences with any other web UI technologies, your input would still be appreciated.
When thinking of presentation patterns, this is a great quote:
Separating user interface code from
everything else is a key principle in
well-engineered software. But it’s not
always easy to follow and it leads to
more abstraction in an application
that is hard to understand. Quite a
lot design patterns try to target this
scenario: MVC, MVP, Supervising
Controller, Passive View,
PresentationModel,
Model-View-ViewModel, etc. The reason
for this variety of patterns is that
this problem domain is too big to be
solved by one generic solution.
However, each UI Framework has its own
unique characteristics and so they
work better with some patterns than
with others.
As far as Ext is concerned, in my opinion the closest pattern would be the Model-View-Viewmodel, however this pattern is inherently difficult to code for whilst maintaining the separation of the key tenets (state, view, model).
That said, as per the quote above, each pattern tries to solve/compartmentalise/simplify a problem/situation often too complex for the individual application at hand, or which often fails when you try and take it to its absolute. As such, think about getting a 'best fit' as opposed to an absolute when pattern matching application development.
And remember:
The reason
for this variety of patterns is that
this problem domain is too big to be
solved by one generic solution.
I hope this helps!
2 yeas have passed since this question was aksed and now Ext-JS 4 has a built-in implementation of the MVC pattern. However, instead of an MVP (which I prefer), it favors a straight controller because the views attachment themselves to the models through stores.
Here's the docs on the controller:
http://docs.sencha.com/ext-js/4-1/#!/api/Ext.app.Controller
Nonetheless it can be made to act more like a supervising controller. One nice aspect of Ext-JS is the global application objects ability to act like an event bus for handling controller to controller communication. See this post on how to do that:
http://www.sencha.com/forum/showthread.php?176495-How-to-listen-for-custom-events-fired-in-application
Of course the definitive explanation of all these patterns can be found here:
http://martinfowler.com/eaaDev/uiArchs.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am just dipping my hands into web technologies. I started with HTML and now JavaScript and PHP. I have a variety of questions in my mind. I am a hardcore .NET Windows developer and earn my living with it. But now I want to go deep into Web and so here are my queries:
(1) I started using PHP. I also want to learn Ruby with Rails. Can I learn both side-by-side?
(2) What type of sample projects I can develop to learn well these technologies? I just have in mind to make a web log, that it.
(3) I am using Aptana Studio 2009. It is very good but not the best IDE. Which other IDE can speed up my design time? Any tool that separates the design with business logic automatically?
(4) What other things I must learn to bring myself to the front in web technologies?
Firstly, I applaud the initiative in learning Web technologies. Frankly, going forward, I think programmers will increasingly find it harder to not know Web stuff.
To answer your questions:
I would advise sticking to one at least for awhile. I'd suggest that one be PHP. Why? Ruby on Rails is a language and a framework. I'm a strong advocate of people having some understanding of the underlying technologies, including HTTP, before they throw frameworks on top of it that may confuse or hide issues a developer needs to know about. Stick with vanilla PHP and don't confuse it by throwing something like CodeIgniter, Kohana, Symfony, CakePHP or Zend on top of it;
A blog is a fine learner project. Whatever you pick shouldn't be something terribly complicated, something you can get something out of relatively quickly and something you should be able to add features you want to (you'll be more interested this way);
Jetbrains new Web IDE is coming along nicely. It's what I've switched to. PhpEd, Eclipse PDT and Netbeans all have different merits;
HTMl, CSS and Javascript. Additionally I'd also recommend jQuery.
1) Yes. But it is advisable to pick one technology/web framework and master it. It is easy to get caught in the technology rat race.
2) Think of a problem you have been facing say at workplace. Perhaps there is some routine work that can be done better using a web application. Use that as a project.
4) Read up on basic design principles like layout, color etc. The Non-Designer's design book is a good place to start.
1). I personally would advise you go with Ruby, Java or .NET but stick to one whilst learning, preferably the one closest to he language you know already, which for you means .NET (C#?). I wouldn't recommend PHP under any circumstances but plenty would.
2). Yes, a blog is a good starter project.
3). Just get yourself a good text editor for starters. IDEs make a hash of HTML/CSS/JS which is what you'll be doing a lot of too. But you can stay on the free side by getting a copy of Visual Web Developer Express Edition.
4). Get seriously aware of HTTP, HTML, CSS + JS. In fact don't even think about dynamic pages until you have static pages down solid. Then add dynamic functionality.
Addendum:
From my experience of colleagues who have taken the path you're taking, desktop development teaches you a number of bad habits for web development that you're going to need to unlearn. Specifically: assumptions about state, client vs server, concurrency, and - both most and least serious - inline styling. Bad. Bad. Bad.
A solid understanding of HTTP helps clear some of those, and learning CSS (as an effective way of learning the value of separation of concerns) helps with the latter. Concurrency is something most frameworks will take you 90% of the way with but it's always going to be up to you to think about when and how to apply it.
Given further thought I would ultimately recommend you stay in .NET land (the ASP.NET pipeline model and C# as a whole are solid and mind-blowing respectively) and get yourself express and download ASP.NET MVC extensions for it - the WebForms model is pretty widely reviled by web developers for a reason, but coming from a desktop background it might be more immediate for you. At the expense of settling you into those bad habits I mentioned.
Yes if you're dedicated. If your php is stronger than your RoR familiarity there's a book for you # http://railsforphp.com/ - I would recommend getting more familiar with PHP then jumping to RoR as it's a bit more to learn because of the whole MVC architecture and the language itself is different from most semicolon and braces C-style languages.
The hello world of web programming - a blog.
Personally I use VIM which isn't an IDE, but it's pretty friggin efficient for text editing.
I would recommend often reading Stackoverflow and try to answer some questions while you're learning some new technology, it'll double the rate at which you'll learn if you really force yourself.
You can. I think I would advise
against it.
Blogs are good
places to start. Maybe a photo
gallery?
Eclipse is nice for all
sorts of development.
Like Nike
says, "Just do it" :)
1) This depends on your learning capability, but you really shouldn't. Start with either one, get good at it, then the second one will be much easier to learn.
2) As said before, blogs are a great way to start. You also want to create something like a shopping system to get the grip on good database development.
3) You don't want to create Business Logic alongside the UI. Try learning about templating engines such as Smarty, and your problem will likely vanish instantly. Try Eclipse for an IDE, or better, learn about vim.
4) Discipline. It is incredibly easy to shoot yourself in the foot using PHP and Ruby using crappy code. Dot your is and remember to initialize your variables. Don't just copy code from somewhere, but think of what it does and what could go wrong. Sanitize user input. This takes work, but saves headaches later on.
1) Dont you will just confuse yourself. Learn one after the other both are good!
2) Amazon and Wikipedia are largly php based, I know of a couple of airline booking systems, most blogs are based on one of several freely available php applications.
3) For php/javascript/css I have always gotten by quite happily with good old vim, but thats just me. I would beware of any "framemaker" type GUI html editors as they tend to generate a lot of confusing and unreadable html. Its alright for a static page but when you generate a dynamic page you really need to know what all the html tags are there for.
4) If your serious you really need to learn about cascading style sheets and how to use them properly.
(1) It is all about what you want to do and are you OK with handling new technologies. You can do anything.
(2) What about hello world or simple login application if you are beginner really.
(3) Eclipse always a Best option to think.
(4) CSS, JavaScript, and new JavaScript frame work like prototype,jQuery and more importantly some of the tag library.