4 ms·
I suppose a better question is "Why aren't you using a framework that automates 90% of your CRUD?" There are lots of those. Rails is the obvious one to point
by jasonkester 9y ago
I suppose a better question is "Why aren't you using a framework that automates 90% of your CRUD?"
There are lots of those. Rails is the obvious one to point to, but there are dozens of others built in the late 00's that all tried to recreate that "20 minute DB-Backed Blog" demo.
I imagine the answer (to my question, and thus yours) is that fashion changed. Everybody wants to build Single Page Apps today. For everything. Even when it makes no sense whatsoever to do so.
So you find yourself dragging in a few megabytes of javascript just to render your static blog page. And you have all the power that made sense for the engineers at Facebook to use on their newsfeed, where things would regularly change behind the scenes and the page needed to re-render and re-flow itself several times a minute without the user noticing, for which a brief 3 second "flash of empty container" was a reasonable trade-off. And you use none of that power on your page, but you have it there in reserve, just in case. Because that's what The Trend has told you to do.
Step back and build some pieces of your site with tools that can look at your database and spit out some sensible defaults for CRUD screens, shamefully pre-rendered on the server as they may be, for the pieces where it makes sense to do so.
- pastullo 9y agoFully agree with you. If you use Ruby on Rails (but any modern full-stack framework would do the trick), building a CRUD is indeed 90% automated already. All you have to do, and that's where the value lies, is putting the bricks together and building the other custom 10%. Modern full-stack web framework have pushed productivty to an unprecedented level.
- astrodust 9y agoRails handles 90% of your needs out of the box. As a developer your job is to add the other 90% of the functionality the client wants.
- davidjnelson 9y agoHow does rails help you automate 90% of the creation of the angular or react single page application ui?
- LargeWu 9y agoTell me about it. I'm currently working in a javascript shop where we recently finished a 4 month react project with 5-6 full time developers. The website had about 10 pages, with about half a dozen forms, all but one of which were very straightforward, and not a ton of fancy UI. As an experienced Rails developer, I could have built the whole thing myself in about a month and a half. Less if the html was provided. There was absolutely no reason to build this thing in React. But, the architect and lead dev have decided we're a javascript shop, damn the torpedoes. For certain things we do it makes some sense, but mostly it just slows things down and makes development unpleasant.
- dabockster 9y agoCurrently working in a Wordpress shop. I feel your pain. Because the client might want to blog in the future, so we build everything in Wordpress with this one theme based in ZURB Foundation developed by one guy that incorporates its own build system in Gulp for Sass that breaks the Wordpress theme engine if you don't have the files in the right places. Ugh.
- davidjnelson 9y agoI hear you. Even back in 1998, I could bang this stuff out immensely fast with perl, cgi.pm, and a few libraries I created for reuse. The thing is, the user experience of these Web 1.0 apps is absolutely subpar to that of a modern single page application.
- andrei_says_ 9y agoWhat’s ironic is that Rails’ turbo links improves CRUD performance almost to the point of an SPA with close to zero impact on complexity. Unnecessarily building websites as SPAs, while likely assuring employment for many, is a suffocating experience, especially in the long run. I just can’t make myself do it.
- 1ba9115454 9y agoI absolutely agree with this. With turbolinks I get the fast page load feel of SPA with much less code and a far superior and maintainable architecture.
- davidjnelson 9y agoOther than 37signals, which large tech companies do this? Large tech companies have smart engineers. If turbolinks really were better, why haven't they caught on?
- mattmanser 9y agoI sometimes suspect it's because most web development is boring and to make it interesting smart devs make tools and frameworks instead, even when it's not really appropiate. Is the Facebook interface today significantly better than it was 5 years ago? No. But they've invested a huge amount of time in React in that time, so why isn't it?
- godot 9y agoI'm going to play devil's advocate here. I totally hear you re: everything being built in React nowadays and SPAs are annoying both as a user and a developer, I definitely feel like that sometimes. But the answer to your question, why isn't Facebook significantly better than it was 5 years ago, is exactly because they've invested a huge amount of time in React etc. and now utilize them fully to build many more features on top of it. 5 years ago, your notification bubble would often go out of sync. Your inbox chat might be on a separate page (can't remember if they had the bottom chat bar in 2012 yet). Even if it was, it definitely did not have video chat and voice call straight from that. Notifications didn't appear at the lower left in addition to the notif dropdown. I could go on forever. It is very similar to mobile phones cpu/memory and battery. Battery tech is getting better and better, why do phones in 2017 still only last < 24 hours, instead of 3 days? It's because battery got better, all the phone manufacturers (Apple, etc.) made use of that extra power and put better cpu/memory in their phones. Now if phones have better and better cpu, why are newer phones in 2017 still feel as sluggish as the ones in 2007? Again, it's because the phones have better cpu now, mobile OS and software developers put more and more features in their code and make use of all that extra cpu resources.
- davidjnelson 9y agoUsers won't be happy these days with user interfaces which are not single page applications unfortunately. So we need "rails for react", or "rails for angular".