I'm currently developing a server side application presenting graphs, stats, reports and so on.
The application is using Highchart library (chart generating library) from Highsoft (Awesome tool!) based in javascript.
If I were to create charts in front end, using highchart is all cool. But problem.. or consideration comes when I were to create charts in back end (server side) with generating report.
Because the nature of Javscript, where it is design for front end (web), if I were to use them in backend, I have to use phantomjs/nodejs.
But if I were to do the same job in serverside languages, such as PHP, I'm certain that it can process/create the charts much faster. (with different charting lib)
Also it is difficult for me to fully rely on stability of using phantomjs/nodejs. (I have seen and experience few issue with running nodejs)
So the question I would like to ask people is that what is the "Performance Difference between processing in back end vs phantomjs/nodejs" under assumption that they do same calculation/computation task in terms of metrics. (eg approximately php is 3 times faster then javascript through phantomjs to do same task.)
As I'm a newbie developer and I need much advice or suggestion before I decide which language to choose before implementing them.
If anyone already have done it, please share the knowledge. It would be greatly appreciated!
Thank you for reading.
-Danny C
The nature of reports is that they need to present correct data and interactivity part is less important, or even impossible.
If you generate report as dedicated URL where user navigates to, use same chart you are using in frontend
If you are generating PDF/Email reports go for stable and (if needed) extendable server side solution, pChart for PHP or some other stable and well documented solution
And remember, people are quite used to idea that chart on reports look different that charts in App/Front end, so don't worry your self too much about that, find something stable, build well documented and maintainable system.
+ extra points if you use some kind of Api/Data provider layer so you can use it for both reports and Frontend, and switch implementation at any point.
Related
I would like to write a 3D application using Golang, my favorite programming language. However, I would prefer not to use native OpenGL directly as the graphical frontend as this would entail a larger learning curve than I'm willing to tolerate. Additionally, I don't really want to use a Golang game engine like go:ngine.
After doing some research I found out about the amazing WebGL Javascript library three.js and I was so intrigued that I completed an introductory Javascript course in a few hours. I'm not really a web developer at all, so I'm wondering how practical it would be for me to write my application primarily in Go but with a three.js frontend.
Some specific questions:
Is it worthwhile / practical to use Javascript/three.js as a frontend to a Golang server like this?
If it is worthwhile, where can I look to learn how to integrate the two cleanly?
If it isn't really worthwhile, which alternatives do I have?
Thanks, any response appreciated.
Edit:
Do you plan to make operations on geometry in Go, possibly in realtime and communicate with your Javascript layer using Websockets?
Yes, this is what I'm thinking now. I'm intending my (Golang) program to generate streams of vertices and triangles based on a few parameters from the user. Each "structure" is generated all at once after the users supply their parameters (which I see as slider bars + input boxes on a Javascript frontend).
Here's an example of something the Go program might generate, plotted in GNUPlot:
(source: alexozer.com)
If this is the case you underestimate Javascript a bit. You should write most of your application in Javascript and use Go as a classical backend service layer like user accounts, persisting state, etc.
I'd be fine with doing that, except for these reasons:
The core generating process fundamentally depends on Goroutines and channels
I know close to nothing about web development, including frontend and backend
So I suppose I'm asking about the implementation details of one of these three possibilities:
Writing most of the program, including the generator, in JS, and a minimal backend in Go
Writing most of the program in Go and using JS just as a graphical frontend
Something else?
I recommend leaving out the whole Websocket aspect because it's only a possible optimization (and maybe not even that).
If you need to depend on Go's concurrency model then go for it, write your component in Go, then a Webserver in Go that takes parameters coming from an HTML request, uses them to compute the result and sends back the data in a JSON format.
On the frontend you will then only focus on sending this request when the user changed a parameter and for displaying of the JSON data you can use ThreeJS right away.
You'll still have to learn a bit of web development and Javascript though. But hey, they say the web is the future ;-)
I think it's the way to go for your case because your application operates in a quite strict request-result way.
The answer to your question depends a lot on where exactly you plan to draw the line between your Go component and the Javascript component. From the way you describe the problem I get the feeling that you want to write most of your application in Go and use JS only as a display layer? I wouldn't recommend doing that.
To rephrase my question: Do you plan to make operations on geometry in Go, possibly in realtime and communicate with your Javascript layer using Websockets? If this is the case you underestimate Javascript a bit. You should write most of your application in Javascript and use Go as a classical backend service layer like user accounts, persisting state, etc.
I might be able to give a more specific answer if I know what exactly you plan to do.
I've been asked at work to convert a popular mechanical engineering excel application to a single page web application. It requires no database so my idea is to put everything on the clientside in javascript.
First version is gonna be pretty small but more complexity will be added further along. Canvas graphics is gonna be drawn in realtime as user changes input. So performance is important. My question is: Should I use a MVC framework such as Angular JS? Or is it better to stick with Jquery? If I should use a MVC, which one is best suited for this app?
Everyone at my company uses IE9 so I dont need any support for older browsers.
Angular bills itself specifically as a way to build CRUD apps - basically database front ends. The app you're describing doesn't sound like it's doing a ton of that, so Angular would probably be more trouble than it's worth.
jQuery is a helper library - it makes dealing with the DOM easier, but doesn't do a thing to provide overall structure to your application. jQuery is a "necessary but not sufficient" in my book - you're going to want it, but it's not enough on its own.
Personally, I'd lean more towards Backbone, specifically because it's so minimal - it gives you some useful data binding stuff and some hints on how to organize your app, then gets out of your way to let you build the abstraction you want. Based on the fact that you mentioned the original is in Excel, some sort of data binding / change notification system is going to be important. This way you can emulate the spreadsheet's "change a cell and the chart redraws" system that everyone's already used to.
In the end it's hard to say without more detail on the app in question, and what kind of calculations / how often they have to happen are. Figure out what your app architecture should be, find (or build) a library that helps implement that architecture. It might be MVCish, it might not.
Well jQuery will get very messy as complexity increases. Angular JS is an amazing library but there are also a myriad of different ones out there. Depending on the Mechanical Engineering principles you are working with using AJAX may prove to be more perform-ant, due to the lack luster power of some older browsers.
It really depends on the complexity of the calculations, but in terms of dealing with events and managin the structure I would suggest using Jquery as well as Angular on top of it. then make the decision about whether or not to move some functions to the server or not, based on performance.
When would one go for using Javascript MVC ? I mean why there was a
need for JS-MVC ?
Is it only because this design pattern was famous in other languages, for code maintenance,readability and many web apps are shipping client side ?
How does it helps a developer, tester and end-user easing their
tasks ?
Any use-case where JS-MVC is suited best and any case where it is
not at all required ?
Question 1,2,4
My view is that you should apply any kind of design pattern only and only if you really need it. Simply because design patterns aren't easy after all. They will add complexity to your solution, but they'll also provide you the benefit of (normally) being established and working solutions for specific kind of problems.
Whether to use or not use them really depends on what you are going to construct and how complex it is. That said, I'm probably not going to structure my 200 lines jQuery plugin using the MVC pattern, maybe...
But at work we create single page applications where we have 2-5 devs working on a project the same time, projects of the amount of 500 days. In such environments things can get complex very quickly and if you don't follow any kind of proper structuring you're lost.
I hope that should answer your question 1 and 2.
For question 3:
The end-user hopefully gets a better quality app with less bugs, but usually he shouldn't even notice (nor does he care) about the underlying architecture of an app.
MVC helps the developer
as an orientation when navigating in the app's source code. Consider an app of 3000 lines of code in a single source file and then when having 4 devs working on it at the same time. A mess, right? When having an MVC app which normally also use routings etc...you normally already know by looking at the route in the url where the corresponding controller lies in the source code and where you should put your hands on
for easier testing. Separation of concerns is always beneficial when applying unit testing practices because you can much easier test your controller because it isn't directly couple to data or presentational stuff (like HTML code etc). And just as a side note, you should definitely unit-test your JavaScript code, definitely!!
maintenance: which is the result of the previous points somehow
I'm not sure which kind of figure you intend by "tester". If he writes automated tests at the unit or acceptance level, then the benefits from before pretty much hold as well. If he's testing the app as a whole in the sense of navigating around, taking the app as a black box by testing its reaction to different kind of inputs, then MVC doesn't really play a big role for him. It's like for the end-user.
So I hope I was able to clarify some things for you. But as said, never just follow a pattern because people follow it but only 'cause it gives you any kind of benefits.
MVC is used to structure your code especially if you are working a lot with client side rendering. Without structure your code gets complex very fast.
User experience for end user is much better when you don't have to wait for the whole page refresh if you only need partial update.
It helps to navigate through the code much faster if you have well defined structure of your code.
JS MVC frameworks are best used where you have complex systems and you want to provide better user experience by using AJAX and partial page reloads or updates. Usually you would not use MVC for Personal website, blogs or stuff like that...
I am currently developing a webapp aimed for mobile devices which basically consists of a couple of long and complex lists, lots of data, collapsible cascading elements.
I'm getting the data to be displayed as XML, now as I see it I have two options:
build the list on the server and send HTML to the client
send XML to the client, build the list with Javascript/jQuery
Not sure which is more efficient, less data to transfer is good, less load on (especially older) phones is also good.
Any other pros/cons I'm not seeing? Suggestions?
The less data you send the better.
I often prefer to make a one-page application. All of the data needed is loaded via AJAX or Web Sockets (check out Socket.IO for a nice wrapper, with compatibility for mobile browsers that don't directly support Web Sockets). That way, you can have a much smoother user experience, and save bandwidth while doing it.
The con with this method is SEO. Search engines won't be running your JavaScript, and therefore won't index any data you are displaying. For "application" like sites, this is typically not a problem. If your site is more content based, then it might be an issue for you. There are ways around this, and progressive enhancement goes a long way to helping the problem. You will need to decide if this is right for you and your situation.
The presentation of Nicholas C. Zakas on velocity 2013 can help you.
Enough with the JavaScript Already. The peroformace or js rendering is very bad, especially for mobile webapp. We have changed the render of data list form js to php in some appliction. You should try to compare the performace or these two ways, and choose the better one. I recommend you do the render of big list in php, just for performce.
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.