Wondering why Shopify redirected my request on that post URL to http://www.shopify.co.id . Ngghhh, i can't read those sweat post :(
Try: http://webcache.googleusercontent.com/search?sourceid=chrome...
Thanks!
Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript
31–40 of 49 posts
Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript
#32Earlier 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.
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.
I think it's actually the exact phrase we should be using. I work with helping beginner programmers learn to code and if they want to know "javascript" (they don't even know what that means) they are always asking for ember/angular/node and when I ask why they want to use these technologies or what project they are working on that would benefit from that style they blank. It's definitely cool kid syndrome.
Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript
#33A little bit OOT, i need to connect to my VPN in US to be able to see the post. It is always redirect to my country's TLD (www.shopify.co.id), in which there is no related link ( http://www.shopify.co.id/technology/15646068-rebuilding-the-... )
Ah, this is a bug in our redirect system. I will look into it.
Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript
#34From 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…
This is one of those religious debates that will never die as long as the web exists in a similar capacity as it does, today.
The fact of the matter—whether we like it or not—is that these are the tools we have for web development. It's hacks on hacks on hacks, as one might expect in a suite of technologies originally intended for X but arguably powerful enough to perform Y, Z, and Z(2014). Take ECMAScript: the first draft was written up retroactively, quirks and all. Many of the oddities and edgecases were written into the official language spec and vendors were encouraged to implement them as written (thus, intentionally writing engines with quirks).
But the fact remains that no single, "fuck it" has been able to take hold. The technologies we have at our disposal have proven themselves "good enough" to keep that from happening to date. At this point, we've invested ~20 years into these technologies.
And, for what it's worth, there are ways to cut through the cruft. These things can be done moderately cleanly. It is possible to write a web-based application that doesn't make one want to blow their brains out (I'd make the argument that, in a lot of cases if you're trying to write a "desktop app" in the browser, you're focusing on the wrong thing but that's neither here nor there[0]). It's simply that legacy and twisting the language to do what we want and not what it was intended for has caused that to not be terribly straightforward.
I understand you're being hyperbolic but it's been my experience that this mindset ("this is so bad I'm never going to touch it") generally comes from folks who take one look and turn in disgust. That's fine—and I'm not going to argue it's not without it's warts because that would be insanity—but it isn't so bad that you'd need to off yourself, and I think the staying power it has had regardless of quirks, poor design choices, etc., proves that.
[0] - with the right team and the right reasons, it can be done. The Slack desktop app is a pretty good example of when it makes sense and is done quite well.
Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript
#35A little bit OOT, i need to connect to my VPN in US to be able to see the post. It is always redirect to my country's TLD (www.shopify.co.id), in which there is no related link ( http://www.shopify.co.id/technology/15646068-rebuilding-the-... )
Ah, this is a bug in our redirect system. I will look into it.
fidz: should be fixed now. Thanks for reporting this.
Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript
#36So 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.
This. We ended up creating models for the exact same stuff in both Ruby and JS. Lots of code duplication, and losing client-side performance due to deserializing JSON all the time.
Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript
#37Earlier quoted context omitted.
Try: http://webcache.googleusercontent.com/search?sourceid=chrome...
Thanks!
Commented above: https://news.ycombinator.com/item?id=8526930
Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript
#38From 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…
Sun with Java and Java applets wanted to be that. Maybe Flash and Flew dreamed of that too.
Browsers were said to render the OS irrelevant and in a way Chromebooks come close to that.
We were also supposed to not owned & store any software locally and rent & download everything. Office Online, Creative clood are there.
But things are rarely that radical and the web was there and opened. I prefer desktop apps (and I'm a web developer !) but how can you beat the ability to login to any of your web tool from any computer ?
Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript
#39Duplication and poor documentation made it difficult for developers to make changes to the admin. Once we started questioning Batman, we saw that the evidence strongly indicated it was time to move on to the next chapter.
I don't see a SPA vs Server side rendering debate in the article. Building your own framework was the problem, is not a core competence of Shopify to build JS frameworks. Maybe they could choose other route, like going with React or Angular there.
Re: Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript
#40From 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…
HTML + CSS + Javascript is obviously far from perfect, but is there any other way TODAY to write a single piece of code that will run on just about every computing device in circulation?
Honestly, I challenge anyone to write a simple UI (lets say draw a circle and put some text on the screen) that just works across ALL major operating systems, screen sizes, versions, etc.
If do actually end up doing it in anything besides "web" languages, its going to be more complicated and take longer as well....
To make a car analogy, The Chevy small block V8 engine was/is never the best, fastest, most efficient engine. It's just that for the past 40+ years they've put the damn thing in every vehicle imaginable. It's pretty ubiquitous in the auto world....It just works and everyone still uses it. Sort of like how you will find a HTML, CSS, Javscript rendering engine in everything today...