I keep hearing about HTML5 applications. When they say that, do they mean applications that are built using HTML5, CSS3, and Javascript only and without the help of MySQL, PHP and other backend tools?
Most of the web applications are 3 tier that means heart of application is Business Logic. And I don't think any Business will get ready to write business logic in HTML for security reason and there are many more such reason like code reliability,maintainability come into picture. So no one can remove use of back end languages.
"HTML 5 Application" is whishy-washy marketing speak. It might mean something that stands alone (probably using non-HTML 5 APIs such as web storage), it might mean something that just uses a little bit of HTML 5.
Certainly you still need a server if any data needs to travel beyond the browser (e.g. to share data with other people / devices, back data up on the cloud, get news feeds, etc).
Related
Some people have asked similar questions about protecting HTML5 apps and protecting freemium apps, but not both together. I'm asking this separately because I have the impression (whether right or wrong) that HTML5 is particularly insecure vs native.
I'm working on an embedded HTML5 app I want to monetize using the freemium model, but I'm worried about how to keep its virtual currency and scoring variables from being too easily messed with by the end user, as I fear this could negatively impact revenue if some hacker (no offense intended by the term) were to create a YouTube video or blog posting about an exploit. I think it is pretty unlikely early on for this to happen, but I think vulnerability will matter more with popularity. I'm also worried about with which someone can copy an app.
I though realize both are possible inherently with an app installed on the device.
My questions are:
How easy is it, in your opinion or experience, to mess with an
unobfuscated embedded (not browser dependent) HTML5 app and its Javascript vs a native app with core files based on Java or Objective-C data?/How well does obfuscation work on HTML5 apps vs native obfuscated
apps in terms of data protection?
How difficult is it to obfuscate an HTML5 app vs using something like Proguard on regular Android apps?
Does obfuscation cause HTML5 to noticeably slow down for normal users?
Lastly, do you think it's practical to have an HTML5 app with
freemium features? Or do you personally think it is too vulnerable?
What I'm basically trying to figure out with them is whether HTML5 is particularly vulnerable or hard to protect, at least when compared to protecting native apps. If an obfuscated HTML5 app is as secure or insecure as a regular app, then I guess I'm okay with it.
The only way to prevent cheating (and unlocking freemium items is a kind of cheating) is to move all the relevant game logic to the server. Forget about obfuscation. When it's executed on the clients machine, it's under the control of the user. Obfuscation can slow the user down, but it can't stop someone who is determined to hack it. This doesn't just apply to javascript, it applies to every game client, no matter what programming language it is written in.
A general rule of designing cheat-proof multiplayer games is to never trust the client and do all calculations which are relevant for gameplay on the server.
In my opinion it is better to obfuscate AND never trust the client.
Not only that, I would even compress the obfuscated code and I would add an obfuscated decompressor in the client and/or the server.
The technique is viable and it is what professional companies are using all over the web.
Now, to answer your questions:
It's not easy to mess with a correctly obfuscated code (something
which will require you to compress/crypt even numbers).Professional
hackers won't mess with your code "for sport" unless they're given
money to do so and even in that case, they'll have a hard time doing
it (that's why I don't believe in the "forget about obfuscation" way
of thinking).
Obfuscation works really well in terms of data protection.Your code
becomes unreadable and, to some extent, it can be seen as a
compression algorithm thus it reduces file size and loading times.
Obfuscation is easy if you rely on professional tools which can
obfuscate, for example, JS, html5, css and php all together. It's
harder only if you have to develop such tools.But there exists
open-source software too in the field.
It slows down "normal users" definitely, they feel lost in front of
you code.
It's practical to have an HTML5 app with freemium features but it
all depends on your implementation of such options.
If done correctly as stated above, it's less vulnerable but,
personally, I don't like this business model.
My company writes software that installs on client machines to perform point-of-sale transactions. The software interfaces with a variety of external peripherals (receipt printers, bar code scanners, credit-card readers, etc). We do this with a WinForms app that we created in Visual Studio using the Microsoft OPOS library, which in turn communicates with our cloud server.
There are obvious inefficiencies in this model, primarily with updates. I'm researching other ways to communicate with these peripherals over the web, preferably via web browser. So far as I can tell, Java is one of the only technologies out there that can do what we're looking for (via applet), and I assume Adobe Flash can as well (via the Air platform). These are viable, but not preferable because we want to run our software on web-enabled mobile devices.
Does anybody have suggestions for other ways to communicate with external peripherals over the web?
UPDATE (Jan 16th, 2019): The Credential Management API has been announced. It's currently only supported on Chrome and Opera but it's looking promising. Google Developers wrote an article elaborating on the spec.
UPDATE (Dec 28th, 2016): Another couple years gone, and another update. This one will be more focused on two new developments than anything else. See the new "WebUSB & Web BlueTooth" section under "Full Device API". But the answer remains the same.
UPDATE (Nov 3rd, 2014): It's been just over two years since the original post was made, but the answer remains mostly the same for now. We are, however, closer to your original goal in several areas.
ORIGINAL ANSWER:
There would be a number of ways to go about this.
Background
The HTML5 specification has entered into the "Recommendation" state. This means that HTML5 is pretty much set for what it looks like. However, I will be using HTML5 in the same way that every marketing person in the world has decided is best. That is, I will not be talking about HTML. Well, I will, in so far as you will utilize it from an HTML page, but not really. What I'll actually be discussing is JavaScript (JS) and that's a horse of a different color. But for all intents and purposes, we're putting it all under the same heading as HTML5, which has been decided to mean "shiny and new" now.
Also, the items which I am discussing will vary in support. Some are very browser dependent projects (like Chromium specific implementations), and some are more standards driven projects that may not have browsers implementing or experimenting with them yet. I'll try to distinguish between the two as I go along.
Full Device API
Status: Incoming, but not ready
Being able to access devices from the browser is making slow but steady progress. Right now, many modern browsers have access to some of the more common devices like the camera or gamepads, but they are all high level APIs. Browser vendors, the standards groups, and lots of companies involved with the web are all trying to make webapps just as powerful as your local applications.
But the APIs you are looking for are still in progress and a ways off. For your particular case, and for the more general case of connecting your webapp to most devices, we're still a few years away from something we can use. If you want to see what awesome things are coming up in that field, here are just a select few items that may help you directly:
Web Near Field Communication (NFC) API
This one unfortunately may be dead in the water for now. But it looks like originally some folks at the W3C (mostly Intel it looks like) were looking at adding a NFC API to the web.
Media Capture Streams
The WebRTC group is working on programmatic access to media streams like the camera which would allow to integrate things like barcode scanning or other features. This has reached CR status and is available in browsers, but is less helpful on its own.
Web Bluetooth
If you had bluetooth capable tools, this API would help you connect with them from computers and devices that were able to listen and connect. The primary driver for this at the moment seems like it is the Chrome team, including an experimental implementation, but I wouldn't consider it anywhere ready to use yet (See "WebUSB & Web BlueTooth" section).
WebUSB
This would allow full access to low level USB information including listing devices and interacting with them. Same as Web BlueTooth, this seems to be current Chrome pet project, but I also wouldn't rely on it (See "WebUSB & Web BlueTooth" section).
Network Service Discovery
If you have other devices or items on the network which broadcast and use HTTP, this API would allow you to discover and interact with these services. No browser implementation, but it is in a working draft for the W3C.
Originally, Mozilla was pushing a number of these forward because of Boot2Gecko (or Firefox OS). However, with that project officially cancelled, we aren't seeing much progress from them in these areas now.
Members of the Chrome team, however, seem to have decided to dive in and start not only working towards these, but putting them live in browsers. Which leads us to...
WebUSB & Web BlueTooth
Like sausages, it's better to not know how Web Standards are made
-Abraham Lincoln (probably)
There's been a little bit of buzz in this area as it looks like the Chrome team snuck in these as experimental features and developed their own specification for it. Which is great! Just maybe not in the way that you were hoping for.
Each browser vendor and W3C contributor group has their own style and makes contributions towards the specs in their own way. The result is usually a fairly decent specification that the browsers have agreed upon. But getting from nothing to something is... messy. Real messy. And is quite a process a lot of times. It doesn't always result in a good spec (yeah, I'm talking about you Florian compromise...) but even when it does, it takes a while.
However, It seems like Google developed this version of the spec all on their own. And, in my experience, Google's approach to the specs is always a little... well... setting my personal opinions aside we'll say "gung-ho". They tend to just dive right into the deep end. And that seems to be what they've done here.
I highly doubt these specs or implementations will look anything like this when they become standards. And there's nothing wrong with that. That's part of the process. But I wouldn't go relying on this implementation or developing any code or products against it. This is an unprecedented feature on the web and all the browser vendors are gonna want a big say in this.
That said, this is actually good. One of the things Google often does (for better or worse) with situations like this is forces the conversation and it can push things along. And having a feature shipped in the browser, even an experimental feature, can turn up the heat on the demand for it. So we may see more progress in this area soon.
PhoneGap Apache Cordova. You know, for your phone
Status: Not fully featured and phone only
Apache Cordova, previously Adobe PhoneGap, is a way to write your program in HTML, CSS, and JS that allows you to access lower level functionality on things like phones, and compile across devices. This would be a way to implement your program, but it would be a phone application, not necessarily a desktop one. An option to consider, and something I figured I would mention.
Cordova implements a few of the above features already, but doesn't have some of the more powerful ones like NFC or BlueTooth.
The Native-App solution (for Windows 8)
Status: Possible, but OS specific and desktop app
Windows 8 offers the ability to build applications in HTML and JS. This would allow you to easily access lower level functionality on the OS via their API. From the looks of it, it is pretty extensive and you can do a lot. You mentioned cross OS support, however, and this obviously limits you to one OS.
It's so Flash-y!
Status: Dying/Dead, not possible as a web app
Flash won't have direct access to the system through the web. You could create an AIR application, but that will sort of defeat the purpose of having it web based. In addition, Flash support on mobile, and on the web it would seem, is on the decline.
NodeJS
Status: Can be a bit of a pain and only possible as a desktop app
NodeJS and JS applications have sort of been a hot topic the last couple years. I didn't discuss it in my original post because I felt it wasn't quite there yet. However, things have progressed and it is much closer to being ready for this sort of thing, and has the support and power of a growing user base. That said, for your particular case, I wouldn't recommend using it. It would have to be local on the users machine, and because of how NodeJS (and similar engines) are at the moment, it would require a lot of extra configuration and setup that would complicate things a bit.
So you could build an app using HTML, CSS and JS with NodeJS or similar engines and have low level access to what you need, but it has to be local, and it would take more work than I'm sure you want to do every time you'd like to install it for a customer.
... Now where was I?
So where does that leave us? Well, simple: if you want a single language/set of code as your code base, HTML/CSS/JS aren't a great option... yet. But they could be some day. For now, your options are limited to what you feel is best for your customer. Java is a stable option you listed, but obviously comes with its own drawbacks. As the web develops, I think we'll see a lot of really cool things coming out of the new functionality, but we've got a ways to go still.
More reading:
Brian.IO: Beyond HTML5
HTML5 Apps on Windows 8
Wikipedia list of projects built using JS
This is possible, but it would have to be done indirectly. In theory, you could write a socket-server in a low level language, which gets I/O, and sends the I/O through the socket (relaying, I guess). HTML5 uses WebSockets, or some equivalent to communicate with this socket-server.
Now it can be achieved with WebUSB API.
It is available in Chrome since version 54.
It is a W3C editor's draft so we can expect (hope) that it will be adopted by other browser vendors...
I've been thinking about this a lot lately... have a POS app mostly written in VB6, considering what to do next. HTML5 is an option and I was thinking I'd use VSPE to get the serial stuff into the JS.
http://www.eterlogic.com/Products.VSPE.html
Love this product! Works very well for getting serial traffic where you need it, so I think it would work well, at least as a proof-of-concept to get you going. You'll want to use a combination of "connector" types along with the "tcpclient" and "tcpserver".
Just for the record, a method that works well in 2016 (since chrome 26), but is to be withdrawn over the next 2 years is to deploy your html5 as a chrome app and use chrome.usb (or chrome.serial or chrome.bluetooth).
I am currently using chrome.usb and planning to migrate to a web app using WebUSB API (see Supersharp's answer), which I hope will be adopted by the time Google discontinue chrome apps 🤞.
I really need your help with this. We are planning on developing a real-time web application. We look at different libraries and concepts and a little confused.
What we need is: clients connect to websites and send data(usually an integer + client machine name) whenever they want (usually 1-5 seconds). Also, the same clients must receive data(the data received from other clients) from the server in a real-time mode. (maximum 0.5 seconds). Also, this data must be stored in the database.
We were thinking about using different technologies, but cannot decide which one to use.
We need this web application to be supported on Iphones and Android Phones (maybe blackberry).
and, of course desktop browsers.
Pooling seems not a very good Idea in this situation, due to highloads.
Html 5 web sockets kinda new, and probably not supported by all browsers.
Have anyone used nodejs ?
or twisted matrix: http://twistedmatrix.com/trac/?
or orbited(cannot post more than one link)?
or tornado?
Or XMPP(Jabber. I did not find good examples.)?
or something else?
What technology is the best to use in this type of project? Also, we would probably prefer the technology that has some community support and free to use.
Thanks a lot!
There is a lot of things to consider here. I would say that HTML 5 is not an option, simply due to support across platform.
Running with NodeJS is most likely possible, but the communication methods are really complicated. Pushing data to a page isn't really something that HTML/web apps are designed to do....
To get a valid answer you are going to need to get someone to come in and sit with you to really iron out details and implementation.
When you say that clients "connect to a website", do you really need it to be a website? It sounds like all the client is sending is a number and for that you don't need a website. Just pick the language of your choice, open up a socket, and go from there.
Are you streaming data to be visualized? You might want to take a look at graphite (and/or "pyped" which is part of graphite).
What kind of data? What is the purpose?
For real-time you're not going to get a web site unless you use some type of RIA but even then, it isn't going to be enough. Services aren't going to be good enough either. You're going to end up doing some type of polling which will only ever be psuedo-real-time unless you do duplex mode which wont be supported on most of the platforms you want to support.
sockets are the way to go but that requires a client for each platform you want to handle. Maybe you should rethink your requirements.
I'm not a Web Developer, and I don't know a lot about the web application frameworks out there.
Recently, however, I got into Wt. It's a web framework written in C++ (that's why I got into it), but what impressed me the most is the idea it's based on.
Its API is different from any web framework I ever heard of (CppCMS, Yii, Django, Pylons, Zope, Drupals, Java Servlets, Struts ...): a new Application object gets created for any user session, and it stays alive until the session expires (only at this point the Application object gets destroied). This Application object works like a desktop window: you put Widgets in it (widgets like forms, links, labels ...); when the user clicks on a link (when the HTTP server receives a new GET/POST request) a function gets called on the object tight to the user session (in a nice Signal/Slot way), which can remove/add/change the widgets, thus changing the page the user will see.
As I said, I'm not very skilled with web frameworks, I develop almost only desktop applications; maybe for this reason I think this paradigm behind Wt is great.
I'd like to know what are the pros and cons of this framework API in respect to the other ones, and if there are other frameworks (also in other languages) based on the same concepts.
Wt is a great framework for its intended range of applications.
Wt is great for :
web apps tightly coupled to a session, i.e.
made to be accessed only by users that are logged in (except the landing page)
display a lot of user-dependent content (so not for a wiki)
relying heavily on state
web apps that need to have a lot of controls/buttons and user input.
For exemple, I plan to write a browser MMORPG. Pages will all be having a state tied to a user, and there will be a lot of buttons. Wt is perfect for that. I used to be a Ruby on Rails developper, and switching to Wt for this kind of app was a great moment. It's increadibly cumbersome to design forms with traditional frameworks that try to enforce pure REST.
Wt would also be perfect for a control interface on some process. For example, an interface allowing your customers to configure their adword campain, etc.
Of course, using Wt is not perfect regarding control and separation, but it allows extremely fast development when you need only the "classic" features (buttons, editors, etc.)
So as a rule of thumb, if you are trying to put a desktop application on the web (which is a great idea, removing the need to deploy and update on your customers' machines), Wt is a good candidate.
Also, if you are interfacing with an existing C++ codebase, Wt has an advantage.
I think this is generally bad idea.
Web application is very different from GUI one and there are many reasons:
99% of the web is about the content rather then about iteration.
You go to web to get or share content rather then to do some real time interaction
like drawing a picture, working with spreadsheet or anything else.
Web is content driven rather then "event driven" interactive application.
This has strong impact on how do you create most of web - you bring information
to user rather then interact with him.
The server and client programming is very different
There are some web GUI applications like e-Mail, Chats clients but to perform well
they require very good separation between the client side written
in high quality Java Script and the high quality server side backend that is used
over AJAX for content retrieval.
Hiding this separation like Wt does or (other known frameworks) lead to crappy
software and generally brings more problems then solutions in long run.
Because it should be very clear separation between server side and client side jobs
as some require real time response and some don't.
When you try to solve all this in one wait for problems. Note, there are client-server
solutions for GUI (see X-Server as example) but unlike web they designed for this
and rather work more like IPC rather then client-server solitions.
The web is stateless most of the time.
Or to be more correct the state usually keeps quite small amount of data.
Creation of instant session object is nice idea until you need to...
Scale up save state in long terms then this model becomes not so good, of course
this not "forced" model by Wt but it is general concept that fits certain concept
and some does not.
Bottom Line
If you want to design good GUI like web application. Start learning JavaScript and use good GUI JavaScript frameworks that fit well to GUI even driven design. Then combine them with some server side API using some interaction RPC model like Json-RPC, XML-RPC and other
AJAX tools.
This is the way to do things right for highly interactive applications.
If your application is more content oriented then most of server side web
frameworks do great job - concentrate on server side with its great tools suitable
for the job.
All in one solution? It just does not work...
Disclosure: I'm developer of CppCMS and I think Wt just goes in wrong way.
ASP.NET is similar; it has the same goal to make web development look like desktop application development.
I want to design a website but I don't know from where to start.
Is there a beginners' guide to start with?
How much dedication do you hope to provide? If you merely want to design a single website, quickly and dirty, there's a plethora of open source web templates available online, with clean and basic HTML/XHTML design strategies that you could modify, and provide content for.
Such as this and that.
Alternatively, if you would like to design your own websites from scratch and have full technical knowledge in the field (the proper way). Pick up a book or two on HTML/XHTML/XML, with documentation on content management systems, php, etc.
You'd soon find that in the beginning your development would be gradual and at best, slow. If you put in sufficient effort, you would find that you get to the point where you can quickly design sites confidently, which best illuminate your content.
You should be familiar with this and this
Try this Web Design from Scratch
I understand by website you mean some kind of web-app. And by design you mean, not just the page design but the design of the web-app. First, you have to understand the anatomy of a web-app. The major components are:
Database is used to store user and application data for long term. A database provides query functionality (SQL), backup on one installation and restore on another, triggers when a data entry changes, and constraints that must be satisfied by the data tables.
Web Server, also called Http Server hosts the web application.
Web Browser such as Internet Explorer or Firefox.
When a user types a URL into the web browser, the web server forwards the URL to the corresponding web application. The web application performs the needed tasks (which may involve reading or writing into the database) and returns a new html page to the user via www.
Some components of the web application are:
Database access objects are representations of objects that encapsulate interaction with database tables.
Business Logic is the main logic of the application. Here we implement the search functionality using Lucene library, for example.
Action Handler handles a http request received from the user, for example when she types a URL or when she clicks on the "submit" button. These are Http GET and POST requests. The Action Handler uses the business logic to drive the actions.
Data view on the web brower is constructed using some template library (which usually produces javascript user interface code for the web browser). For interactivity one may use Ajax techniques.
Almost all web-apps separate the model, view and controller of a web application. The view deals with the display, the model deals with data and the controller deals with control/functioning. See http://www.uidesign.net/Articles/Papers/UsingMVCPatterninWebInter.html.
Several frameworks implement MVC. The most easy ones to get started are Ruby on Rails and Django (over which an open source social network called Pinax too is written). There are much more comprehensive frameworks and libraries in java too (for a single web appl you may need to join several of these libraries), such as spring, webwork, tapestry, lucene (for search), sitemesh (for page decoration). Many java web apps run on tomcat web server and with mysql database.
I started with http://w3schools.com. Make sure you're using Firefox and the Firebug addon. Get your hands dirty then get familiar with the web design community.
I have CSS Mastery by Andy Budd on my desk and it's a good, readable, short, yet deep guide to CSS.
Don't Make me think has also become my mantra of web design.
Overall, you're going to produce a lot of crap--as I have--before you get good. If you have someone to look over what you're doing that'll be the best help. Personal drive will matter the most in the long run though, so stick with it and keep learning.
Liz Castro has a good book too.