Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript

shopify.com

Post reply on HN
Print view View original

11–20 of 49 posts

Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript

#11

Post by aikah »

So AFAIK they send html back to the client right? that's my understanding of turbolinks

The problem with this is that it makes client and server tightly coupled.One cannot update the client app without touching the server code.

I understand that's a tradeoff but I think a restful architecture serving only json/xml data is better. And you dont have to duplicate logic that much.If any validation needs to happen clientside,create some validation resource for each model and do it entirely serverside for instance. Even SPAs dont need fat clientside models or a complex service layer on the client.

Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript

#14

Post by matthewmacleod »

aikah wrote: post #11

So AFAIK they send html back to the client right? that's my understanding of turbolinks The problem with this is that it makes client and server tightly coupled.One cannot update the client app without touching the server code. I understand that's a tradeoff but I think a restful architecture serving only json/xml data is better. And you dont have to duplicate logic that much.If any validation needs to happen clients…

I don't know that what you've identified there is actually a problem in practice – I'd wager that in a system like Shopify's admin, the client and server are inherently coupled regardless of what architecture you choose. Trying to abstract to a client-side app and JSON API in these situations often results in more complexity for few benefits.

Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript

#15

Post by Joeri »

matthewmacleod wrote: post #14
aikah wrote: post #11

So AFAIK they send html back to the client right? that's my understanding of turbolinks The problem with this is that it makes client and server tightly coupled.One cannot update the client app without touching the server code. I understand that's a tradeoff but I think a restful architecture serving only json/xml data is better. And you dont have to duplicate logic that much.If any validation needs to happen clients…

I don't know that what you've identified there is actually a problem in practice – I'd wager that in a system like Shopify's admin, the client and server are inherently coupled regardless of what architecture you choose. Trying to abstract to a client-side app and JSON API in these situations often results in more complexity for few benefits.

If you have multiple front ends on top of a shared backend, like a desktop and mobile UI, as well as a bunch of third party integrations, then it makes a lot of sense to build the API first. The thing is that it requires three different use cases before you can make an API generic enough to cover the majority of the needs, and that makes it difficult to build the API first and UI later. I believe in the approach, but it's not the right way to go for everybody.

Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript

#16

Post by cageface »

With all the buzz around SPA frameworks like Angular or Ember it's a worthwhile reminder that there's a still a lot of room in the world for more conventional server-side rendering approaches. Not every web app needs to be an SPA and old-fashioned Rails apps can be a lot simpler to implement.

Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript

#17

Post by matthewmacleod »

tericho wrote: post #7
carsongross wrote: post #5

Money quote from the article: The new admin would make a return to more classic architecture with some modernizations. Our approach would be ERB views and server-side rendering, with the use of Turbolinks, and a lightweight custom JavaScript binding system. This allowed us to tackle problems of code duplication and developer productivity in a single blow. As always, the devil is in the details and I'm looking forward…

Can we please drop the "cool kids" cliche? It's a tired generalization. Clearly at this point both architectures work, it's childish to see this as an argument for server-side rendering. Obviously it works, so do client MVC systems. The value in this article is the humble detailing of their mistakes that many of us also experience in our careers.

I think part of that is a reaction to how many people jumped on to the client-side JS framework bandwagon very early, because it was "the next big thing", but before the tools were ready for production.

I've had to deal with more than my fair share of crappy, hacked-together Ember apps that were developed like this. There have been too many breaking changes to upgrade, performance is bad, an they're full of hacks to work around deficiencies that existed back then.

Even though we actually have production-ready frameworks now, that sort of thing can leave a bad taste in your mouth. Especially when you see the same mistakes made by people jumping onto the Meteor bandwagon, for example. But it's defintiely something to try and get over :)

Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript

#18

Post by matthewrudy »

matthewmacleod wrote: post #17
tericho wrote: post #7

Earlier quoted context omitted.

Can we please drop the "cool kids" cliche? It's a tired generalization. Clearly at this point both architectures work, it's childish to see this as an argument for server-side rendering. Obviously it works, so do client MVC systems. The value in this article is the humble detailing of their mistakes that many of us also experience in our careers.

I think part of that is a reaction to how many people jumped on to the client-side JS framework bandwagon very early, because it was "the next big thing", but before the tools were ready for production. I've had to deal with more than my fair share of crappy, hacked-together Ember apps that were developed like this. There have been too many breaking changes to upgrade, performance is bad, an they're full of hacks to…

Ember now feels like a complete framework, but fundamentally any Ember app will be tightly coupled to Ember the framework.

In many ways this is the same as Rails Apps have traditionally been very much tied to Rails.

Having worked on many Rails Apps that have grown beyond the scope of the framework, the apps I build today are as decoupled as possible from the framework.

I hope that the Ember community can grow in that direction too, and at a distant look, it feels like Web Components will be that method of decoupling.

Right now I tell everyone that I'd never render HTML (or JS) on the server, and I hope that JS frameworks will keep maturing with my clients' needs, so I don't have to renege on that approach.

Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript

#19

Post by adrianhoward »

Bahamut wrote: post #3
coldcode wrote: post #2

While it's refreshing to see people talk about the things they did wrong and how they intelligently approached fixing them, building your own javascript framework from scratch (batman) is something I would have said no to from the start. Not for the faint of heart or those who have not suffered such an endeavor before.

If I had to guess, none of the solutions back then sufficed for them. Batman has been around for a while.

Yeah. I've made that kind of decision a few times in the past — do we use NewFramework or do we develop our own.

It's a really tough call. I've been wrong (and right ;-) multiple times going down either path.

The last time I had to make that sort of choice we went the set-based design / real options path and developed both in parallel for as long as we could. More expensive, but lower risk. I'm glad we did coz the decision we made four months in on which one to drop wasn't the one we would have made at the start.

Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript

#20

Post by iagooar »

mabbo wrote: post #9

My teammate and I compete to see not how much code we can write, but who can have the highest sum of lines deleted in all commits. Any old hack can write a lot of code, but to remove code while still adding functionality (or at least, not removing it) is the sign of a good developer, imho.

We do that too, in our team. Reminds me of: http://delete-your-code.herokuapp.com
Post reply on HN