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.
Related
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 1 year ago.
Improve this question
I hope this doesn't come off like too strange a question, but I'm relatively new to Django specifically. I currently have a website going using Heroku and Django and I would like to post a bunch of mini-projects and such I make there. One of the ones I want to do is a text-based adventure. I'm relatively proficient in Python and Javascript individually and have built similar things in both, however I'm having trouble thinking how best to translate this into the Django framework.
Currently on my website I have a bunch of pages just for things like articles and written pieces. All of that is working fine and I've even added a mini CMS to the backend and that all works alright. However most of that was either building stuff entirely in backend, or entirely in frontend and then just doing a data linkage. There's no real python code going on in the backend outside of constructing the views and models etc. If I was to build this in Javascript I would likely just hardcode a lot of the writing for a text-based game, likewise with Python, however I feel with Django and a linked Postgres DB there's potential to make it more dynamic and less hard coded using this, but I can't quite figure out which is best.
My question based on this is: should I construct the game entirely in javascript which is just served to the webpage and then update the view using POST requests and a data table, or is there a way to create a python script which integrates with the web page a bit more effectively. I suppose the question is really more is it better to build the game in front-end or back-end, as I can't see a particularly effective way of dividing it across both?
You have to ask yourself about what data does the game needs from the backend (Django and Postgres)? Be clear and specific about what data and when that data need to be in the game frontend (Javascript)?
With that said, one way to approach this is to have the game written in a pure frontend and will be cleaner to be written in javascript. It should focus on the game logic and gameplay.
Seeding Initial Game Data
If you're very clear with what you need on the game (i.e. frontend) during the initial loading, then you can consider feeding all those data during the initial page load. (more detail: https://stackoverflow.com/a/298793/764592)
Subsequent Data
The other data from the backend which cannot be determined after the initial load will have to be requested via XMLHttpRequest to a separate Django views which returns the data only (either in JSON/XML/etc).
In those requests, you need to make sure if the backend logic does the necessary validation as well as the frontend logic. If you find that there is a duplication in the frontend and backend logic, do consider move that logic in the backend, and have the frontend call the backend instead.
Make sure you are clear with the responsibility of each backend and frontend.
The game runs on Javascript, and the backend stored data is validated in the Django.
Note: The above is just one way you can deal with it in a clear separation of responsibility. But if your game is extremely simple, you can even consider do everything in Django level without Javascript. Or Everything in Javascript without Django at all if no database/server logic required.
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 8 years ago.
Improve this question
I am acting as web developer for a small startup, taking over as the only in-house developer to maintain and adapt the application that was initially put together by a team of contractors. I would consider myself to be at an intermediate level with Ruby on Rails. I know enough about front end technologies like HTML and CSS to use Bootstrap or Foundation effectively and write my own tweaks when necessary. However, I only can read the JavaScript code of other developers well enough to make small modifications to what's already in place.
I would like to become proficient in JavaScript to help round out my skillset but there seem to be a lot of JavaScript "options" out there and I'm not sure what's on the way in, what's on the way out, what's popular, what's most useful, easiest to start with, best fit for Rails applications and so forth. And by "options" I mean "regular" Javascript, jQuery, Node, Angular, etc etc.
In hopes that my question will meet SO terms as "answerable" I'd like to focus on the question of what kind of Javascript fits best with Rails and which technologies are the most generally relevant today (i.e. not on the way out of popularity already).
Your choice should depend on what you're doing. One case might be using Rails primarily on the back-end, pulling data from it, and then generating your markup and displaying content primarily on the front-end with JavaScript. In that case, you should look into a JavaScript framework like Ember.js or AngularJS. If you're going to be generating your markup primarily on the back-end with Rails, having that markup being pre-populated with content before being sent to the user, you might be better off using jQuery for DOM manipulation and the occasional AJAX request to your Rails back-end.
In the case you're looking for a framework: Yehuda Katz is a leading voice in the Ruby on Rails core team, and has a similar role inside of the Ember.js project. While this isn't strictly objective, I'd say that Ember is the JavaScript framework that most closely matches "The Rails Way". That said, any framework will integrate well if you're using Rails as a backend, and AngularJS is currently more popular and might be easier if you're looking for examples and helper libraries.
I'd like to point out that Ember is just a framework, just like jQuery is just a library. Knowing JavaScript from the bottom up is a very helpful thing when working with anyone's code. I highly recommend checking out the Learn JavaScript page on MDN, and maybe picking up a copy of JavaScript: the Good Parts by Douglas Crockford. The former has a bunch of free information about getting up to speed on JavaScript. The latter is a dense, and somewhat controversial book, but (in my opinion) is one of the best books about dealing with the language's rough edges.
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 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
Now I don't have any specific question, rather a general, ask for opinions post.
Within a month we will receive the documentation of a project we have to develop. The website has a lot of potential and will be advertised in TV and radio as well when it'll be done. So it'll have a lot of visitors, members and it'll have a rich admin panel with lots of options. My friend who was asked to be the CTO is a senior PHP developer with almost 10 years of experience and I am a junior JS developer. (or less, I don't have years of experiences in JS, but I'm committed)
Is a JS MVC framework substitute for PHP? Is a PHP MVC framework substitute for JS? Are they both working well together or is it possible to not use any framework, but write the project in MVC approach?
For example:
model: PHP
controller: JS (jQuery+Ajax)
view: HTML, CSS
As my friend is a professional PHP developer and will have a daily job next to, but only in the beginning of this project, he doesn't really want to learn an other language (like Node.js), because almost everything is a routine for him now in PHP.
I know everything depends on the documentation and what we have to develop exactly, but I'm just a curious mind and want to understand more. I know I have much to make up and sometimes I worry of my current knowledge, but then I think that be whatever big the challenge, there will always be a solution for it.
MVC does not mean to use differenct languages for all of the modules (model, view, controller), but to loose couple and encapsulate certain parts of your application.
Against many opinions, MVC is not the panacea for application development. It really depends on the application you're developing.
It's not necessary to use any frameworks in order to follow the MVC approach. In fact it's a pattern that can be tied together very quickly, in it's most basic form.
If you decide to use your backend as an API and pull the data via frontend, you don't need to use MVC come hell or high water. For an API for example it's not necessary to perform most of the view tasks. Instead you should care about building a performant and scalable data storage layer (which for example is able to easily provide your data in many common formats, such as XML or JSON) and a strong router that can handle HTTP Requests nicely (See if REST is something for you).
In this case you want a strong frontend which can handle templates, and also has a strong layer for obtaining, sending and handling data in general. A strong controller layer that can delegate tasks to certain parts of your application would also come in handy.
Well you see what I'm talking about. It really depends on your application. In my example the backend wouldn't exactly follow the MVC approach, while my frontend would completely. MVC isn't about switching programming languages for certain parts of your application. Instead it decouples your application structure making things a lot easier.
Of course Frameworks come in handy when developing such an enterprise scale application, but it's not necessarily required.
To sum things up: MVC has not much to do with the code itself, it has much more to do with architecture and structure of your code. How exactely you're implementing it is absolutely up to you.
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.