Live data from Hacker News

Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript

shopify.com

21–30 of 49 posts

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

#21
post #7

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.

Can we please drop the "cool kids" cliche? It's a tired generalization.

Worse, 'cool kids' implies doing something because someone else is doing it rather than because it's the right thing to do in your organisation. It smacks of cargo cult behaviour - copying actions and hoping to get the same end result without understanding why.

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

#22
From the perspective of someone deeply rooted in UI development for the desktop, seeing stuff like this makes me glad I am deeply rooted in UI development for the desktop. If I had to build a Cocoa app with this messy, complicated shit ... I'd blow my brains out. All over my desk. Maybe I'd leave a note, but I think people who knew what I did for a living would get it and not need me to leave one.

It also makes me wonder, how we've all decided that HTML is the way to go for this class of application, how hacking a document display format to ape a native UI is a good idea.

I have to think that at some point people think that there has to be a better way to deliver a network transparent, portable UI without worrying about strange things like a Shadow DOM, the hack that is CSS, and all of the other weird shit web developers have to put up with to create something that mimics (usually poorly) a desktop app.

Like is there a breaking point where people are like "fuck it" and come up with an alternative browser that is specific to this and similar kinds of applications? I guess not because the gray line between what HTML is good at and what people need to HTML to do despite itself is a pretty big fat line.

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

#25
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 guess the key bit of the article is:

"These frameworks work well for highly interactive apps with complex user interface requirements. We only needed a small piece of what a full framework would offer."

As you say its a tradeoff...

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

#26

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.

Yup, also a good reminder that you need to constantly question the design decisions as you go (on an almost daily basis).

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

#27
post #22

From the perspective of someone deeply rooted in UI development for the desktop, seeing stuff like this makes me glad I am deeply rooted in UI development for the desktop. If I had to build a Cocoa app with this messy, complicated shit ... I'd blow my brains out. All over my desk. Maybe I'd leave a note, but I think people who knew what I did for a living would get it and not need me to leave one. It also makes me wo…

Things are not that complicated today,really.It's just that there isnt only one way to do things.

> I have to think that at some point people think that there has to be a better way to deliver a network transparent, portable UI without worrying about strange things like a Shadow DOM, the hack that is CSS, and all of the other weird shit web developers have to put up with to create something that mimics (usually poorly) a desktop app

It already exists : GWT,or you can use something like C++ and the emscripten toolchain,and whatever C++ gui framework. So if you dislike all the js/html/css you can definetly avoid it.And users dont care,provided it runs in their browser without plugin.

Most webdevs wont use these because they already know javascript and there are good frameworks out there.

And at the end of the day it is still a webpage,it's not a desktop app.

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

#28

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.

On the other hand I had to develop a small admin framework and decided to do it with server rendering since I thought it would be easier. I soon found all the small details I needed to think about and that there were a number of server side components/files that I had to create to do what I wanted to do. It would probably have been easier to just do it in the SPA framework I am used to (Angular).

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

#29
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 guess the key bit of the article is: "These frameworks work well for highly interactive apps with complex user interface requirements. We only needed a small piece of what a full framework would offer." As you say its a tradeoff...

But one of the nice things with Angular is that for small things you can get away with almost no code at all, small controllers that isn't really depending on each other for example. It is when you start on a larger system you have to think about splitting your app into services, controllers and templates/views and sending information between all those things.
Post reply on HN