Yes, the state of the industry is a hot mess, but I'm not sure this article rings true. Failing to leverage good frameworks is as big a problem as over using the bad ones. I would point to Rails as an example of an appropriate framework (and Laravel if PHP is your jam). The trouble is so many others are bad, incomplete or defunct, but I don't think the answer is the golang mantra of 'we don't need no stinking frameworks'. Seeing mediocre developers reinvent the wheel, slowly and badly, is super painful and wastes time and money. If you hate the frameworks available to you then perhaps you should consider finding a better ecosystem. Relax your bias and follow the happy developers, wherever that may lead.
I'm not sure I'd describe the golang community's attitude as a complete write-off of frameworks. I don't think I personally know a Go developer who doesn't use some sort of web framework (I personally use Echo, for example).
Rather I think it'd be better phrased as "frameworks should use simple abstractions and methods as often as possible", which the language naturally pushes people towards imo. I believe this causes most Go frameworks to be referred to as "microframeworks".
I agree with your more nuanced take on the golang community's position. I still think that a fully realized framework is, in general, a better starting point for the vast majority of projects. Part of the problem is that such frameworks are few and far between. I'll stick to the Ruby community: I know developers I respect who really like Sinatra, which would be more akin to a microframework. It is their go to starting point, but when I go to work on their projects I very quickly find myself straying out of Sinatra's capabilities into things that are fully baked into Rails. I then have to spend time pulling that capability into Sinatra, which is not how I like to spend my time as an application developer. There are many frameworks that are positioned as 'elegant' or 'focused' when they are simply incomplete in the face of real world development and teams end up having to either cobble together disparate micro-framework or rebuild basic capabilities to get to a fully realized app. I would argue that is not time well spent and that everyone thinks they are super good at creating solid, performant, extensible, well documented code, but they are not (statistically speaking) and by then it is too late and others have to live with their junk for years, or worse yet they all bail because now they know hot-framework-x and board the recruiter train to their next salary bump.
Laravel is prime example of a bad framework trying to reinvent the language, educating young developers to use it and its ecosystem and to never get out of the stranglehold.
I'm not sure what made you think it's an "appropriate" framework, it's literally antipattern on antipattern and it's not even the worst thing, neither is the fact it's 10x slower than anything else out there - what's worst is the blatant lying, bunch of security issues and using it as an advertising platform to push subpar services onto devs stuck with it.
I don't know the php ecosystem well at all. I just didn't want to come across as 'Rails is the only one true way'. Lots of php folks seem to love it, and it derives a lot from Rails, so I thought it was a fairly safe shout out. But, it is HN after all, so no opinion can be put forth without and equal and opposite negative reaction.
Or do you prefer to not use any framework and instead write your own one on the fly because you're probably going to do it a lot better with all the best practices and no bugs and great documentation?
Why would you imply I tried to say anything against frameworks in general? My comment was specifically about Laravel because it was singled out as a great framework.
To indulge you, about good frameworks: Symfony, Aphiria. Aphiria in particular because it's small, cuts down on repetitive tasks and doesn't reinvent the language with things like "Macros" or abuse of Reflection or mishandled patterns like singletons - all of which Laravel gets wrong.
Symfony because of active development. Every large tool is bound to be bad at something. Symfony is no exception, however it's not an advertising platform - and Laravel is an advertising platform. Sane choice is to use the tool with maximum benefit and least negative impact.
Micro frameworks that don’t do more than routing. I’d love to see those beautiful reinventions of the wheel people do when using “simple” frameworks for email, ORM, validations, authentication, authorization, cli commands, translations, error and performance reporting, etc etc.
The only case where failing to leverage a good framework would be a real problem is in front end development, and that's just because the front end stack is so horribly designed that it often needs a framework just to make the complexity demanded by business possible. Those frameworks often bring in a ton of problems, of course, so it's really picking your poison. But libraries and hand-rolled solutions should be used when you aren't stuck with JavaScript.
The x86 hardware and the Linux OS both had to make the jump to 64 bit. Sun was still able to make hay in the period where Linux was well established because 32 bit memory restrictions kept if from being a viable option for a lot of higher end computing needs. It was inevitable that Linux would eventually make the migration to 64 bit once the hardware was there, but Sun got there first on both the hardware and software fronts. Why Sun didn't react more radically when 64 bit Lintel was able to go head to head with Sun's precious 'enterprise' solutions is unknown to me. Maybe they were just in mass denial? Maybe they thought the technical hight priests within their organization would manifest new technical advantages? Maybe they just knew that if they dropped their pricing to address the new price/performance reality that their company was no longer economically viable? There was a lot of denial about Linux at the time, and there were plenty of legitimate reasons to question whether or not Linux could really make the leap to compete head to head with the leading commercial Unix offerings. Meanwhile, major efforts were being made by the likes of IBM and, ironically, Oracle, to contribute to efforts to make Linux a 'no compromise' commercial offering. Remember that companies like IBM had watched their own Unix offerings suffer from Solaris on the high end and Linux on the low end. The smart ones realized that Linux could be the answer to the hard sell they were running into with their own Unix and put engineering efforts towards making that happen. I'm not saying Linux wouldn't have gotten there without them, but there was a strategic shift that happened to accelerate the technical ascension of Linux, and that also caught Sun off guard. I suspect they had looked at the historical trajectory of Linux and over estimated how long it would take Linux to 'catch up' to Solaris. Linux went 'hockey stick' on Sun.
No. AMD64 wasn’t as popular especially in enterprise environments until just before Intel started to support it. Intel had the failed Itanium but that wasn’t the reason for Linux’s success. Linux on 32bit was still dominant at that point and the cause.
I was supporting a cross-platform enterprise environment and was deep into this at the time. I saw it from the front line’s and I even implemented my company’s port to Linux. Everyone was skeptical about Itanium. Enterprises companies in most part didn’t have the luxury to experiment.
Agreed. In my mind, the M1 Mac I'm typing this on is a direct descendent of the NeXT workstation that launched while I was still a student with no hope of ever owning. As much as I love the progress, it does make me wonder where/how the next true breakthrough will come from, or will we just continue to evolve what we have for another few decades?
They were already doomed at that point. I was involved in several major purchase decisions during that period and Sun were totally out of touch. If they were quoting hardware that had an x86 equivalent, then they were overpriced. If it was something that didn't have an x86 equivalent, like they had for a while with 64 bit, the prices were atrocious. Then Lintel moved to 64 bit and it was all over. The price/performance equation was broken, but Sun, for whatever reason, kept on like nothing had happened. I, and I'm sure many others, tried to show them that they were uncompetitive, but you were dealing with reps working from a price sheet and citing the same old mantra that Sun was inherently superior. For years when I would tell peers that the Sun equipment was just throwing away money they wouldn't believe me because they hadn't done the benchmarking. Really, if people did proper benchmarking and didn't just 'buy what they know' without questioning, it all would have unwound even more quickly. They certainly had some good tech, and were not wrong about the advantages of containerization, which came full circle with linux containerization and docker, but IBM mainframes had similar virtualization capabilities in place long before Solaris zones, so it wasn't something that was a game changer. Ironically, it worked against them because even though they were right, it was seen by some as Sun touting their way of doing it because they didn't have a viable solution for the prevailing VM direction of hardware virtualization. Basically, they began by offering the best price/performance and innovation, but then died trying to be a 'premium provider' without the goods to back it up, and market forces then do what market forces do.
Sun's sales guys were killing it right up until their last breath. I can clearly remember thinking to myself "why does this Sun/Solaris node cost $32k when this equivalent Intel costs $10K?" One day it was the in-thing, the next pooof Solaris was GONE.
I agree that they were doomed by that point as well primarily due to Linux on faster and cheaper x86 hardware. My UltraSPARC-III-based Blade 1500 that was an incredibly overpriced workstation that only ran Solaris well, and wasn't on par with the performance of x86 at the time.
However, I do remember buying an Opteron-based Ultra 20 because it was cheaper from Sun than anyone else and had 100% Linux support, which everyone seemed to be migrating to from Solaris. By that time, I'm sure there was no clear market direction for Sun software- or hardware-wise, and everything was too little too late.
If there is a business/domain need for this capability most organizations will go with some kind on content management solution (CMS) of which there are myriad solutions. Git would be considered bare bones and unintuitive compared with the best of these tools.
It competes with anyone selling point of sale hardware. I think Square falls into that camp, no? I wouldn't want to be in that space right now. I don't see how this doesn't usurp a big chunk of their market since it isn't even a decision between buy this or buy that, but buy that or just use the thing already in my pocket.
This was my initial thinking, but then I think most businesses won't want to use a phone as their payment platform. My reasoning is that when I go into a business and I tap the Square terminal, I am assuming that terminal belongs to the business, because what individual would have their own square terminal.
If the person who is ringing me up has an iPhone, and says "just tap this", there is a part of me that is wondering if this is the company's iPhone, or their personal device? Of course, this is easily resolved with the right surround which would remove this question, but I think it's somewhat valid.
Isn't this how it works in Apple stores (I'm not an apple person). Don't they walk around with iPhones in this big chunky yellow cases, and then you just pay for stuff through that? Maybe I'm wrong...
Are you concerned about a malicious employee using their own iphone to steal the money? Why couldn't they give you their own square terminal? On that note, when you pay cash why can't they just pocket whatever you give them?
I don't see why you care anyway, they would be stealing from the store, not from you. You would already have whatever item you are buying.
A colleague of mine owned a lunchstand, where the cook brought in his own receipt printer and used it for a large portion of daily business, and later bought the business.
Because I can somewhat trust the Square terminal will show the correct amount? If I swipe some random persons iPhone, whats stopping them from showing a $10 total and charging $1000?
This is an interesting to think about. Say you're at an ice cream stand that has a Square Reader (the little square hockey puck reader) that's paired with an iPhone running Square's payment reader.
The merchant rings you up for $5, shows you the phone in their hand indicating the cost, and the Square Reader lights up to show it's ready for payment. You pay via inserting your credit card, which processes in a few seconds, and then the payment is complete. The merchant is no longer showing you the phone, and presumably hits "No Receipt".
However, the merchant actually has a second out of sight device that is set to charge $500 and is actually paired with the Square Reader. Because you've paid with a physical card, there's a good chance you won't notice the charge till you go to pay your credit card or check your bank account.
This would probably be a short-lived scam, as the merchant's malicious Square account would have to be linked to a bank (I think this is the only option), which would identify them. I'm pretty sure Square requires ID verification of some sort as well. So reporting this malicious transaction to your bank/credit card would flag them.
Additionally, if you're paying via a mobile wallet, you'll likely get an immediate notification saying "You paid $500 to Malicious Ice Cream Vendor".
Now let's think about Apple's new plan. It could be that Apple layer's it's own mandatory interface that shows "Pay $5 to Ice Cream Vendor" regardless of the app being used. Maybe this is actually the employee's phone instead of the company's device, but that's the same as the employee stealing cash out of the register, so not really your issue.
Or Apple could not layer it's own UI, and just open up the radio as an API. Apple could require that apps that use this API to have some additional verification to prevent someone from making an app that displays "Charge $5" when it's really charging $500.
All that being said, I only see smaller merchants using iPhones + Square Readers. Maybe some boutique stores, food trucks, etc. Once a store gets large enough, they usually want dedicated hardware, even if it's a Square Stand.
Wouldn't you just get a notification on your phone from your credit card or bank app to say how much the transaction is for and to whom. Then you'd know straight away that something is wrong.
Can’t you turn on in your bank app to get a push notification immediately on every transaction? I have this turned on for both of my credit card accounts, so literally within a second or two of tapping or inserting (whether physical card, or Apple Pay on the watch or phone) I get a notification telling me how much was just charged to my card.
Useful for double checking that something hasn’t gone wrong and I haven’t been charged the wrong amount! I’d also see if a fraudulent transaction went through.
Why do I currently trust any contactless payment terminal to debit the right amount from my Visa card ? The trust is built with every transaction.
The first time I used one of those strange little white terminals it seemed a bit dodgy ... but you pretty quickly come to trust that what's on the screen is what gets debited.
Also I doubt Apple would leave a nice app-accessible text field on the Tap To Pay dialog where I can insert my fake amount. Right ?!
So, yes, it is a concern about a malicious actor. Likely an employee, but hey, with just an iPhone and a big enough store, can't anyone just pretend to be an employee?
I would like to go to a store where I trust the business, the employee, and the entire pipeline. I understand that is idealistic, but yes, this is how I feel. It's like saying "why do you care if the employee is underpaid, you're saving money", which describes the whole tipping culture in the US.
Square readers are dirt cheap, like $60 or less. If an employee wanted to defraud their workplace like that, it's no barrier. They'll be caught when the shop reconciles things.
Why would you need a special surround? And why is that an issue for you the consumer?
Anyone who is going to be buying PoS from Square at a rate greater than just the phone attachment reader, this won't be sufficient for. Using a phone for a business you personally run is fine, using a phone as the central point of your business for even a relatively small fast casual is going to be a nightmare.
And for those even on Square Apple's ipads are still the preferred choice as far as I can tell. So there isn't much of a benefit other than fees.
For anything larger than a small fast casual you quickly run into greater integration needs with things like KDS (of which a few do use tablets, Toast, Fresh, etc, and even then I think ipads are preferred. I know Square integrates with a few of those as well as NorthStar so, I don't think they may have much to fear other than at the low end mom and pop stores.
POS and payment hardware used to be a fairly high margin vertical hardware business, but I don't think so any longer. The real goal now is merchant / customer acquisition and service lock in. Basically I'd expect the hardware will be given away at some point.
I'm not even sure there, at least for another few years. No store, mom and pop or otherwise, would want to be "tap to pay only" as a means of taking credit card payments. There are still plenty of cards out there that don't have RFID chips.
Payments and mobile service are some of the more weird things about the US given how easily startups or new tech is developed there. There last time I was in the US was years ago. I still had to swipe my card in a few places and getting a new SIM involved me having to talk to someone. By this time in Australia contactless payments were almost everywhere and you just needed to go to a convenience store to get a SIM and activate online.
It looks like they are going through similar weird things with instant bank transfers. In Australia all the major banks just have instant transfers built in. I use the bank app to transfer to friends and they get notified. In the US you Venmo or PayPal or whatever.
Yeah, the US is finally starting to catch up with contactless. Other countries have been strange as well. My understanding is it was popular in Canada for awhile, but then terminals started disappearing?
The first time I was able to use ApplePay (as an American) was on a trip to NZ. In fact, the clerk at the gas station was shocked to see someone pay with their phone, even though this had been possible with Android for some time, and even though contactless itself was old hat there.
As for the SIM thing, that just depends so much on the business model and regulatory environment. Pay as you go is relatively unpopular in the US, and the availability reflects that. But it's not like Italy, where I had to hand over my passport (!) to get a SIM, or Germany, where I had to document where I was "living". I've heard it's even worse in, say, Chile, where you virtually need to be a citizen or permanent resident to get a SIM.
Yea, practically speaking the physical card is just a trinket to get people to sign up for the card.
BUT contact free payment via card and Apple Pay contact free payments are slightly different and I’ve been to POS terminals that had one but not other. But the point was that there exists cards that don’t have nfc capabilities, including the one made by the company at center of article.
> I’ve been to POS terminals that had one but not other.
They are very, very similar that this surprises me. Apple/Google pay implement the same standards as wireless cards and it should Just Work(TM) everywhere the cards can be accepted. Obviously real life and 'should' don't always marry up.
But it was one of the big drivers of acceptance of the tech in most places - the infrastructure is already there! You probably don't even need to update the firmware on your reader!
> including the one made by the company at center of article.
Sure, but my point is that I believe that's deliberate, because they want you to use the contactless payment capability of your phone. I don't doubt there are other cards out there without the capability, I just think the apple one isn't a great example.
No one uses a mag reader here in Canada. Europe ditto, and sounds like the antipodes too. I don't know anyone who doesn't have RFID cards, debit or credit. Swiping a card through a mag reader is the backup option alone here.
I'm in the US. It's not uncommon here. In fact, two of my cards, a Chase Visa, and an Amex, both only support mag stripe and chip; they do not have an RFID chip in them. I could get them replaced, but why? Every POS system supports those; not everyone supports tap to pay.
The US may be an anomaly here, but it always has been. The UK had chip and pin roll out while the US still had mag stripe being the most common; we slowly added chip and signature (we still don't have chip and pin), and now we still aren't anywhere close to universal in tap to pay.
I assume Square makes vastly more on fees than on hardware, so the opportunity to make fees off more merchants who have a smaller barrier to entry is probably beneficial, even if they don't buy hardware.
Fees are definitely where the money is made in the payments sector, however, most proper terminals are leased so that represents a fairly large source of revenue for merchant service providers. A company I worked for were leasing terminals starting at £20 a month, and then took a cut of transactions plus a whole host of other bolt-ons like PCI non-compliance fees (which is it’s own racket, they’re not incentivised to ensure merchants are PCI compliant because it’s a significant revenue stream).
Square sells hardware, but losing money on that. I don't believe it is intended to compete with payment processors providing hardware, but more so commoditizes it/flattens existing players in cases where a POS terminal system isn't needed.
It competes with anyone selling point of sale hardware
No.
It allows sole proprietors, freelancers and the like to not have to get a Square reader to take credit card transactions. That's super convenient, especially for getting a deposit from a client, for example.
It also requires a newish iPhone (iPhone XS or later device), so there will still be plenty of iPhones out there that won't support this.
As in 'slight of hand' employed by a magician. Where someone makes an obvious movement to distract from something they don't want you to see. In this case, the assertion is that the Metaverse is more hype than reality. A shiny object, or concept, to create a plausible narrative that bridges Facebook into a future where they once again dominate, while distracting from the possibility that their current position is in decline with no tangible mitigation plan.
20+ years of web site ecommerce development experience and what I see is that consistently the designers and the managers and/or product owners (who have the final say and must be suitably impressed) have no access to, or don't bother to consume or understand the site metrics and in many cases don't even have a rudimentary understanding how how their site works (or doesn't work). I've been in so many meetings where the group was ready and willing to kill a feature, or a link or a button and I've had to bring up hard metrics to keep them from killing something that not only people used, but converted more often with a bigger cart. And these are ecommerce sites, so I can only suppose that it is even more so with any site where cold hard cash is not on the line. The trend towards hiding things just to make the design look clean is ignorant and lazy. UX is hard. It should be driven by metrics and validated by observing real user behavior. Anyone who doesn't do that is being vastly overpaid and inevitably eroding the user experience. Nobody should ever have to hover randomly around a screen to hunt for controls, but I see it every single day, and now even on former bastions of usability like core Mac interfaces. How does this stuff get through usability testing? A: It was probably never done, or if it was the aforementioned decision makers never gave it a first let along a second look. Best advice I can give is to never, ever, do a wholesale site redesign when conversion counts. Always incremental, always iterative, always driven by metrics and true usability labs. If someone balks at doing any of this, they shouldn't be in the business, get rid of them or ask for another designer/team.
