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 9 years ago.
Improve this question
I always read something like HTML5 games etc. But I don't believe that a game is entirely programmed in HTML5 because it is just a markup language. Normally, it is controlled though JavaScript, right?
I want to program a very very simple browser game, that I can play with my friends. But I want to code the logic in Scala.
So I came up with this structure.
The client is able to see HTML in his browser. HTML5 will be manipulated though JavaScript which opens a connection to my webserver (AJAX?). Now I can program all my logic in Scala and let JavaScript execute it (for example move pawn from position a to position b).
This would be possible, right?
As a webserver I would choose Lift.
But I have never done any rendering with JS/HTML5. Would you recommend to look in some frameworks such as LimeJs or CraftyJs?
"HTML5" is commonly used as an all-encompassing reference to a set of specifications for client-side scripting language APIs, in addition to the core markup language that gave rise to the "ML" part in the name. So "implement this-or-that in HTML5" generally means something like do it in client-side Javascript, manipulating a DOM tree as specificied by HTML5 in order to present a user interface.
It is somewhat inconsistent/illogical naming, but standardizing on inconsistent illogical terminology is what this industry is best at. :-)
http://en.wikipedia.org/wiki/HTML5
HTML5 is a markup language for structuring and presenting content for the World Wide Web, and is a core technology of the Internet originally proposed by Opera Software.[2] It is the fifth revision of the HTML standard ... a mixture of features introduced by various specifications, ... software products such as web browsers, ... common practice, and the many syntax errors in existing web documents. It is also an attempt to define a single markup language that can be written in either HTML or XHTML syntax
HTML5 on its own cannot be used for animation and interactivity - it must be supplemented with CSS3 or Javascript
Sticking with your example developers typically define an API to access your data via your web server.
Javascript would be responsible for manipulating your view (html dom), so it would actually contain a big chunck of your game logic
webserver would contain your data model (maybe it would have logic for a robot player and its next move)
client is the browser
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 5 years ago.
Improve this question
So recently I have come across a site known as "negafinity", I had looked at it as a normal site, until someone told me that the site was programmed using just JavaScript (presumed they had looked at their .js files).
Site URL: https://negafinity.com/
So, is there any benefit in programming your website in full JavaScript? Rather than just programming it in plain HTML, CSS & JavaScript.
If there is, what are the benefits? And what are the disadvantages?
EDIT: To not make it so broad, I am looking for these main factors:
Website Loading
Programming Time
Caching
Though, I am also on the look out for other benefits/disadvantages so please state them if you feel they are necessary!
When an entire site is created solely with JavaScript, it is most likely because the final HTML and CSS (created by the JavaScript) will always need to be different based on certain conditions.
Those conditions could be something that can only be determined by what the situation is at the server.
Or, it could be based on the type or version of the client that is making the initial request (this would allow for the JavaScript to create proprietary HTML and/or CSS, but only when a certain kind of client makes the request).
Many sites rely heavily on content coming from databases (eBay is a very good example of this) and those sites will often just employ JavaScript to contact the server and get all the information needed and then construct the page based on smaller HTML templates.
In short, it allows for the entire page to be dynamically generated based on current conditions.
However, from a performance standpoint, it would be slower for pages to load this way than to have static HTML and CSS at least for the bulk of the page structure. It would most likely take considerably more time to code the page and less content would be cached.
With today's modern standards like CSS3 Media Queries, page content can be conditionally shown. And with AJAX, portions of a page can be conditionally generated as needed, rather than the entire page being built that way.
I don't think so. There's a reason why most sites use HTML or PHP with javascript.
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 7 years ago.
Improve this question
I am new to front end development. Let's say hypothetically my clients have modern hardware, 2.20 GHz CPU, 4GB ram. A flashy website that uses a lot of event handlers, and animations like "slide for div containers to move in and out on users click" and "jquery "on" click for mustache templates created on the fly with ajax (for elements being added after initial DOM load).
I know it depends if my programming skills are really terrible which could be causing the user end to perform really poorly, but lets say I program as close to efficient as possible, and use very well written plug-ins.
Question - Do clients with that hardware handle a highly customized design well? Are browser development tools the best out there in terms of troubleshooting and analyzing performance, or is there a highly popular widely used tool that does the job for a lot of developers?
My question focuses on two key points.
Client Side Performance based on sleek and flashy websites using
plugins mentioned below on modern hardware.
What do developers use to help them check hardware utilization,
profile and troubleshoot issues.
browser development tools is sufficient?
A popular tool widley used by developers that I haven't discovered?
Additional Notes
I am also using my application server to host these files since I am using MVC so its not completely static html files. Plugins include:
Jquery
BootstrapJS
Bootstrap Max Length
Jquery UI(Effects Corewith Slidejs, its 14Kb in size)
Jquery Uniform
MustacheJS
Jquery Uniform took the biggest hit on page load times I called it on about 100 elements when the page loaded. So I changed it by calling it on elements that needed it when the client clicks on a div to slide open on specific selectors.
What influenced my question?
Toying around and reading about Angularjs. Since everything is client side, I read mixed feelings on it slowing the client down and possibly speeding it up. Since I am already knee deep in Jquery I was curious how well it performs with the more modern hardware using a lot of flashy components and DOM manipulation that I mentioned above. This is my first front end design, so I know more seasoned Front End Developers know how well browsers handle these knew frameworks being used.
Why it's important
The temptation to add all the glitter and flashiness to a webpage to make it look more attractive to the client, could actually work against me is a concern.
In my experience you can have hundred of thousands of DOM elements, thousands of objects with arrays inside and nothing happens. In the web are many awful sites made up like Frankenstein's monsters with literally dozens of libraries and have not performance problems in computers from 15 years ago.
While you don't mess with 3d rendering and that experimental things you won't have problems in mainstream PCs. I don't know what your flashy cool features are. Also if you are very bad programming and make almost never-ending loops or something like that could be a problem, but that's anywhere.
Another problem is the download time, and is the most important thing to care about, if you have tons of code it will take longer to download. Usually in server applications you prefer performance before lightness but in the front end is better to download small files. Internet always will be slower than the CPU and RAM.
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 8 years ago.
Improve this question
I'm trying to catch up with modern Web application design approaches. With the latest technologies, is it still appropriate or necessary to tie a web application to a specific backend language like PHP, ASP.NET or J2EE?
I've been thinking of HTML5, JavaScript and asynchronous queries. An application could potentially consist of a series of simple, empty HTML document templates where the data components are filled in after the page load event using JQuery/XMLHttpRequest calls to a web service.
In this context, the backend web service could be implemented using any arbitrary framework and the serving of HTML pages could be handle by any web server. The application's web component would then be purely HTML5 and JavaScript with all other business logic hidden behind a web service interface.
But is this an effective design for complex applications which rely on session management and page transitions? Does anyone code this way or are traditional backend languages always used to generate the HTML documents?
Thanks.
Interesting question, I view it as this way. HTML5 is no longer HTML5.. but "HTML". We'll never see an HTML6, the new HTML5 model will continue to be improved upon and have features added to it. Some day, the days of needing third party plugins for video, audio and drawing, all devices will share the same front end presentation model.
When you think of it, frameworks like PHP just make dynamic HTML, and marry business logic with presentation logic. For the forseeable future, couldn't we always have a need for something like that? That being said, I can certainly see numerous applications in the future that leverage open data and rich client side controls. I don't think this threatens the extinction of ASP.NET, PHP or J2EE.. I think it enhances them, as now we all have a more fuller toolbox to develop with.
Scott Hanselman gave an awesome presentation 2 years ago at Microsoft's Build conference (http://channel9.msdn.com/Events/Build/2012/3-027), it's a great discussion on how JavaScript makes the web browser an incredible emulator, and that you can now front load logic and programming onto the end user... similar to what you are thinking. In the end, I think options like this just allow us to make sure that we use the tools for the appropriate reasons, just like in the ASP.NET world we now have Web Forms and MVC.. Web Forms aren't dead, they're just not the only game in town anymore, but now we can use Web Forms when appropriate, and MVC when appropriate.
Great question!
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 9 years ago.
Improve this question
I've always been told it's good practice (ala 'unobtrusive javascript') separate JavaScript from HTML markup. However, I've been seeing the opposite trend with a number of new and popular frameworks such as Bootstrap, Angular.js, and Ember.js. Can someone tell me why this isn't considered bad practice?
Unobtrusive Javascript is a good practice for many places on the web. The frameworks you mentioned are often used for creating full-blown Javascript applications. In many of these apps, the experience without Javascript is often a blank page. In that environment, the value of separating your markup from Javascript is relatively low.
I'm asking the same question myself and have come to the following conclusion:
HTML is markup language for presenting documents. The semantics that everyone is referring all around is actually related to representing rich documents. This includes images and links that allow more richer experience.
The same principles can be applied to Word documents, where instead of marking a specific text as red, you can mark it as emphasis and then style the emphasis as red, which will be semantically correct way to express the intend.
The problem arises because HTML actually includes elements that allow user interaction - forms . The initial design was to allow non professionals to create simple interactive UIs. When I checked different desktop GUI frameworks there is no such thing as separation between actual view and view logic, because when you build GUI you don't need that separation.
For me the importance is how much of what you writing is content based or GUI based. Because the HTML serves two purposes it's difficult to know what to serve from the server.
Basically sites like Wikipedia, and even Stackoverflow are content oriented. This means that if they want to be accessible to broader range of clients, like bots and older browsers they should be able to stream pure html.
I'm thinking of two possible strategies when you want to provide content and some richer UI experience, like the textare where I'm writing this comment. The one is to server the html and then initialize the GUI. This is also referred as unobtrusive javascript and semantical HTML. This is what most content oriented sites do. This is mostly to be able to benefit from browsers and bots that will allow their content to be more accessible.
The other strategy will be to identify the type of client and serve different content, which can only be achieved reliably only on the client side, because in both cases html will be served. This is still close to the first stategy, because of the way HTML is used/abused as both content and GUI representation.
If you are writing an application that don't provide content but actual service/process then architecture like AngularJS and similar is suited better.
In my experience most business have to provide both. Let's say you have an app that uses HTML/Javascript to allow users to create drawings. This app doesn't need to follow any unobtrusive guidelines, but it won't be able to run on old browsers too. But if you provide a social sharing of the drawings between users, allowing comments and other content then it's better to write this part of the site in a way that bots and other clients can access the content easily.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm in the process of building and designing my first Javascript OOP web application and I'm wondering what kind of data structure / management system would be best to use. I know the interaction between Javascript and XML is good and fairly easy, but XML isn't meant to be used as a database.
Is it better to form a combination of both? Have a server-side language (PHP) generate XML and have it then be read by JS?
Or am I heading in the wrong direction with this?
Javascript itself doesn't do queries....it needs a helper like PHP, .net, or Java. It can traverse XML or JSON just fine like you say, but sending colossal XML documents with all possible data when only small amounts of the data is actually required will lead to massive overhead that will bring your app to its knees. It's the definition of lack-of-scalability.
My personal preference is JQuery Ajax talking to a PHP backend (transactions via JSON). If I'm dealing with the presentation of large datasets I'll always page the information server-side and pipeline it (load data ahead of and behind the current view to reduce transactions), and usually present in via jQuery DataTables. Grids are always your friend with large amounts of data. Again, personal preference, but I make heavy use of jQuery UI for layout and presentation, and I do write custom Javascript for the "nifty" one-off type things that come up. Again, any server language you have access to and are comfortable with will suffice, as Javascript is language agnostic.
Javascript can get out of hand in a hurry. I'd recommend that unless you have a ton of time on your hands that you focus on clean presentation via something baseline like HTML with judicious use of Javascript and CSS for progressive enhancement. Think about the user before you go crazy with motion, dynamic elements, etc. Don't forget the old adage, "80% of the people only use 20% of the functionality" Nail that 20% cleanly before going to town on flashy javascript fluff. Your users will thank you!
JSON is by far the fastest to parse, since it IS JavaScript.
Application frameworks like EXT.JS are already doing this with great success.