Related
Question background:
Hello everyone, I have been developing windows form application for my employer for about 3 years. Though most of my works are amateurish. I've been using visual studio, c#, enjoying creating re-usable windows form controls by sub-classing and other techniques. Now my boss want me to make website for this company, the first thinking in my mind is to create re-usable WEB controls just like windors form application.
The methods I have tried
Web User Control, At very first, I found visual studio support developer to create Web User Control, with file extension as *.ascx. I was very exciting to find this because I thought I can create Web controls just like I did in windows form application development. BUT, it's a very big "BUT", I then found that it cannot be embed to assembly file (DLL), and either can it be displayed in ToolBox to support drag and drop in web page design time. AFAIK from msdn, the Web User Control is not intended to be re-used across projects. So I give up this method.
Server Control, then I found there is Custom Server Control can be created to support assembly embed and ToolBox. It's a *.cs file that written with a class which sub-classing from System.Web.UI.WebControls.WebControl or System.Web.UI.WebControls.CompositeControl. Good point is that this is exactly what I want: re-usability and design-time support. HOWEVER, the huge disadvantage is that it doesn't support drag-drop when creating the web control itself. The control can only be rendered by html written in c# or be created by code. And I have to embed css/javascript to the control if I want to create more beautiful, complicated or efficient control. Anyway, from MSDN, Server Control is what I need.
Pure HTML, Javascript (jQuery), CSS, actually I've beening working with Server Control method for a while, just in order to make my boss happy. But I still cannot stop thinking about other better solutions. From my understanding, web page is not that complicated, it's simply constructed (please correct me if I'm wrong) by HTML tag, javascript (or other scripting language), CSS to manipulate UI. So I believe if I create web control by pure Html, Javascript and CSS, it will be of course more complicated but more compatible. Because Server Control solution requires the web server support .Net Framework, which is not free and limited to Microsoft scope. If I have a way to get rid of .Net, why NOT? I'm willing to spend double-time to create Re-Usable control if it's worthy to do. For example, if I want to turn to PHP to create web page, I might have to acquire the technique to create my web control simply by HTML, Javascript and CSS.
My question
Speaking all of the above, is it even possible to create my web control library only based on Html, Javascript and CSS?
If so, is there any tutorial about this method?
I really would like to know that how does commercial/professional company create web page.
Thank you everyone, any advice will be very much appreciated!
Speaking all of the above, is it even possible to create my web control library only based on Html, Javascript and CSS?
In strict speak, the controls you have become accustomed to support the aforementioned. This will continue work in future projects created in WebForms.
However, if you foray into MVC then there is a striking difference. Most of the controls that handle input are client side (which can be wrapped in js wigets and user validation classes). On the other hand there is very little server controls, however there are _MasterLayouts and Views that can make use of PartialViews a PartialView is similar to a Web User Control. In your Controller you can return EditTemplates and other types that would be similar to Server Controls
After digging for a few days, I almost give up creating my own javascript library not just only for web widget(UI), neither I would like to use third-part js frameworks because:
Cost too much time: as it says: 'do not reinvent the wheel', well, I accept/disagree with this point half by half. But now, I simply do not have too much time on it. It really really cost time, can hardly complish by an individual person.
A lot javascript frameworks are so great, like dojo, yui, jqui, as #dandavis commented, BUT, the usage of some is difficult, at least for me (as a js beginner), especially dojo. Dojo is very powerful, AFAIK, but it's hard to implement and use. I followed official tutorial to create my own web widget, spend a hour and not get it done. I might give up too fast?
I still want to dig asp.net with ajax, it is much powerful. And can easily manipulate on server side.
Well, I don't know if it's an answer but this is my personal end of my question. Thanks a lot guys.
So I have this project I'm working on and I'm trying to build the website part of my project. I have experience with Flash AS3, but not so much or none with JavaScript. My co-workers are telling me that they are almost the same and you can just build the site in JavaScript. But people can have JavaScript turned off, and not everyone uses Flash.
I'm having difficulty knowing what to use to build my website...by the way, this website is generally an application. It's going to have a menu with features and stuff. I figured I can probably do HTML and PHP, but there's some features I need that will be dynamic. I really want this site to be available to as many people as possible.
The only reason (again) why I would use flash is because I've used it before and it's easy to design with animations and junk.
I could use some advice.
This is my personal opinion, but if you can meet the needs of your application with HTML and Javascript, you will probably be much better off. Your application will not require Flash, will likely load faster, will work better on mobile devices and will work on iDevices which do not support Flash at all.
That said, there are some challenges to building some types of applications in HTML and Javascript, particularly if you need to work across a wide range of browsers. Using a popular library like jQuery or YUI can help with a lot of that cross browser compatibility, but some capabilities are only available in the more modern browsers.
On the opposite end of things, some things can be done better in Flash than in HTML (particularly in old browsers).
So ... the answer is that, it depends on the needs of your application. If it were me, I'd build it in HTML and Javascript unless I found a reason that I couldn't make a successful application that way.
As for computers with Javascript off, it's my opinion that those computers are not doing modern things on the web anyway and would not likely be customers of anything I'd build on the web. Google has dropped support for computers without javascript and some old browsers from some of their apps because the cost of development for those cases is way higher than the benefit from the few customers you might gain by it. Whether that logic applies to your application obviously depends upon what you're doing and who it would appeal to.
If you looking to use javascript, there is jquery which is very easy to use and very rich in functioanlity. There is also extjs which is also easy and functionality rich but its not free for commercial use.
If you are new to javascript and already know java, you can use Google web toolkit where you write the code in java and the toolkit compiles that into a javascript. But this depends on how much server functionality you have.
IF the website is a simple one, you can probably use jquery, html and css.
If its a commercial project I would use Flash because You're good at it and You will build the app faster.
If You want to take a fascinating journey with the most popular language and develop Your skills then use javascript.
Flash and javascript are both very popular. For both methods You can use a fallback if the technology is not available.
If You decide to use javascript consider using backbone.js. It's a great MVC library.
Often I need to refer to code written in HTML/JavaScript/CSS, but it is a very awkward construction to constantly refer to the descriptive trio of 'HTML/JavaScript/CSS' code.
for example, Mozilla refers to its HTML/JavaScript/CSS JetPack code as 'a JetPack'.
Other than the defunct 'dHTML', what are some concise, generic and accurate terms I can use to collectively refer to applications written in HTML/JavaScript/CSS.
I'm going to have to say DHTML anyway. Why would you say it's "defunct"? It is the perfect answer to this question. See http://en.wikipedia.org/wiki/DHTML. DHTML means Dynamic HTML—which is exactly what the combination of HTML/JavaScript/CSS code is.
Unless you're dealing with someone who isn't impressed with terms that are less than a year or two old, or unless you aren't specifically talking about code, DHTML conveys exactly what you are talking about.
Web application is perhaps too loose of a term, but it's a start.
Let's break it down.
HTML is data, CSS is presentation, and JavaScript is code. These are web technologies.
These are usually brought together by a browser.
Something in a browser on the web is a website.
JavaScript suggests it is somewhat interactive, so it's not just a site, it's an application.
("Application" also suggests that it's more complex, like with a SQL backend or something, so you might sound even more talented. :)
I'm guessing that you had the term LAMP (Linux, Apache, MySQL, and PHP) in mind? To my knowledge there is no such abbreviation for HTML, CSS, and JavaScript. The easiest way to say it is to just say it.
Versus "Front end" – I think that term implies that you built something that customers used. "Web application" is nonspecific about who the users are, so it would apply to customer-facing applications as well as internal-use applications. The word "application" implies that it's not just a tool; there are users who are not the programmers. "Front end" is probably more impressive because a customer-facing application has to be nicer than an internal one.
If you are not using it in a browser, or it's not actually on the web, maybe just your intranet or an internally distributed application bundle, it's still an application developed with web technologies.
Given that the person you're trying to convey this message to knows you're talking about web-related stuff - Front-end or Front-end development has always worked for me.
"HTML5" is the answer I now believe to be correct to replace "HTML/JavaScript/CSS". Since I asked the question in January, HTML5 has gained a lot more recognition for its incredible capabilities and promise. "HTML5" also has significantly greater name recognition than 7 months ago, and clearly sets it apart from lesser HTML.
I think the reason there's no specific term is the same reason that dHTML fell into disrepute - all three scripts are so integral to frontend development that there ceases to be a need to refer to them specifically. If you code in HTML, you almost necessarily use CSS, and if you have any active content at all it will most probably be in JavaScript.
Frontend development is a bit vague, but something like HTML based frontend development should get your point across.
If you want to refer to an application - use Web Application.
And if you need to refer to some code - use simple JS (JavaScript) because most of your code (except for some ie css expressions if you use it) will be in JS, isn't it?
Web Suite
suite: a set of things belonging together, in particular.
thus you have:
Web Suite: the set of HTML/CSS/JavaScript, the basic technologies used to develop a web site or application.
example:
"I used the Web Suite to make a cool website to show off all my pictures of cats sitting in boxes."
"UX" (User Experience) or "Front-end Development."
Web Applications, and Web 2.0 are both big names. One name/acronym that I personally like to use is RIA, or Rich Internet Application. From the article:
Rich Internet Applications (RIAs) are
web applications that have most of the
characteristics of desktop
applications, typically delivered
either by way of a standards based web
browser, via a browser plug-in, or
independently via sandboxes or virtual
machines.1 Examples of RIA
frameworks include Ajax, Curl, GWT,
Adobe Flash/Adobe Flex/AIR,
Java/JavaFX,[2] Mozilla's XUL,
OpenLaszlo and Microsoft
Silverlight.[3]
Also, someone else mentioned "impressing the suits," which this title tends to do. After all, it's got "rich" right in the name ;)
Web code
I was just having to write "HTML/Javascript/CSS" in an email and thought, "Isn't there a better term for this?". Googling, I found this post. I'm going with "web code".
Some call it a JAM stack, which stands for Javascript, API and Markup. But I acknowledge that it's not as specific as LAMP or something like that.
https://en.wikipedia.org/wiki/Solution_stack
https://jamstack.org/
However uncool it might be, it is still DHTML to me.
They are standard web technologies for producing dynamic websites and web applications. The last thing we need is another vacuous moniker for something that is more than adequately described by DHTML.
An Alternative to this Source or Page Source.
The Context all depends but for me this seemed to be a good name. When I right-click and I see "view page source" it seems relevant. it contains all of this HTML/CSS/JS.
I like Web Application but my use case was page-specific, not app-wide.
I've been calling this the web stack (HTML, CSS, JavaScript). Exclude frameworks or other tools, just the base technologies of what the web is made.
I come from the Microsoft world (and I come in peace). I want to rapidly prototype a web app and if it works out, take it live - and I don't want to use ASP.Net.
I am not sure which web application toolkit to use though. Should I use GWT, DOJO...other recommendations? I am open to any server-side language but am looking at RoR, Php or even Java (J2EE to be precise). I am not much of a Javascript/CSS guy so a toolkit that might make it relatively easy on me on those fronts would be preferable.
Also, I am a mac user at home. What IDEs go along with the framework you would recommend?
Any recommendations guys?
If you're open to doing Java, GWT is the way to go. It allows you to have a relatively uniform codebase across client-server, and to only use one language on both.
There are some limitations to doing very off-the-beaten-path AJAXy things (which GWT makes difficult, but not impossible), but it doesn't sound like that's your use case anyway.
GWT will allow you to scale up by using more of its features as your app gets more complex - and your prototype won't be throwaway code.
If you want to write the front and back end in JAVA, and want to do complex ajax type thing, then GWT is a great way to go.
The easiest way to think about it is that building a GWT app is kind of like building a JAVA swing application that hooks into a server. Just like a swing app that uses a server you can make it fat or thin. When you're done it all compiles down into HTML and javascript, and has very good modern browser support (ie6+ ff, opera, safari).
It does abstract all the javascript and HTML away, but if you want it to look good you'll still need to understand CSS.
I think anyone who says that that it ruins MVC or that it's a muddying of client vs server doesn't understand GWT. GWT is a CLIENT side framework. And it is only used on the CLIENT. GWT does provide an RPC mechanism to hook it into JAVA (and other) back ends, but that's just a communication protocol, it doesn't mean that your server code magically becomes your client code. Sure you can write a whole bunch of business rules into your UI if you really wanted to, but you can do this with any framework, so it would be silly to say that GWT is somehow different in that respect.
GWT is a good choice, while if you choose more powerful JavaScript framework based on GWT (e.g. SmartGWT), the compiled stuff is too heavyweight.
Choose direct JavaScript if you need a compact project.
I am a fan of GWT, however I am very familiar with Java. I found it to be intuitive, and surprisingly easy to get good results quickly. If you are to use GWT, then you'll definitely want to use the free, and immensely powerful Eclipse IDE.
One disadvantage of GWT is that it requires Javascript to be supported by the browser, there is no "graceful degradation".
We have evaluate a large list of frameworks and have decide us for Echo2.
You need only to code in Java. Javascript you need only if you want write your own components.
There are no startup performance problems with large projects like GWT.
You can use the full range of Java in your client code because it run on the server. In GWT you can use only very small set of Java classes.
The IDE for Java is Eclipse. This is independent of the used framework.
I'm a fan of jQuery, the chainability of actions, traversals, and commands is really powerful. A good friend of mine is crazy about Mootools, he works at a Java shop FWIW. He mentioned a cool feature of Mootools is that you can specify the functionality you want the framework to include and it will generate the entire library on a single line in a file that you can include on your page to minimize the weight of the framework (pretty cool feature). Really it just depends on what you are most comfortable with. jQuery has great tutorials, is super fast, and can be used along with other javascript frameworks.
Not related to GWT, but have you considered other backends that GWT could work nicely with?
Grails is one backend that ties quite nicely with GWT.
Personally, I would avoid server-side frameworks that try to embed or hide the client-side framework. I'm sure that GWT is great for getting something going quickly, and is probably fine for certain kinds of applications, but you'll probably run into lots of problems "on the edges" for more complex applications. Decoupling the client framework from the server-side framework avoids those problems.
With the increased power of JavaScript frameworks like YUI, JQuery, and Prototype, and debugging tools like Firebug, doing an application entirely in browser-side JavaScript looks like a great way to make simple applications like puzzle games and specialized calculators.
Is there any downside to this other than exposing your source code? How should you handle data storage for this kind of program?
Edit: yes, Gears and cookies can be used for local storage, but you can't easily get access to files and other objects the user already has around. You also can't save data to a file for a user without having them invoke some browser feature like printing to PDF or saving page as a file.
I've written several application in JS including a spreadsheet.
Upside:
great language
short code-run-review cycle
DOM manipulation is great for UI design
clients on every computer (and phone)
Downside:
differences between browsers (especially IE)
code base scalability (with no intrinsic support for namespaces and classes)
no good debuggers (especially, again, for IE)
performance (even though great progress has been made with FireFox and Safari)
You need to write some server code as well.
Bottom line: Go for it. I did.
Another option for developing simple desktop like applications or games in JavaScript is Adobe AIR. You can build your app code in either HTML + JavaScript or using Flash/Flex or a combination of both. It has the advantage of being cross-platform (actually cross-platform, Linux, OS X, and Windows. Not just Windows and OS X).
Heck, it may be the only time in your career as a developer that you can write a web page and ONLY target ONE browser.
SproutCore is a wholly JavaScript-hosted application framework, borrowing concepts particularly from Cocoa (such as KVO) and Ruby on Rails (such as using a CLI generator for your models, views and controllers). It includes Prototype, but builds plenty of stuff such as sophisticated controls on top of that. Its Photos demo is arguably impressive (especially in Safari 3.1).
Greg already pointed you to Gears; in addition, HTML 5 will come with a standardized means of local storage. Safari 3.1 ships with an implementation where you have a per-site SQLite database with user-settable size maximums, as well as a built-in database browser with SQL querying. Unfortunately, it will be a long time until we can expect broad browser support. Until then, Gears is indeed an alternative (but not for Safari… yet!). For simpler storage, there is of course always cookies.
The downside to this would be that you are at the mercy of them having js enabled. I'm not sure that this is a big deal now. Virtually every browser supports js and has it enabled by default.
Of course the other downside would be performance. You are again at the mercy of the client handling all the intensive work. This also may not be that big of a deal, and would be dependent on the type of app you are building.
I've never used Gears, but it looks like it is worth a shot. The backup plan would be to run some server side script through ajax that dumps your data somewhere.
Not completely client side, but oh well.
Nihilogic (not my site) does a lot of stuff with Javascript. They even have several games that they've made in Javascript.
I've also seen a neat roguelike game made in Javascript. Unfortunately, I can't remember what it was called...
If you want to write a standalone JavaScript application, look at XULrunner. It's what Firefox is built on, but it is also built so that you can distribute it as an application runtime. You will write some of the interface in JavaScript and use JavaScript for your code.
Gears might provide the client-side persistent data storage you need. There isn't a terribly good way of not exposing your source code, though. You could obfuscate it but that only helps somewhat.
I've done simple apps like this for stuff like a Sudoku solver.
You might run into performance issues given that you're completely at the mercy of the client's Javascript interpreter. Gears would be a nice way of data storage, but I don't think it has penetrated the market that much. You could just use cookies if you're not fussy about that kind of thing.
I'm with ScottKoon here, Adobe AIR is great. I've really only made one really nice (imho) widget thus far, but I did so using jQuery and Prototype.js, which floored in such wonderful ways because I didn't have to learn a whole new event model. Adobe AIR is really sweet, the memory foot print isn't too bad, upgrading to a new version is built into AIR so it's almost automatic, and best of all it's cross-platform...they even have an alpha-version for Linux, but it works pretty well already on my Eee.
Standalone games in GWT:
http://gpokr.com/
http://kdice.com/
In regard to saving files from a javascript application:
I am really excited about the possibilities of client-side applications. Flash 10 introduced the ability to create files for save right in the browser. I thought it was super cool, so I built a javascript+flash component to wrap the saving feature. Right now it only works for creating text based files (vcard, ical, xml, html, css, etc.)
Downloadify Home Page
Source Code & Documentation on Github
See It In Use at Starter for jQuery
I am looking to add support for non-text files soon, but this is a start.
My RSS feeds have served me well- I found that Javascript roguelike!
It's called The Tombs of Asciiroth.
Given that you're going to be writing some server code anyway, it makes sense to keep storage on the server for a lot of domains (address books, poker scores, gui configuration, etc.,.) For anything the size of what you'll get in Webkit or Gears, you can probably also keep it on your server.
The advantage of keeping it on your server is two-fold:
You can integrate it fairly simply as a Model layer in a typical MVC framework, and,
Users get a consistent view without being tied to their browser/PC, or in a less-than-ideal environment (Internet Cafés).
The server code for handling this can also be fairly trivial, particularly if it's written with this task in mind, so it's not a huge cognitive burden.
Go with qooxdoo. They recently realsed 1.0, although most users of it say it was ripe for 1.0 at least two versions ago.
I compared qooxdoo with YUI and ext, and I think qooxdoo is the way to go for programmers - YUI isn't that polished as qooxdoo, from a programmer's point of view and ext has a not so friendly licensing model.
A few of the strong points (for me) of qooxdoo are:
extremely clean code
the nicest OO programming model I've seen among Javascript frameworks
an extremely rich UI widget library
It also features a test runner for unit tests, an API doc generator and reader, a logging facility, and several useful features for debugging, grouped under something called Inspector.
The only downside is that there aren't readymade themes (something like skins) for qooxdoo. But creating your own theme is quite easy.