It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
The Single Page Application (SPA) has come to us. A lot of new things come with it as well, like Routing, Page life cycle at client side, MVC pattern, MVVM pattern, MV* pattern,... and some of Javascript patterns also come to us like AMD pattern, Singleton, Facade,..
A lot of SPA frameworks and libraries also were developed. We can find out some of its on the internet. They are AngularJs, Reactjs, BackboneJs, DurandalJs,.. and a lot of third party components to make the Javascript coding more easy like RequireJs, Amplifyjs, BreezeJs...
But I just think why do we need the SPA? Because it's seen to be introducing some of new complex things in developing the web application. Inspite of the SPA, we can use the traditional web application, each request each loading page. I just see a benefit like we can be easy to run it on the mobile and adapt with a new web application development trend. Could somebody explain more clearly about that?
One more thing, if we use a lot of third party components to composition just one SPA. So does it make a consistency for this web application? I think it should make a complex for maintain a huge components inside our web application. How do you think about that?
All suggestions are welcome.
I believe that this is the direction most websites should be moving in considering the number of devices that users utilize today, and the abilities and limitations of each.
IMPORTANT:
Before reading the rest of this, please understand that this concept is built on the foundation of basic principles of designing for the web. In order to design a single page application for all devices and situations, it cannot be run exclusively as a single page application. You must build a foundation that will work on the most basic of browsers with highly limited features and enhancing the user's experience according to their device's capabilities.
This may cause more work for you, but you will be capable of satisfying a larger and more diverse audience, which is much more impressive than throwing together a web app built only for modern desktop or phone browsers specifically.
Decrease load time and/or weight
Single page applications are more capable of decreasing load time of pages and the amount of data transfer from server to client.
Some of the most heavily impacting features of this method include :
storing any global functionality once it is loaded the first time,
allowing easier data transfer between pages and a more complex user interface
removing the cost of loading a whole page after a postback when you only need specific components
Increased chance of over complicating
This design method may allow for laziness in the developer and more interference from an end user. As a developer, be sure that your UI does it's job (get, display and submit to server) and that the server does it's job (provide, validate and submit to database). Most end users won't attempt to break your system using the information in a javascript file, but including information about your data structure is asking for trouble in my opinion.
Start with a strong architecture!
As with any webpage, the processing of data can be moved directly into service handlers instead of pages which could result in an architecture utilizing the following layers:
Database (Data Storage)
BL (Data Handling and Transport)
User Interface (Data Display and User Interaction)
Services over page handling
In my opinion using services is pretty much a requirement for organized and modulated code in a website. The standard get and post methods used in backwards compatible website can also use these services to hit services representing business objects instead of pages. This allows your code to be more generalized across modules concerning the same objects.
The update to a single page application then becomes simplistic in that you can initialize any UI to pick up the get or post methods and perform them using AJAX methods instead of causing a postback for events, thus a single page instance.
A side effect of using these services to handle UI events is that you eliminate the need for event handling in a code behind file except for life cycle events. The life cycle events are useful for handling and modifying relevant data to display based on the situation as well as modifying the returned html to lighten the load on the user's device.
Deferred Loading!
Any complex website will come with complex modules and plenty of unique components.
A benefit you gain from using a single page application is that you have the option to deffer the load time to an ajax process and do so whenever you like for any part of your application (i.e. first attempt to use a module, dead time after initial page load, etc), making the initial load faster and the processing time more controlled.
My list of best practices
As for best practices.. there are quite a few optimizations that could and should be made to a design intending to use this method, such as :
storing information as it comes, obliterating when no longer relevant
loading in script, html and js files through ajax only when needed
using data loaded on one page in another if it can be instead of reloading for each new "page"
minimalist data structure for the UI since it is a means for displaying and not for processing.
don't obsess with validation on the UI because your services should already be built to validate any information submitted to it
These optimizations are helpful with load time, data handling and object associations. Obviously this is not a complete list, but it is a great head start to building you single page application.
Finally, I would suggest researching concepts for designing for one web to help build a solid foundation. After that, the rest is relatively simple enhancements. (TIP: One of those enhancements is to catch all actions resulting in a postback and use the information to build a asynchronous call instead).
There is all sorts of information on this, and all sorts of libraries to use, but I would suggest using your own code as much as possible for the basic functionality and to get into the library code that solves your issues and do some research instead of trying to implement a complex system with generic library code. Using their code as an example may lead to a smaller overhead and stronger code for your specific situation.
Good Luck!
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have been searching about few details of HTML5 application but finding it hard or may be i am not searching in the right way. Basically i want to understand the new way of creating an application using HTML5 and CSS3 which will provide an experience of native application. Followings are my doubt.
How to navigate page by page. In typical web application every page is requested to the server and server will load the new page in browser with a refresh. In modern approch what is the way to do page navigation without page refresh effect.
In a typical web application a dynamic web programming such as asp.net, JSP are used to generate HTML files in browser. What is the modern approch do we still need to use the same way or plain static HTML files can be used and can be modified by jquery.
How the client server communication has to done so that page refresh does not happens. Can we use jquery for all the communication. Will it too much work for browsers.
How the HTML5 files are hosted. In server or each client has to have a copy of HTML files locally.
Any resources explaining this would be great.
The question is very generic, but I will attempt to answer it.
1. HTML5 is just a new version of HTML which is still under draft according to w3.org. HTML5 is still HTML and HTML navigates to other pages by requesting a fresh copy of the next page from the server, which the server actively responds. This will however flush the existing page from the browser and the new page is brought in. ( And yeah when the same page is requested again, either a cached copy in the browser is displayed or a new request is sent to the server and all the contents,tiny or huge, are reloaded). This is the reload part. However, you can use asynchronous services that AJAX has to offer using which you can request part of a html page.
Ajax is a group of interrelated web development techniques used
on the client-side to create asynchronous web applications. With Ajax,
web applications can send data to, and retrieve data from, a server
asynchronously (in the background) without interfering with the
display and behavior of the existing page.
2. Static pages are rarely used these days. However, if the site does not have too many user specific components or if the site only has static data to put in, then static pages are helpful, because loading the javascript stuff can be avoided. But then again, all modern web pages are dynamic.
There are a lots of ways of putting dynamic content on the web like
the Model View Controller approach and Event Based approaches.
And just to give you an idea, the new look is the one page look where all the content in the site is displayed in one single page and there are multiple controllers that feed various parts of the page and all of it is combined into a view.
Have a look here .
3. There are a lot of new js options these days with node.js and angular.js being the latest additions. Node.js is an excellent option if you want your site completely powered on javascript, however not many hosting sites support node.js yet. However, right now javascript seems to be the future.
4. This question is huge one, owing to the sheer lack of research from your point. Because, hosting and having copies are two different things because other than the hosting site and your client(that is the browser) there are lot of other servers which are put reasonably close to the client to serve pages on the fly, so that the file is brought quickly to the browser.
So, in a sense a lot of websites which have huge number of hits have
layers of fast cached servers upon slow back-end servers to serve
requests quickly. Then there are also fast cached database servers
upon huge slower ones.
So, what I want to stress here is that this is a purely performance related decision that YOU have to take. So, if there is something you want to achieve, whether it be speed or anything else, there are a lot of options to explore.
Coming to the CSS3 part, animations part of CSS3 is still to be accepted globally. There are still users all over the world who have browsers unable to process CSS3D transitions( users using older versions of IE etc). So thats about it.
That said, these things are purely related to performance and HTML5 or CSS3 for that matter have no part to play here.
Check out jQuery Mobile!
Basically jqm and other web mobile frameworks use Ajax to avoid any page refresh, with nice animations as a bonus.
This is more of a matter of how you want to pull data into your web app, from a server? then yes, it's gonna be an ajax request, and yes you will have to insert that into your html page, but again this doesn't mean your whole page has to come from a server. You can basically have a three tier setup, server, middleman, and your frontend. your middle part will have your html templates for your "pages" and will insert the incoming data from the server, and your front end will process and make everything happen. it can be like a php/angular or jquery setup, or php/handlebars/jquery or javascript setup, there are many others. Your page navigation again depends sort of on your framework setup.
Again kinda like the above. Routing is the most common way of communicating to a server these days. YOu basically requests data through different routes to the server and then process the incoming data -json perhaps- in whatever template engine you want to present to your end user. For routing, php solutions are the most popular, like slim or symfony.
Jquery is totally fine, angular is said to be much faster these days. Handlebars is excellent for creating template pages. Angular combines, qjuery, handlebars and some other stuff all in one. Backbone.js another good one.
THis is an odd question or tells me that you need to research some more about the whole concept. But think of in terms of frameworks and MVC type models.
I understand you require a single page HTML 5 app, For page navigations you can use Jquery mobile.It implements it via ajax.If you require the experience of native application.(In mobile devices JQM can be a little slow)You would require to make some performance improvements in jquery mobile, like removing unused widgets,unused themes,using clever javascript for minimal page reflow etc.
For such apps,for code maintainability we require the use of javascript frameworks like backbone js,knockout js etc(You have a wide variety of MVVM frameworks to choose from).
For client server communication you can make AJAX calls.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Background
I need to create a potentially very large HTML/JS mobile web app that will be delivered as a mobile web site and natively using Phonegap. I'm currently working to determine the best way to organize the app itself.
The basic plan is to have many modules that will each focus on a different subject of interest . Some of these modules will be very basic (ie, announcements / news) and some will be very complex (ie, sports: team players, schedules, video, etc). There will be a side-drawer navigation that will apply to most pages so users can quickly navigate to a different module. There needs to be the ability to deep-link within modules. These modules will be created by a variety of developers and vendors.
Single Page App
Most of the mobile solutions I see involve Single Pages, which seem like a bad idea to me in this case, since there is the potential for so much memory use. It also seems like it would be difficult to reconcile hash navigation between modules and hash navigation between section within modules. Module development would have to be done with the app framework in mind and limits how things can be done by vendors and developers. On the other hand, things aren't getting loaded as often and everything can easily communicate with each other.
Multiple Page App
Using multiple pages, it seems like each module could easily be created in whatever technology a vendor was comfortable with (and could do quickly and cheaply). It would cut down on memory use, but also remove the ability for modules to communicate (a feature that I don't know is necessary for us at this point). I could see making a javascript library every module would use for common handling of various events (like logging errors, navigation, etc). Each app navigation between modules would be a new page call, resetting the DOM. Each module could use a single page design if it wished.
Help Me Please
So, is there any common or new knowledge about how things like this should be designed? I'm eager to begin work, but don't want to be rewriting things that may already exist. Do I have any glaring flaws in my reasoning? I'd love to hear from anyone that has insight.
Honestly, if you are considering building any app that you believe will be high volume and of high complexity, you really ought to consider doing native development, or at least use something like Appcelerator where the application will be "compiled" down to native code for better performance. If you are intending to just let any number of developers build their own javascript components that may or may not do a good job of managing limited system resources, so are going to quickly run into application performance issues.
On the other hand, if you are just going for proof of concept and don't mind potentially having to greatly refactor your application architecture when and if you get a sufficient level of complexity, then you may want to simply go with the web app approach.
Really, you need to also be considering your backend service architecture as much or more than the frontend architecture. that is really where you are going to run into problems down the line in trying to integrate offerings from other developers.
I had a similar architectural problem to contend with a couple of years ago. It wasn't mobile, but it wasn't entirely web-based either. The target applications were a mix of web sites and desktop apps, with the potential to go mobile in the future.
The interesting part was that there had been two prior attempts at creating a framework that could be used in a variety of situations. The problem, and the reason both attempts failed, was that the developers saw it as a UX problem space. They approached it using several different technologies, but became mired months down the road because they had made assumptions up front and flown the project by the seat of their pants.
My approach was to eschew all the UI discussion completely and focus on a backend architecture that could be approached from any standpoint. To this end, I created a web service that had data going in both directions, and was ultimately serving a mathematical model. The service is being accessed from a variety of sources using different technologies: Flash, Unity, a Google Earth plugin, and finally, from an unrelated web architecture serving up good ol' HTML.
My advice to you, is don't concentrate on the front-end mapping so much as get your back-end right. Once you have a data structure in place, you can build outward, and several issues such as memory management, monolithic app or not, i.e. one page versus many, will almost resolve themselves. Work on creating a great API with lots of good interfaces and you won't fall into a "many chefs" hole. Give a bunch of dispersed developers enough rope, on the other hand, and you'll never find where all the knots are!
The decision whether to ultimately go native API over HTML5-based technology such as Sencha Touch, jQuery Mobile, or Phonegap is an evangelical black hole that will be played out over the coming months and years. Native apps may be more fluid and speedy in some cases, but the investment in resources is something that should be considered. On the other hand, JavaScript developers are lurking around every corner and are not in short supply.
Your first step is to nail down those requirements.
If you're doing this for yourself or for your own company, then nail down how these modules (co-)operate.
If you are doing this for your employer, then somebody there ought to have a clue what they want to see, otherwise, how are you going to build it?
A solution which supports multiple pages, opening and closing modules with no communication is going to require different things than a framework which is responsible for maintaining multiple widgets at the same time, which may or may not communicate through system-calls or services.
There's no way around that -- building services/sandboxing/etc for modules is going to take more work than treating each like a page-change (or making them be literal page-changes).
When you figure out what you want your program to do, start building out an idea of the API you'd like other people to have.
Are you going to provide them with an API for building UI components, or are you going to leave that to their own whims?
Personally, I'd avoid a situation where each module change just replaces iFrames, and then the end-user can do whatever they want in there.
Likewise, I'd avoid situations where you're allowing module-creators to run whatever they'd like in a non-sandboxed environment... It ends poorly for your end-users (or you, in UK court).
But that's not a concern, yet.
First-concern is what does your platform do.
Then figure out what your back-end communication is going to look like, and what interfaces you're going to provide to module creators, and how you're going to get data from your end to theirs (http-based API, REST or whatever else... ...but work it out WELL, if you don't already have it).
THEN, when you know what your platform is expected to do, AND you have a backend which can serve all kinds of tasks well, figure out what services you're going to provide to content-creators, to make their widgets, and to upload/download data from your service, and sandbox, and the like.
I've been investigating a few of the JavaScript frameworks such as Backbone.js and Batman.js for a while and whilst I really like them, I have one niggling thing that I keep coming back to. That issue is accessibility.
As a web developer I've always tried to make my websites and applications with accessibility in mind, especially using the idea of progressive enhancement.
Clearly out of the box these new JS frameworks don't gracefully degrade, so I was wondering what are other developers thoughts on this issue and what are you doing about it. After all the accessibility of a website / app isn't really an optional thing as it's part of the law in many countries.
Maybe I'm just being overly zealous on this subject, and not appreciating how far things have come in terms of accessibility.
I use a js-framework (spine.js in my case) in my latest site. Still I make sure that non-js browsers (certainly not over zealous: think SEO) can navigate my site and digest the contents.
As an example I'm going with a search-page with products being shown. Products can be paged, filtered, sorted. Of course this is an example of the generalized idea.
PREREQ: use a template-engine that can both render server-side and client-side. (I use Mustache) . This makes sure you can render models without js- through server-side templating, and render models with js through client-side templating.
Initially: render the products using server-side mustache-template. Also include a 'bootstrapJSON'-object which contains the same products in JSON-format.
Initially: all links (product-detail page, paging, sorting, filtering) are real server-side urls (no hashbang urls)
The end-result is a page which can be navigated 100% with paging, sorting, filtering without the use of JS.
all paging,sorting, filtering urls result in a request to the server, which in turn results in a new set of products being rendered. Nothing special here.
JS-enabled - on domload:
fetch the bootstrapJSON and make product-models from it (use your js-framework features to do this) .
Afterwards rerender the products using the same mustache-template but now doing it client-side. (Again using your js-framework).
Visually nothing should change (after all server-side and client-side rendering was done on same models, with same template), but at least now there's a binding between the client-side model and the view.
transform urls to hashbang-urls. (e.g: /products/#sort-price-asc ) and use your js-framework features to wire the events.
now every (filtering, paging, sorting ) url should result in a client-side state-change, which would probably result in your js-framework doing an ajax-request to the server to return new products (in JSON-format) . Rerendering this again on the client should result in your updated view.
The logic part of the code to handle the ajax-request in 6. on the server-side is 100% identical to the code used in 4. Differentiate between an ajax-call and an ordinary request and spit out the products in JSON or html (using mustache server-side) respectively.
EDIT: UPDTATE JAN 2013
Since this question/answer is getting some reasonable traction I thought I'd share some closely-related aha-moments of the last year:
Spitting out JSON and rendering it client-side with your client-side mvc of choice (steps 6. and 7. above) can be pretty costly cpu-wise. This, of course, is especially apparent on mobile-devices.
I've done some testing to return html-snippets on ajax (using server-side mustache-template rendering) instead of doing the same on the client-side as suggested in my answer above. Depending on your client-device it can be up to 10 times faster (1000ms -> 100ms) , of course your mileage may vary. (practically no code changes needed, since step 7. could already do both)
Of course, when no JSON is returned there's no way for a client-side MVC to build models, manage events, etc. So why keep a clientside MVC at all? To be honest, with even very complex searchpages in hindsight I don't have much use for client-side mvc's at all. The only real benefit to me is that they help to clearly separate out logic on the client, but you should already be doing that on your own imho. Consequently, stripping out client-side MVC is on the todo.
Oh yeah, I traded in Mustache with Hogan (same syntax, a bit more functionality, but most of all extremely performant!) Was able to do so because I switched the backend from java to Node.js (which rocks imho)
Since I'm a visually-impaired user and web developer, I'll chime in here.
These frameworks, in my experience, haven't been a problem provided the appropriate steps are taken with regard to accessibility.
Many screen readers understand JavaScript, and we as developers can improve the experience using things like HTML5's aria-live attribute to alert screen readers that things are changing, and we can use the role attribute to provide additional hints to the screenreaders.
However, the basic principle of web development with JavaScript is that we should develop the underlying site first, without JavaScript, and then use that solid, working, and tested foundation to provide better features. The use of JS should not be required to purchase a product, receive services, or get information. And some users disable JavaScript because it interferes with the way their screenreaders work.
Doing a complete Backbone.js or Knockout site from the ground up without regard for accessibility will result in something akin to "new Twitter" which fails extremely hard with many screenreaders. But Twitter has a solid foundation and so we can use other means to access the platform. Grafting Backbone onto an existing site that has a well-crafted API is quite doable, and an awful lot of fun, too.
So basically, these frameworks themselves are no more of an accessibility issue than jQUery itself - the developer needs to craft a user experience that works for everyone.
Any webpage that requires javascript in order to get the content out of it will likely be met with accessibility-related challenges. The accessibility of JavaScript frameworks is definitely an issue of contention, though really, any web application suffers drawbacks when content is provided dynamically, regardless of the framework used.
There's no silver bullet to ensure your site will be accessible, and I certainly can't account for every JavaScript framework. Here's a few thoughts about how you can prevent your site from being totally inaccessible when using JavaScript:
Follow the guidelines from WCAG 2.0 on client-side scripting, and WCAG 2.0 in general.
Avoid frameworks that require you generate the page's UI, controls and/or content entirely through javascript such as Uki.js, or ones that use their own proprietary markup, like Jo. The closer you can stick with static(-ish), semantic HTML content, the better off you'll be.
Consider using ARIA roles such as role="application" and the aria-live attribute to indicate the areas of your page which are dynamic. More and more aria roles are being supported by assistive devices as time goes by, so using these aria attributes makes sense when you can add them to your app appropriately.
In terms of JS libraries, check their source and see if they output any aria roles. They might not be perfectly accessible, but it would demonstrate they're considering assistive devices.
Wherever possible, treat JavaScript as an enhancement rather than a necessity. Try to provide alternative methods or workflows to accessing the important information that don't require dynamic page updates.
Test and validate your app with your users! Do some user testing sessions with people who use assistive devices or have other difficulties using web software. Nothing will help you prove your site is accessible more than watching real people use it.
The last point is the most important, though many try to escape it. Regardless of the technology, the fact remains that you're developing an application that people will use. No machine or theory will ever be able to perfectly validate your application as being usable, but you're not building it for machines anyway. Right? :)
Chris Blouch (AOL) and Hans Hillen (TPG) had a good presentation on this regarding jQuery, including the work they do in reviewing for accessibility. Making Rich Internet Applications Accessible Through JQuery That and another related presentation on Accessibility of HTML5 and Rich Internet Applications (http://www.paciellogroup.com/training/CSUN2012/) should be of interest to you.
My money is on choosing the most accessible framework: jQuery provides a great deal of graceful degradation or progressive enhancement fallback as well as an overall pretty good focus on accessibility. Also, indirectly I help test and review several systems that leverage jQuery (Drupal public and Intranet websites) such that defects found for accessibility are found and routed back to the project for fixes.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
Original Question: Is it a bad idea to make an all JavaScript website?
*Changed the question because this ended up being more of a discussion, but it could be helpful for others.*
In this case, I was thinking of making a website that initially delivers its overall layout using regular HTML (like a normal, basic web page), but then I plan to fill the content of the HTML content area dynamically, entirely with AJAX requests.
Users of the site won't ever be refreshing the page or going to a new page, and all other divs and elements that need to be generated will be created using AJAX (making use of lots of JavaScript functions that are on a cached external JavaScript page).
Although I'm not actually making a forum website, a forum's level of functionality is close to what I want to achieve. Lots of database reading and writing too.
Is this a bad idea? Am I not considering something that could make this potentially terrible? Is it good performance-wise (since I'll be doing so much client-side work and less server side work)?
I realize that the page wouldn't work for people who have JavaScript turned off, but that's not a concern in this case. I'm also not worrying about any mobile devices that don't support JavaScript, since I would probably just create a mobile-specific version of the site that doesn't use JavaScript).
Thanks!
UPDATE:
First: Thank you for all the responses, everyone! I really appreciate it!
Just for clarification purposes, I thought this would be a good idea mostly because it seemed like I could just say, "Hey AJAX, just give me the raw forum post data for this page and I'll do all of the HTML building on the client side." Same DB access of course, but less server side page formatting work and less data transfer to the client.
And another important clarification: I'm not worried about search engine optimization because this forum would be a login-only network that should not be crawled or viewed by non-logged-in users.
Not a crazy idea at all, but I recommend against it since it'd be hard to maintain. You just got to know what you're getting in to. Facebook does something similar. The Google search interface, for example, also keeps you on the same page when you perform a search.
You might also be interested in:
Backbone.js
http://documentcloud.github.com/backbone/
and BBQ (Back Button Query)
http://benalman.com/code/projects/jquery-bbq/docs/files/jquery-ba-bbq-js.html
One disadvantage is that analytics scripts won't necessarily work properly on sites built this way, depending how you build them.
Edit:
One concern is that it won't be search engine crawlable. This can be overcome if you build the site well, probably using BBQ, and by following this spec:
http://code.google.com/web/ajaxcrawling/docs/specification.html
Couple of years back, that'd be an absolute NO. But now with the newer browsers, libraries like jQuery, YUI things can be reconsidered.
Disclaimer: I'm not saying an absolute YES.
Rather, it requires careful evaluation of your requirements, user experience expectations, performance levels etc.
If your primary user base is using IE6/7 or even 8, the page speed is going to be significantly slower than FF or Chrome. There are certain cases where you've to resort to server side rendering.
The list could go on an on but you're the best judge here (unless you can be more specific with your requirements).
Recently we rolled out a JS intensive website for a major news corporation. However, to keep it performant, we also leverage server side caching and few other techniques in conjunction with client side JS.
No, it's not a bad idea in and of itself, particularly if you don't care about support for browsers that don't have JavaScript enabled, but it does carry some caveats. For instance you'll need to put a fair bit of effort into working out how your JavaScript framework should be structured, and what tools you will use. If you don't come up with a solid solution then your website code can quickly degenerate into an unmaintainable mess. You'll also be spending a lot more time doing cross-browser testing, as the same JavaScript code may produce different behavior in different browsers (thanks mostly to IE).
As far as performance is concerned, you really aren't doing any less server-side work. The expensive server-side operations are your database queries, and you have to do those regardless of whether the server is returning a standalone web page or an AJAX (or JSON) snippet. In fact, depending upon how you structure your JavaScript client you could end up doing more work. For instance, if the JavaScript sends a separate AJAX request for each div on a page, that will be less efficient overall than allowing the server to create the content for all of the divs on the page as part of a single operation.
Its a good idea, but lets see what could be some troubling points
what i can think of:
The web site wont be Crawlable by any
Search Engines.
the SOURCE CODE of your Web site can
be Easily stolen, and everyone will
be able to enjoy on your hard work.
Pages Cannot be Liked in Facebook
(facebook needs OG Tags)
Hard to track analytics
Yes, it is. You should always provide a non-javascript fallback site for search engines and people with old browsers.
Preamble
So, this question has already been answered, but as it was my first question for this project, I'm going to continue to reference it in other questions I ask for this project.
For anyone who came from another question, here is the basic idea: Create a web app that can make it much easier to create other web applications or websites. To do this, you would basically create a modular site with "widgets" and then combine them into the final display pages. Each widget would likely have its own set of functions combined in a Class if you use Prototype or .prototype.fn otherwise.
Currently
I am working on getting the basics down: editing CSS, creating user JavaScript functions and dynamically finding their names/inputs, and other critical technical aspects of the project. Soon I will create a rough timeline of the features I wish to create. Soon after I do this, I intent to create a Blog of sorts to keep everyone informed of the project's status.
Original Question
Hello all, I am currently trying to formalize an idea I have for a personal project (which may turn into a professional one later on). The concept is a reflective web application. In other words, a web application that can build other web applications and is actively used to build and improve itself. Think of it as sort of a webapp IDE for creating webapps.
So before I start explaining it further, my question to all of you is this: What do you think would be some of the hardest challenges along the way and where would be the best place to start?
Now let me try to explain some of the aspects of this concept briefly here. I want this application to be as close to a WYSIWYG as possible, in that you have a display area which shows all or part of the website as it would appear. You should be free to browse it to get to the areas you want to work on and use a JavaScript debugger/console to ask "what would happen if...?" questions.
I intend for the webapps to be built up via components. In other words, the result would be a very modular webapp so that you can tweak things on a small or large scale with a fair amount of ease (generally it should be better than hand coding everything in <insert editor of choice>).
Once the website/webapp is done, this webapp should be able to produce all the code necessary to install and run the created website/webapp (so CSS, JavaScript, PHP, and PHP installer for the database).
Here are the few major challenges I've come up with so far:
Changing CSS on the fly
Implementing reflection in JavaScript
Accurate and brief DOM tree viewer
Allowing users to choose JavaScript libraries (i.e. Prototype, jQuery, Dojo, extJS, etc.)
Any other comments and suggestions are also welcome.
Edit 1: I really like the idea of AppJet and I will check it out in detail when I get the time this weekend. However, my only concern is that this is supposed to create code that can go onto others webservers, so while AppJet might be a great way for me to develop this app more rapidly, I still think I will have to generate PHP code for my users to put on their servers.
Also, when I feel this is ready for beta testers, I will certainly release it for free for everyone on this site. But I was thinking that out of beta I should follow a scheme similar to that of git: Free for open source apps, costs money for private/proprietary apps.
Conceptually, you would be building widgets, a widget factory, and a factory making factory.
So, you would have to find all the different types of interactions that could be possible in making a widget, between widgets, within a factory, and between multiple widget making factories to get an idea.
Something to keep on top of how far would be too far to abstract?
**I think you would need to be able to abstract a few layers completely for the application space itself. Then you'd have to build some management tool for it all. **
- Presentation, Workflow and the Data tier.
Presentation: You are either receiving feedback, or putting in input. Usually as a result of clicking, or entering something. A simple example is making dynamic web forms in a database. What would you have to store in a database about where it comes/goes from? This would probably make up the presentation layer. This would probably be the best exercise to start with to get a feel for what you may need to go with.
Workflow: it would be wise to build a simple workflow engine. I built one modeled on Windows Workflow that I had up and running in 2 days. It could set the initial event that should be run, etc. From a designer perspective, I would imagine a visio type program to link these events. The events in the workflow would then drive the presentation tier.
Data: You would have to store the data about the application as much as the data in the application. So, form, event, data structures could possibly be done by storing xml docs depending on whether you need to work with any of the data in the forms or not. The data of the application could also be stored in empty xml templates that you fill in, or in actual tables. At that point you'd have to create a table creation routine that would maintain a table for an app to the spec. Google has something like this with their google DB online.
Hope that helps. Share what you end up coming up with.
Why use PHP?
Appjet does something really similar using 100% Javascript on the client and server side with rhino.
This makes it easier for programmers to use your service, and easier for you to deploy. In fact even their data storage technique uses Javascript (simple native objects), which is a really powerful idea.