I am trying to figure out which widget development platform is superior. I want a cross-browser widget and so I a thought either the Google or Yahoo solution will be best. They both seem to be using the same technologies - JavaScript, HTML, XML, etc.
Any thoughts on which is a better platfrom in terms of development, performance and any other unmentioned factors?
Personally I've seen a presentation from Christain Heilmann a Yahoo Developer Evangelist, and what Yahoo are doing with widgets, especially putting a framework in place so you can install widgets onto Yahoo's homepage is pretty cool. I'd recommend to look at Yahoo's stuff further go to their developer network. Also Christian's talk availible here, I would say gives a good overview of it.
Yahoo Widgets doesn't really "use HTML". They have an object (Web) that you can use to embed an HTML page, but you usually don't make widgets with HTML.
It's also not possible to make the Web object transparent, so it will be an ugly rectangle on your widget :)
Related
I am interested in taking up a learning path which would include web application development using Dashboard Admin UI Kits such as these Link to example
What application and or languages are used when implementing such a
UI ?
What databases are to be used in the backend?
For the UI:
Languages are always the same: HTML, CSS, JavaScript. Yet, they have countless libraries.
For CSS, I would check Bootstrap (or Bulma if you want slightly less pain), which is a simpler but richer one compared to many others.
For JS, I would check some animation libraries (there are many), and probably not start with any JS framework such as React, Angular etc. They might come later once you feel comfortable with JavaScript.
For HTML, you already have dashboard kit already. Though a great idea for learning, but as far as I know using templates is not a common practice for bigger companies etc.
For the backend:
It really depends on what you want to focus more on. Programming languages have advantages and disadvantages. You can work with (almost) any language but increasingly more popular ones are Node.js, Django (Python's popular web framework) etc. For beginning, these two are nice options. Node.js is also closely related to JavaScript, so that is a big plus.
For the database:
You might want to check if you need relational data or not, because that might narrow down your options. MongoDB is easy to learn and to get the basics of backend programming, while SQL (PostgreSQL is a nice example) is a widely preferred SQL option one in the industry.
When should one develop HATEOAS server RESTful API instead of using HTML (resource links, forms, etc.)?
Isn't HTML and a browser good enough as hypermedia engine?
Isn't HTML and a browser good enough as hypermedia engine?
HTML + HTTP + URI + Browser === The world wide web. So it's pretty good, no joke.
It's not without fault.
HTML's understanding of links is disappointingly limited. No support for idempotent writes. Uri Template support for GET only. I'm not super keen on how many different spellings there are for "link".
It's kind of verbose for a hypermedia format; don't get me wrong - built in text markup is brilliant when you are trying to document what is going on for a human being. But my impression thus far is that same structure starts to get in the way when as a human being you want to quickly review the semantic content that your automated agent is consuming.
I call your attention to this quote from RFC-4287
The primary use case that Atom addresses is the syndication of Web content such as weblogs and news headlines to Web sites as well as directly to user agents.
So a bunch of really smart guys, specifically trying to address use cases directly related to the web, decided to invest a bunch of effort into standardizing a new hypermedia format rather than using the one that was already ubiquitous in their problem domain.
And over the past 10+ years, that format has been widely adopted.
Without adoption, I'm not sure that HATEOAS has much benefit. You don't need a hypermedia api if you are controlling both sides of the conversation (example: javascript on the web -- hypermedia with code on demand capability downloading a client that has learned the protocol of a web api via some out of band channel).
Evidence would seem to suggest that HTML is not nearly as convenient a format as, for example, any of the JSON based hypermedia formats.
In conclusion: no, it's not good enough. It might be an acceptable place holder for the moment; but the JSON hypermedia tool sets are soon going to be sufficiently mature that HTML will be seen as a giant step in the wrong direction.
I'm brand new to web technologies, and in researching a web app that I want to create I got a little bogged down. I want to be able to use a Google Map on my site, including the functionality that allows you to use layers and draw shapes and lines on top of it, but I'm confused at the difference between the Google Maps API and Google Maps Engine and which one would best suit me.
Is one of those a better option for me? There seems to be a lot of red tape on getting Maps Engine for a site, but I'm unclear on if Maps API has all the functionality I'd want.
Sorry for the beginner question, but I haven't found any sort of FAQ that's addressed this. I'd really appreciate any insight. Thanks!
So Google actually offers three different products.
Google Maps JavaScript API is intended for developers, and it lets you take Google's base maps and draw on them programmatically by writing your own JavaScript that calls the API.
Google Maps Engine is for creating your own base maps. You could use it to render shapes and lines on top of a map, but if that's all you want to do, it's probably overkill (and it's not free).
Google Maps Engine Lite is the new boy in town, and it's still beta as I type this, but it might fit your use case the best: you can draw by hand on top of Google's standard maps, import a variety of formats with geo data, and then share your results or embed them on your website, all without having to write a lick of JavaScript.
It all depends on how comfortable you are with coding. Google Maps API requires the application to be built in JavaScript.
As Google Maps Engine has now been shelved by Google I would suggest taking a look at MangoMap. It allows maps to be built using only an interface, you can built really powerful web ma applications without writing a single line of code.
Disclaimer: I'm the CEO of MangoMap ;-)
With Google Maps API, Google supplies a blank map and you add points, line, polygons, etc. to the map via JavaScript. This is great until you start having to add thousands of map objects.
With Google Maps Engine, (now deprecated), you upload, store, and process the geometry data on Google's servers for optimal rendering. You can turn a large group of points and lines into image files with transparent backgrounds which can display quickly on a map.
I'd like to add a map of countries to my website where the user can choose a specific country by clicking on it. http://code.google.com/apis/chart/docs/gallery/map_charts.html has the looks i want, but it's not possible to underlay the countries with links, afaik(Besides lacking pan/zoom, nice to have). The interactive map(Geo Map) allows more options but it's based on flash which i'd like to avoid(Not sure if links would be possible anyway).
I've played with shapefiles/polylines and google-maps but thats too complex(Lots of data for the polylines, far too much for the simple functionality i need).
Do you know of alternatives which are similarly easy to implement as the google-api-options?
Thx
Christian
I would, if I may, suggest to check out Highmaps, from the people behind Highcharts (myself included). It's 100% Javascript based, and designed to get you up and going with very little effort. You can easily implement your own click-based events.
Highmaps is free for non-commercial use, works great with mobile browsers (full touch support) and old IE down to IE6. It also has support for advanced dynamic features like drilldown and rich tooltips, and is very customizable.
We supply a map collection with over 350 maps, to get you started quickly. The maps are optimized for size to keep things lightweight.
So I've been looking into the different mapping API's out there, and I've narrowed it down to Google Maps API and MapQuest's API. I'm leaning towards the MapQuest API for:
Unlimited queries
Support for draggable routes. Google's API allows multiple way points, which is not the same thing.
The draggable routes is a pretty important feature for what I'm working on, but am I missing any big reasons to avoid MapQuest's API? Some caveat in the EULA perhaps? The draggable route support sucks in practice?
It's kind of a late answer, but I ended up using the Mapquest API because they work better as small maps, and don't look quite as cluttered, especially after I extracted the zoom control from the map and implemented it via jQuery UI Slider.
I thought it was rather intuitive and easy to use. If I'm just looking up directions somewhere, I still always opt for Google Maps. If I need to build an API map, especially to fit smaller dimensions, MapQuest seems to do the trick.
If you need to actually PAY for their HTTPS services (e.g. you need to use their maps BEHIND a password protected site), it costs less with Mapquest
Are you sure Google Maps doesn't support draggable routes? There are plenty of times I've accidentally dragged a planned route when using the website, throwing everything off. Not sure about the API though.
As accuracy goes I've noticed that for directions here in North Carolina, MapQuest is slightly more accurate. Google doesn't always map addresses to the right position. MapQuest and Google use different data providers in some places. Google uses a variety of data, and in some places the providers will be the same (NAVTEQ and Tele Atlas).
Otherwise it is largely user preference: I rarely do see sites though that don't use Google Maps. Microsoft seems to force their projects to use Bing for some reason ;)