Hacker News new | past | comments | ask | show | jobs | submit login
Connect: behind the front-end experience (stripe.com)
273 points by hepha1979 on June 19, 2017 | hide | past | web | favorite | 60 comments

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

    const getDistance = (state, rotate) =>
      ["x", "y"].reduce((object, axis) => {
        object[axis] = Math.abs(state[axis] + rotate[axis]);
        return object;
      }, {});
really an improvement on grandpa's version

    function getDistance(state, rotate) {
        return {
            x: Math.abs(state.x + rotate.x),
            y: Math.abs(state.y + rotate.y)


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:

    const getDistance = (state, rotate) => ({
      x: Math.abs(state.x + rotate.x),
      y: Math.abs(state.y + rotate.y),
TBH, this thread is pretty nitpicky, but I do agree with your assessment.

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.

Stripe's design continually makes me envious. I hope to one day own a product that matches their level of quality.

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.

Or perhaps, Stripe has front-end engineers that really know what they're doing.

Stripe has FE engineers who know what they are doing. https://stripe.com/open-source

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...

...or perhaps Stripes just take pride in their work.

Well deserved pride. It should be customary to showcase a frontend project with brilliant landing pages :)

I always imagined they would be called 'Stripers' but now realize why it could go horribly wrong when saying it loud.

Interesting insights into Stripe's collaboration: https://medium.com/in-progress/design-and-collaboration-at-s...

Perhaps Stripe just has that much cash.

Paypal is far bigger Stripe, so it's not that.

That doesn't mean Stripe is small.

The landing pages don't look very difficult to implement, but yes, the design is beautiful.

Fucking stupendous. Stripe is continually pushing the envelope. Outstanding work.

How does CSS Grid compare to CSS Flexible Box ("Flexbox") for user interface design? According to W3C:

* CSS Grid "defines a two-dimensional grid-based layout system, optimized for user interface design."[1]

* Flexbox is "a CSS box model optimized for user interface design."[2]

It looks like CSS Grid is optimized for two-dimensional layouts, whereas Flexbox is oriented around a single axis.

Are there different use cases? Do they solve the same problem in different ways?

[1]: https://www.w3.org/TR/css-grid-1/

[2]: https://www.w3.org/TR/css-flexbox-1/

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?

React is just a View layer, you can use whatever layout system you want to use with it.

I haven't dug into Pinterest's code but I imagine it's most likely a mix of Flexbox and Multi-column layouts: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Columns....

Edit: See this blog post on how to combine them to achieve the staggered effect: https://medium.com/@_jh3y/how-to-pure-css-masonry-layouts-a8....

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.

Yeah React Native uses Yoga as it's layout engine which only supports Flex box. But for React DOM you get all of CSS, warts and all!

Interesting touch for the Accessibility consideration on the site!

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

beautiful stuff

It's neat and all but I feel like there's something so utterly unnecessary and gratuitous about beautiful bouncy payment web widgets.

Makes me sad that CSS programmers make truckloads of money while other workers in the economy rot.

I don't understand what you're angry at.

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.

(1) CSS is absolutely a programming language, and a difficult one to master at that.

No, CSS is a presentational / style-sheet language.

HTML5 and CSS3 together can provide a Turing-complete environment, but on its own CSS is just absolutely not a programming language.

There are no "CSS programmers" and regardless I don't even know of any web developer who gets paid to only write CSS.

Just a healthy bit of advice, consider refraining from using absolutes when engaging in discussions where you could possibly be incorrect.

It places you in a position where you are unlikely to accept that you are wrong due to personal embarrassment.

> No, CSS is a presentational / style-sheet language.

That doesn't make it distinct from programming, you've just added more specificity.

Sorry bud, that just isn't the case.

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?

* edited to sound like less of an asshole

The leap you're making is that turing completeness is a requisite to call something a programming language. Not so.

You need to do more editing.

I'm not making that leap at all. I specifically classified turing completeness and being considered a programming separately. Read my post again.

A programming language doesn't need to be turing complete. But CSS is neither of the two.

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.

I can't help it if you misinterpret my words.

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.

> And you are still completely incorrect about CSS being a programming language.


[citation needed]


I like that you couldn't link it, because it says nowhere on the page that CSS is a programming language.


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.


(2) is exactly what RodericDay is lamenting.

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].

Beautiful work nonetheless.

[0] https://github.com/senchalabs/connect [1] https://github.com/expressjs/express

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!).

There is a section in the post about how they handle fallbacks for older browsers.

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...

Well, this isn't so convincing.

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.

Yes, that thread is four years old, but the latest comment is _2_ days old... So they are still having issues apparently.

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.

Only a few people seem to have issues communicating with them. Weirdly I've not had many issues.

Certainly a lot better than some payment providers I've worked with

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact