Framework abstracts you from low level details, makes you more productive, and protects you from low level error ( such as preventing SQL injection attacks).
A good PHP framework forces you to separate your concern and implements the proven architecture, which in the end improves your design, and makes your code much easier to read and maintain and unit test.
A framework streamlines application development by automating many of the patterns employed for a given purpose. A framework also adds structure to the code, prompting the developer to write better, more readable, and more maintainable code. Ultimately, a framework makes programming easier, since it packages complex operations into simple statements.
For a simple web application or a website with basic features it’s wiser to use some good open source system. However for more complex and bespoke functionality requirement it’s more recommended to work with framework.
Huge amount of development time can be saved with the use of Frameworks due to availability of large variety of tools like input sanitization and abstraction layers in particular.
It's very common scenario in website development companies where clients are really pressurizing and so often demand quick turnaround. Frameworks can be real life savers under high pressure as they help enormously in quickly delivering repetitive and commons tasks.
There are pretty good reasons to use the Frameworks:
|
Tuesday, 28 February 2017
why to use framework
why to use javascript frameworks ?
Don't Reinvent The Wheel
Why write code that's already been written (better)? A good programmer is a lazy programmer, so be lazy. The tools are there -- use them
Do More With Less Code
Most JavaScript frameworks provide function "chaining." Chaining allows you to do more with less code. Less code means less maintenance time, less download time, and less coding time. Check out MooTools chaining.
Save Time -- You Don't Code Your Own OS, Do You?
I love JavaScript as much as the next guy, but some programmers REALLY love developing JavaScript. Let the experts do the tough part, you take their work and make what you'd like of it.
Chances Are, You Aren't The Expert
As big as any programmer's ego is, there are people out there that are smarter, more inventive than you. Most Web Developers need to be a jack of all trades and it's difficult to keep up with every language when you're needed in every facet of a website's construction and launch. The minds behind the frameworks have their eyes on JavaScript daily -- trust in them.
Speed Thrills
The creators of these JavaScript frameworks have their own private pissing contest when it comes to JavaScript speed put a lot of effort into making sure their frameworks are fast. The first job of JavaScript for mass web visitor usage is to be fast -- users expect accuracy, speed is the most important part. Who's fastest today? Check out SlickSpeed.
Avoid Cryptic JavaScript Base Code
Why use JavaScript's default functions when you can use a framework's English-named functions? For example:
//standard JavaScript document.getElementbyId('mydiv').style.color = '#f00'; // camel-case the style! //mootools JavaScript $('mydiv').setStyle('color','#foo');
These are the reasons I use JavaScript frameworks. Need I say more?
7. Unified browser API, most of the time You dont have to think about browser compatibility because guys from Your framework took care (btw. I love jQuery).
Monday, 27 February 2017
Random Question Answers
What is CORS? How does it work?
Cross-origin resource sharing (CORS) is a mechanism that allows many resources (e.g., fonts, JavaScript, etc.) on a web page to be requested from another domain outside the domain from which the resource originated. It’s a mechanism supported in HTML5 that manages
XMLHttpRequest
access to a domain different.
CORS adds new HTTP headers that provide access to permitted origin domains. For HTTP methods other than GET (or POST with certain MIME types), the specification mandates that browsers first use an HTTP OPTIONS request header to solicit a list of supported (and available) methods from the server. The actual request can then be submitted. Servers can also notify clients whether “credentials” (including Cookies and HTTP Authentication data) should be sent with requests.
Explain the purpose of each of the HTTP request types when used with a RESTful web service.
The purpose of each of the HTTP request types when used with a RESTful web service is as follows:
- GET: Retrieves data from the server (should only retrieve data and should have no other effect).
- POST: Sends data to the server for a new entity. It is often used when uploading a file or submitting a completed web form.
- PUT: Similar to POST, but used to replace an existing entity.
- PATCH: Similar to PUT, but used to update only certain fields within an existing entity.
- DELETE: Removes data from the server.
- TRACE: Provides a means to test what a machine along the network path receives when a request is made. As such, it simply returns what was sent.
- OPTIONS: Allows a client to request information about the request methods supported by a service. The relevant response header is Allow and it simply lists the supported methods. (It can also be used to request information about the request methods supported for the server where the service resides by using a * wildcard in the URI.)
- HEAD: Same as the GET method for a resource, but returns only the response headers (i.e., with no entity-body).
- CONNECT: Primarily used to establish a network connection to a resource (usually via some proxy that can be requested to forward an HTTP request as TCP and maintain the connection). Once established, the response sends a 200 status code and a “Connection Established” message.
Explain the basic structure of a MIME multipart message when used to transfer different content type parts. Provide a simple example
A simple example of a MIME multipart message is as follows:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier
This is a message with multiple parts in MIME format.
--frontier
Content-Type: text/plain
This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--
Each MIME message starts with a message header. This header contains information about the message content and boundary. In this case
Content-Type: multipart/mixed; boundary=frontier
means that message contains multiple parts where each part is of different content type and they are separated by --frontier
as their boundary.
Each part consists of its own content header (zero or more
Content-
header fields) and a body. Multipart content can be nested. The content-transfer-encoding
of a multipart type must always be 7bit
, 8bit
, or binary
to avoid the complications that would be posed by multiple levels of decoding. The multipart block as a whole does not have a charset; non-ASCII characters in the part headers are handled by the Encoded-Word
system, and the part bodies can have charsets specified if appropriate for their content-type
.
What is Long polling, how does it work, and why would you use it? Considering server and client resources, what is the main drawback of using long polling? Which HTML5 feature is the best alternative to long polling
The HTTP protocol is based on a request/response pattern, which means that the server cannot push any data to the client (i.e., the server can only provide data to the client in response to a client request). Long polling is a web application development pattern used to emulate pushing data from server to client. When the long polling pattern is used, the client submits a request to the server and the connection then remains active until the server is ready to send data to the client. The connection is closed only after data is sent back to the client or connection timeout occurs. The client then creates a new request when the connection is closed, thus restarting the loop.
There are two important drawbacks that need to be considered when using long polling:
- Long polling requests are not different from any other HTTP request and web servers handle them the same way. This means that every long poll connection will reserve server resources, potentially maxing out the number of connections the server can handle. This can lead to HTTP connection timeouts.
- Each web browser will limit the maximum number of connections web application can make. This means that your application load time and performance may be degraded.
In HTML5, a useful alternative to long polling is using a WebSocket. A WebSocket is a protocol providing full-duplex communications channels over a single TCP connection. The WebSocket protocol makes possible more interaction between a browser and a web site, facilitating live content and eliminates the need for the long polling paradigm.
Another potential answer could be Server-sent DOM Events. Which is method of continuously sending data from a server to the browser, rather than repeatedly requesting it. However, this HTML5 feature is not supported by Microsoft Internet Explorer, thus making it less attractive solution.
What is an ETag and how does it work?
An ETag is an opaque identifier assigned by a web server to a specific version of a resource found at an URL. If the resource content at that URL ever changes, a new and different ETag is assigned.
In typical usage, when an URL is retrieved the web server will return the resource along with its corresponding ETag value, which is placed in an HTTP “ETag” field:
ETag: "unique_id_of_resource_version"
The client may then decide to cache the resource, along with its
ETag
. Later, if the client wants to retrieve the same URL again, it will send its previously saved copy of the ETag along with the request in a "If-None-Match"
field.If-None-Match: "unique_id_of_resource_version"
On this subsequent request, the server may now compare the client’s
ETag
with the ETag
for the current version of the resource. If the ETag
values match, meaning that the resource has not changed, then the server may send back a very short response with a HTTP 304 Not Modified
status. The 304 status tells the client that its cached version is still good and that it should use that.
However, if the
ETag
values do not match, meaning the resource has likely changed, then a full response including the resource’s content is returned, just as if ETag
were not being used. In this case the client may decide to replace its previously cached version with the newly returned resource and the new ETag
.
Explain the difference between stateless and stateful protocols. Which type of protocol is HTTP? Explain your answer.
A stateless communications protocol treats each request as an independent transaction. It therefore does not require the server to retain any session, identity, or status information spanning multiple requests from the same source. Similarly, the requestor can not rely on any such information being retained by the responder.
In contrast, a stateful communications protocol is one in which the responder maintains “state” information (session data, identity, status, etc.) across multiple requests from the same source.
HTTP is a stateless protocol. HTTP does not require server to retain information or status about each user for the duration of multiple requests.
Some web servers implement states using different methods (using cookies, custom headers, hidden form fields etc.). However, in the very core of every web application everything relies on HTTP which is still a stateless protocol that is based on simple request/response paradigm.
Describe the key advantages of HTTP/2 as compared with HTTP 1.1.
HTTP/2 provides decreased latency to improve page load speed by supporting:
- Data compression of HTTP headers
- Server push technologies
- Loading of page elements in parallel over a single TCP connection
- Prioritization of requests
An important operational benefit of HTTP/2 is that it avoids the head-of-line blocking problem in HTTP 1.
Subscribe to:
Posts (Atom)