I want to introduce a class to mobile development. In the past, the long installation process for using things like phonegap deterred many from completing the assignment, so this time I want to keep things as simple as possible.
My preferred languages are javascript, css, and html. I know I can create a mobile version of a website using these languages, but that would go through a web browser. Is it possible to build an app purely using these languages and install it on a phone, with an icon and everything?
You should look into jQuery mobile. It's a HTML5 Javascript library for easy app creation: http://jquerymobile.com/ It should be good for students to use for assignments.
Related
We are attempting to write a LOB application for a medical device. We expect the application to grow upto > 50k lines of code with a complex state machine, business logic and UI rendering. The choices are
Electron or NW.js using NodeJS, HTML5, CSS3, Angular2, TypeScript
QT
WPF
We have lot of internal javascript libraries and developers skilled with javascript. So our preference is to reuse as much as possible and go with option 1. Is option 1, mature enough to support developing complex desktop applications.
Which would be your preference if you are starting today.
HTML5, CSS3, Angular2, TypeScript For Rich Native (desktop) applications
...
medical device
For what it's worth, this terrifies me. I hope any critical functionality is being handled elsewhere. If anything, because I do not trust anyone to audit all of the code you're about to dump into this and the code of the browser engine that's going to run it.
Is option 1, mature enough to support developing complex desktop applications.
Yes, of course. People do this every day.
We have lot of internal javascript libraries and developers skilled with javascript.
JavaScript doesn't tie you to HTML5. Folks have added QT bindings to Node.js before, as well as other libraries.
We expect the application to grow upto > 50k lines of code
How could you possibly know this right now? You haven't even decided what you're going to write it in.
There's a specific app that I want to make, and I was wondering if I can use JavaScript to code it entirely.
There are a number of frameworks out there that let you write your code in HTML, CSS, and JS and then compile/build apps to native devices I for instance Apache Cordova or Phone Gap do this.
Choices are countless. Try Cordova for hybrid app development.
You're most likely thinking of a single page HTML5-based "app".
(though it's arguably not an app, it's just a web page).
These are often built using frameworks such as Angular, Backbone, or Ember.
Watch out, there's still constant debate on the merits of HTML5 vs. native apps.
I just recently got introduced to MV* frameworks and have taken a chance to try out Ember.js with the TodoMVC app tutorial they have on their site.
I was considering using Ember for one of my upcoming projects (a Ruby on Rails CRUD app, similar to Twitter in some of the functionality), but I'm still a bit confused and before I take a final decision I would love it if somebody could clear the following concerns:
Is it a good idea to use such an advanced framework as Ember for a medium-sized multi-page CRUD app? Will it improve development time and maintenance compared to an interactivity layer built with jQuery's DOM manipulation and AJAX capabilities? Or is using Ember (and the like) only good when developing complex single-page apps (e.g.: Grooveshark)?
Considering the app will be developed using Rails, and assuming Ember will be used, is it going to be possible to offer a fallback with basic functionality for browsers with JavaScript disabled and/or for search engine crawlers? Will it require code duplication or other dirty tricks? Do you know of any technique that can be used to achieve it?
Will it be possible to adapt the website for mobile browsing (using only CSS) with valid results, or will the overhead imposed by running Ember on the phone make it hard for the device to render the website in a way that keeps it responsive?
We're in the middle of a pretty big Ember project right now, so here are my thoughts on your questions.
We've found Ember to be really productive for creating rich UIs for our single page app, but I don't know that it's going to be that much more helpful if you're creating an app designed for traditional multi-page (viewing pages, submitting forms, etc) layout.
I think this is the clincher - Ember is completely JS-based, so if you need to support browsers without JS, you'd basically have to write a parallel application. If this is a hard requirement for your app, I think Ember (or any MV* JS framework) would be out of the question
We've had very few performance issues on mobile - our site is fully responsive and renders on everything from Blackberries to the latest Chrome on desktop with good performance.
#Scott Rankin, has addressed most of the concerns with going with the Pure Ember approach. I'll add one quick way to make this decision.
Go with Ember/MVVM if the application is behind a login. Then you don't have to consider search engines, as the content is generally private and not supposed to be indexed.
For SEO you have to build atleast part of your content such that it is indexable. A good example of this is the Discourse application. They use Ember but also send down some generated html along with the app html slugs, so that search engines can index them. You can read about their approach here.
We have a different approach which can be seen as a fall back: We pre-render a static version of each page in the application (daily scheduled task). This static version is stored on the server as HTML file. Whenever we sniff as spider/ robot user agent, we deliver that version.
I'm working on a Java EE project right now, using lots of javascript function, but only using jQuery library.
I would like to know if anybody has some experience with this, used a Javascript framework with Java before, and tell me what would be the best way to do it, and best tool to do it.
Also, part of requirements are that I want to use the Framework to make it easy to handle the events, and to define a state machine for the website. I was looking a sproutcore, but couldn't find any information on how to use it inside a Java EE project.
For pure frontend compilation, there are several options, darioo mentioned Google Web Toolkit, though this is all very low level and thus harder to roll into out of the box. There are several GUI frameworks out there based on GWT.
Ext GWT
Smart GWT
Vaadin
Out of those three I hear our Java devs are most happy with Vaadin, though it's quite hard to create really customized (your average funky website with never before seen features...) frontend apps with these frameworks and you will long back for the expressive freedom JS toolkits like jQuery have to offer in a lot less code.
Then there are hybrids (JSP based), allowing more freedom in you frontend files (aka. frontend developers can tinker with it without knowing Java). Java code doesn't compile JS, but offers out of the box solutions you can tinker with in the JSPs.
JSF2 (uses YUI)
Spring Roo (uses Dojo JS framework)
Spring Roo scaffolds an entire frontend provides/uses the Dojo framework. JSF2 was/is looking nice as well according to our Java devs, though wwhen looking at the website, the angst of Oracle seeps in.
Both Dojo and YUI are quite expansive and mature JS frameworks specialised for large JS projects. Whereas jQuery is nicer for smaller JS projects with a rather flat architecture.
Ignoring Java based solutions, you can always fall back to YUI, Dojo or even MooTools for more architecture options.
You can also stick with jQuery, but imo. you need to be happily insane and masochistic (aka. frontend/JS developer) to maintain large scale JS/Html/CSS projects. jQuery is a nice toolkit, but as a framework, it offers meager architectural/structural solutions, you will have to devise them yourself by mixing and matching it with other small toolkits like RequireJS.
My best advice would be, build your app without JS first, using page refreshes and whatnot. Then apply a JS layer and build Ajax services for that layer. That way, your views and JS solution are losely coupled and theoretically, you can always switch frameworks without touching your JSP's too much.
If you already know Java, Google Web Toolkit is the most Javascript centric framework out there that I'm aware of.
Note: it's not just another Javascript library like jQuery, but a full blown framework with set rules you must adhere to. By writing Java code, it will generate Javascript for you that's highly optimized for speed, size and multiple browser compatibility.
I would like to know, how powerful/viable are JavaScript only clients based on say, GWT/gxt/vaadin, when compared to DHTML clients such as those made with wicket, tapestry, click etc?
My boss has insisted on using GXT (due to its nice colors and theme) on a project that will most likely become very big with lots of screens. I am against the idea of a javascript only client, especially when the javascript is generated from Java code. I have tried to advice him that we use something like wicket whereby we construct the screens with html but put in ajax where and when neccessary.
How viable is such a JavaScript client? I understand that JavaScript was intended for minor web page enhancements, and not all browsers, especially mobile devices have complete support for JavaScript.
Yes, it is viable for certain applications. Consider Gmail, Google Docs and Google Maps as typical applications where this works, and is probably the most feasible approach.
Some rich UI JavaScript frameworks, such as Ext JS also rely on this technique.
I've built javascript only web apps for ages.
First in SAP projects for big multinationals. And now on a new project:https://beebole-apps.com?demo
So yes it is powerful and viable.
Javascript-only webapp can be extremely powerful, and it's viable for certain applications, say, an Instant-Messenger webapp?
You mentioned that there are lots of screens in your web-app. One of the advantages from GWT/GXT is the fact that you can unit test your UI-layer with JUnit. This is an extra testing you can do on top of, say, Selenium. This is essential if you'd like to make UI testing a part of the continuous integration process, and, as the team grows, you'll definitely want to have tests around to make sure everything works (At least in theory.)
However, if what your boss meant to do is to build an in-house, custom Javascript engine using GWT's JavaScript Native Interface (Link), then I'm not sure...
Another advantage with GWT-like-engine over Wicket is that you can rely on HTML-code-gen to generate standard-compliant (In theory) HTML code. With framework like Wicket, it is hard to ensure every single developer on the team to author good HTML code - Especially when the team gets bigger.
Disclaimer: I'm a member of the Vaadin team.
Our Timeline demo is a good example of what can be achieved with Vaadin and GWT in client side, but I think all of the options presented in this discussions are viable given enough time.
Since you are going to start a big project you should build a simple proof-of-concept app with each of the relevant frameworks. If your PoC includes at least some of the more complex use cases you'll probably can make a pretty informed choice based on the experiences you get while building them.
I urge you to at least evaluate Vaadin. With it you write only server-side Java code and Vaadin will create a slick and professional browser UI for you. Client side can be easily extended using standard GWT (also pure Java), and there are no HTML templates, tag libraries or XML configuration involved at all. A Vaadin UI is fully Ajax'ed and lazy loading out of the box, and it easily integrates with any server side technologies, eg. Spring.
In addition to the development model advantages you get top-notch documentation, a bi-weekly update schedule, a very lively community filled with helpful experts, 100+ useful open source add-ons, and a 10 year old backing company with help on hand should you need it.