|Hacker News, Reddit, Stack Overflow Stats|
No public GitHub repository stats available
No public GitHub repository stats available
|Description||A popular general-purpose scripting language that is especially suited to web development||Lightweight, interpreted, object-oriented language with first-class functions||The primary programming language you use when writing software for OS X and iOS|
|Why people like using this service||
|Companies using this service|
PHP drives 80% of the web
July 11, 2014 01:42
Rants about PHP are everywhere, but during the last years the language and the whole ecosystem has evolved.
The lastest versions support namespaces, closures, traits, generators and with composer a dependency manager that changed the way PHP developers work and collaborate.
December 15, 2015 02:36
worked with php for around a year helping a client automate their backend and optimize their existing infrastructure.
PHP powers 90% of our application; both rendering the front-end, as the background processes (data capture, processing, etc.)
To generate websites from data, and to serve my UI for defining that data. Also many small personal tools, such as icon converters (rather than bash scripts). PHP is my go-to tool for server side logic.
Built an API with Composer, PHP Unit, Doctrine, Zend Validator, Zend Filter, and Stack PHP, and a PSR-7 micro framework that someone built called Proton that does not have any documentation.
Most used web development language, we use the latest version 7 which is about twice as fast as previous versions.
We happened to write the frontend in PHP. Hey, it was 2006, and we were high school students ;-)
An older ticket purchase system as well as nearly all management tools are still written in PHP. It's a long process to migrate away from it given available development resources.
PHP is what powers the server and dynamic content pages. It may be old school but it works.
How to use SelectPdf for HTML TO PDF Conversion in PHP: http://selectpdf.com/web-html-to-pdf-rest-api-for-php-samples/
→ Tom Z
Because it is required although the server is running HHVM every bit of code is PHP friendly it's an awesome synergy.
Legacy code that, although maintained slightly, will be phased out as we migrate the 2 backend tools that rely on it to other, more robust languages. See: http://bjorn.tipling.com/if-programming-languages-were-weapons
→ Sud Web
For bells and whistles on the UI, and for making the game Whack-A-Mol. I purposely avoided jQuery or other 3rd party frameworks, as I was aiming to make a low overhead website system, rather than a complex web application like I make most of the time.
The only notable exceptions were the use of SCSS (augmented by Compass) for styling, Bash for a few basic 'system chores' and CLI utilities required for development of the app (most notably git and heroku's CLI interface), and a bit of custom SQL for locations where the ORM extractions leaked (the app is DB-agnostic, but a bit of SQL was required to fill gaps in the ORMs when interfacing with Postgres).
All of our Frontend code is written in ECMAScript 6 using React/Redux, running on Node.js
Used Angular,Express,Mongo,Node.js and plenty APIs to support web or mobile application development.
Also used Sequalize for Object relational mapping in case the database shall be relational database, such as postgreSQL, MySQL, MariaDB, Oracle database.
Aside from usual web UI stuff, the user support widget/chat client, Z-XMPP, is written in it.
There are a couple js front end pieces that make my page look a little better.
JS on the config pages as well as within the watchapp for communication with the Foursquare API.
Used along with jQuery to add site interactivity, tag management and analytics.
While the majority of our stack is now using Swift, we still love Objective-C in many cases, especially low-level software manipulation, where it's just easier. It doesn't hurt that a lot of iOS/OS X Libraries out there are written in it either.
We like to go native with iOS development, and Objective-C has been the only game in town until recent introduction of Swift. We're keeping an eye on Swift, but we aren't giving up on the [old way:to do:things]!
Basically, the trajectory was we had our iOS app, which started out native, right? It started as a native app, and then we realized you have to go through a review process and it’s slow, and at a very early stage, it made sense for us to make it a wrapped web view. Basically, the app would open, and it would be a web view inside of it that we could iterate on quickly and change very rapidly and not have to wait for app store view process to change it. It wasn’t totally a native experience, but it was as actually a pretty good experience and lasted for a very long time and was up until recently the foundation of our current mobile web experience, which is different from our app situation. So for a long time, basically, our app store iOS Instacart app was a wrapped web view of just our store, a condensed version of our store, which meant that we could add things. We could change sales. We could change the formatting. We could change the UI really fast and not have to worry about the app store review process.
This all changed about a year ago, I would like to say, at which point it became a totally native app. We felt comfortable enough with the product and all the features that we made it a native experience and made it a fully featured app.
We actually launched iOS first. The iOS app looked okay. It worked; you ordered groceries from Instacart, there was no notion of stores or retailers on the site. You just ordered your bananas and milk from Instacart and had them delivered from Safeway.