It's always interesting to see real world applications of new Web functionality, so kudos to the Stripe team for pushing the envelope in an environment where mistakes could surely be expensive. I hadn't realised that CSS Grid Layout was a viable option for production use yet, for example, so TIL.
I do wonder whether sometimes the code here is using trendy tools just to be trendy, though. For example, is
Yeah, that's a strange piece of code, particularly since it introduces mutation (object[axis] = ...) and additional processing (reduce loop and inner function construction) that the naive example doesn't. It is slightly more generalizable to additional dimensions, but that seems awfully YAGNI to me. I suppose it prevents repetition of the Math.abs call and addition, but again that seems like massive overkill. I'd write it as follows, similar to yours:
TBH, this thread is pretty nitpicky, but I do agree with your assessment.
Yes and no.
On the one hand, the much more interesting parts here are the new APIs they've been using (and also IMHO the intelligent way they're handling compatibility and polyfills). All credit to the Stripe team both for making these tools work and for sharing what they've learned in the process for the benefit of others.
On the other hand, I think there is a real cultural problem in the JS community where newer is equated with better, and those defending that position will not infrequently appeal to authority by saying that Facebook or Stripe or Google or whoever does it so it must be a best practice. Grandpa here is getting awfully bored of young whippersnappers telling him code using new ES6 tricks is better (or, just as bad, that there's something wrong with clear, working code that does things in some older way). A gentle challenge to that assumption in a discussion about how these high profile organisations are using the new technologies doesn't seem either impolite or unjustified.
If you were trying to create a generalized getDistance function then the former would be preferred, but for this specific use case the latter outperforms the former by 2 orders of magnitude: https://jsperf.com/reduce-vs-standard/1
Using an object literal is significantly superior than using a dynamic construction in any case where parameterization isn't needed. The body of that reduce looks like what you'd expect the implementation of a custom object literal initialization to look like - something where the members being iterated over are parameterized.
I'm far less fussed about function vs lambda literal bound to a const. Usually that kind of decision comes down to tooling in debuggers - depending on the runtime, turning lambdas back into names may be difficult, if you have lambdas bound to event handlers and the like.
Their landing pages are just so beautiful, like fine art. I do wonder though the return on investment. The pages must take forever to create. Perhaps Stripe just has that much cash.
I think it's an extension of the excellent work that goes into their entire front-end. There's a great mix of functionality to simplicity that makes me be able to unambiguously recommend it for people starting out with CC payments.
The leadership team at Stripe seem to have a refreshingly simple and holistic view about how they run their business: they see that growing e-commerce as a whole is good for them, because it makes the pie bigger and they're getting a slice of it.
Much of what they do supports that overall strategy, from making attractive things for developers to some of the high-profile hires and acquisitions they've been making recently. Apparently the strategy is a good one, because here we all are talking about them on a site full of entrepreneurial types, and today it's not because of the service they provide but just because of their landing pages. :-)
Its definitely well worth it. Presentation is so fucking important outside of the insanely meritocratic programming world... I've seen this play out many many times...
Very simplified, Grid is for defining flexible 2D Grids from various components: you define lines forming a grid, and assign content to grid cells. Flexbox is primarily for layouting things along one axis. It provides some flexibility in the second dimension, and the ability to wrap the axis, but it primarily either organizes a row or a column of things.
Grids are also more flexible in where they position things, where Flexbox goes strictly by order and hierarchy in the document.
I'll give an example of something you can't do with a one-dimensional layout system like Flexbox but can do with Grid Layouts: a staggered grid/one made of nonuniform cells: https://i.stack.imgur.com/QI2ol.png.
These come up quite a bit. Look at Pinterest, it is all staggered/made of nonuniform cells.
That’s interesting, I didn’t know about that. Didn’t Pinterest migrate its web front end to using react which uses flexbox for its layout system? If so, how did they do this?
Cool, that’s interesting to know. I’m mainly used to using react in the context of react native so I wasn’t aware that mixing and matching like that was a thing.
Fascinating read! Web Animations are always so cool, but I never know where to start to incorporate them into my own work. What resources help one reach this level of expertise?
I love all the effects and they really did them well.
I hate that the current trend amongst webdev'ers in that "no added visual effects!" Black text! White background!
I think it's because the guys that are hyper focused at the programming side of things don't want to think/care about design stuff because they aren't that good at it.
This is what happens when a group of really enthusiastic and bright people come together to collaborate and build something. CSS/JS feels like a one man army against the browser but really great things can be accomplished if you have the right people for it
How many people do you know that only work with CSS?
And why shouldn't artists and engineers who are good at what they do and create aesthetically pleasing functional designs get paid appropriately?
Salary is a simple function of supply and demand, if your employee can find better pay elsewhere, you either increase his salary or let him fly. If you want to retain talent, you have to pay what the market pays. There isn't some kind of secret conspiracy where employers are shortchanging people who work in a more saturated market.
I'm highly suspicious you have no idea what you're talking about given your use of the phrase "CSS programmers". You shouldn't get angry at things you don't grok.
The pedants on Hacker News understood what the OP meant, yet nitpick on his use of "programmer".
I agree that there is too much window dressing on the web, an aesthetic defined by gratuitous graphic elements and distractions. The only purpose it serves is to project an image, it is marketing.
It used to be that pretty designs are seen as more trustworthy, but there has been a backlash. The superficial optimism of modern web design is becoming less and less effective, and it's taking more effort to pull it off.
Hehe I don't care about downvotes I just want to do this:
1. CSS isn't a programming language
2. If "workers in the economy rot" while "CSS 'programmers' make truckloads of money" then they aren't in the right industry.
CSS is not turing complete, is not a programming language, etc. It is a declarative, presentational language with no processing capabilities beyond extremely basic math.
There is no if, and, or but about it. Are you a web developer?
I read your post. You clearly brought in turing completeness to try and support your argument. Your other points I've addressed, think we're done here.
But I very clearly did not conflate turing completeness as a requirement of a programming language. I just thought it was worth mentioning that CSS3 + HTML5 is Turing complete.
And you are still completely incorrect about CSS being a programming language. I think we are done here.
You misunderstood my (granted) flippant point which was meant to mean 'lookup "programming language" on wikipedia', not 'go to the CSS page and look for it to explicitly call it a programming language'.
The whole point is, nothing about CSS being a stylesheet or presentational language makes it fall outside of the definition of programming language.
Okay, I'm gonna say it: I had to chuckle at the name "Connect", because there is already [0], and _even more so_ with Stripe also naming their user onboarding flow "Express", like [1].
Nice. But in my experience, front-end design always requires some hacks here and there, e.g. because of compatibility issues or because of design flaws in CSS. So either the Stripe engineers are ridiculously clever, or they are just avoiding the difficult stuff.
Their work is really about as good as it gets, so I don't really see how you could conclude they are "avoiding the difficult stuff" - though quite possibly they don't care very much how their pages render in IE 11 (I don't know!).
Never used stripe before, I haven't even heard much about them before, but their site(and this blog post) is convincing so I was thinking I will try it, but then I bumped into this thread: https://ecommerce.shopify.com/c/payments-shipping-fulfilment...
That thread is about four years old. Stripe got big very quickly and definitely had some growing pains for a while. Their customer support really was that bad/non-existent for a while. It was a lot of hassle to sort things out when we had a dubious chargeback too.
To give credit where it's due, they have improved since. Gone are the days when they were the small developer's payment service and you could expect to reach technical people straight away via their contact addresses, but they do at least seem to reply to messages eventually now.
IMHO they still have room for improvement. In particular, 24-48 hours for a first substantial response doesn't seem unusual, and that's far too long for a merchant who might have one of their own customers in limbo or some sort of ongoing dispute or fraud that they need to deal with quickly.
But at least Stripe seem to be moving in the right direction and genuinely trying to do better. Our experience of their support is still much better than you'll get from a lot of other payment services if you're only a small merchant.
Given the amount of payments they are processing these days, it seems unrealistic that they would get absolutely everything right every time. You find the same with PayPal, all the major traditional gateways, etc.
Of course, in online forums you see the people who are (sometimes quite reasonably) very upset and shouting about it, but not all the things that worked just fine for every other merchant. There's no way to know whether those stories were the norm or isolated incidents. Importantly, there's also no way to know whether there was more to the stories than the people telling them were letting on, because we only see one side there.
As I said before, Stripe definitely still have room for improvement, and are still often very slow at dealing with things. And I'm sure if anything like some of those stories happened to me, I'd be very aggrieved and warning people off them as well. But I can only comment on my own experience, and so far I'm still inclined to give them the benefit of the doubt, because in several years of dealing with them, they generally have fixed any problems eventually and seemed to be genuinely trying to help.
I do wonder whether sometimes the code here is using trendy tools just to be trendy, though. For example, is
really an improvement on grandpa's version