4 ms·
When you are writing web APPs, you don't have to move as much logic to client as possible. I was writing web apps in 1998, with table layouts, almost no CSS an
by jiriknesl 2y ago
When you are writing web APPs, you don't have to move as much logic to client as possible.
I was writing web apps in 1998, with table layouts, almost no CSS and no JS.
Of course, it was simple. It was so simple you can't imagine how. And it was the simplest in the golden age of MVC frameworks (like Django, Rails, Symfony) some 10-15 years ago. Since that, everything went downhill.
Building sign in form or some simple form with validation and saving in database was 2 hours of work, 4 hours with testing and deployment. Salaries of devs were 1/4. Now, it takes 2 days to make a simple form, backend API, sync two states, run it via myriad of builders and minimisers and deploy it to production.
Development now is 4 times less productive, 16 times more expensive for marginally better UX.
- fragmede 2y agoI mean webpack is slow, and css can be annoying sure, but c'mon, 2 days? I'm having trouble seeing that take two days unless you're doing a lot more than a form with two text input boxes and a button for signup and one for login in the modern version, which would make it an apples to oranges comparison.
- jiriknesl 2y agoIt's not just 2 input boxes, unfortunately. It's also a backend part, adding sessions, requiring the user to be signed in. It is also sign out functionality. In MVC framework, you just annotate a bunch of controllers, import Sign In and Sign Out functionality, and you are all set. Another examples might be building data grids, CRUD functionalities, or more complex validation situations. Back then, you designed database, generated CRUDs, it automatically added Bootstrap CSS compatible classes. You added one beforeSave handlers to add extra logic, and it was done. We web developers had to be competitive, because our competition were people using tools like Delphi, where you could drag'n'drop 30 screens in a day. It was ugly (default Windows 98 WinAPI look), it wasn't responsive, it wasn't prepared for people with disabilities, but it was hyperproductive.
- dlisboa 2y ago2 days is fast. OP left out that most companies nowadays run a separate front end team, so now you need your backend team and front end team to have a meeting about what proper JSON should be returned, then the front end mocks that response and implements the form behavior, all the while the backend implements server functionality, then someone else (usually) tests this integration, then someone else deploys it. If nothing in that multi-team communication pipeline breaks you’re very lucky. If you can all get that done in 2 days you’re running a very fast dev team. Minus the QA and DevOps team my point is that a SPA/JavaScript-heavy web app is not only a technological choice but an organizational one. Things used to be faster because there were fewer divisions in the software, therefore fewer divisions in the organization.
- evilduck 2y agoExpectations have also changed in various ways since "the simple days" when devs were the product managers, the implementors and testers all in one. Some things are better now, some things are worse. I used to be able to churn out a form, naively, in two hours because I could just implement the elements, inline style them, give them a name and then go implement the backend form handler. Now there's a checklist of requirements: does it implement our design system, does it have test id attributes, is it responsive, does it work with password managers and auto populating form fillers, does it support internationalization, does it support multiple languages correctly, does it provide client side data validation, does the server return errors correctly and how should they be displayed, does it have rendering tests, does it have end to end tests, and so on and on and on. Most of this isn't needed for a personal project or proof of concept but for a reliable product that millions of people use globally, a lot of it is table stakes or legal liability. You can certainly do it server side too, but the two hour effort window is still gone.
- lakomen 2y agoThis simply isn't true. You are stuck in the past and unwilling to adapt and learn new, in fact, better alternatives. I'm currently using Go with Ent and Gqlgen and Relay extension on the backend and React vite with Relay graphql client as well as React-oidc-context for oidc with zitadel as the oidc idp. It doesn't take 2 days to make a simple form. You need to get put your comfort zone and learn. I built a classifieds site in 3 weeks. Including admin ui. I'd call that as productive as it gets. There's currently as library in the works where you will be able to tell generative AI to make a frontend just from showing it the graphql schema.
- yellowapple 2y ago> I'm currently using Go with Ent and Gqlgen and Relay extension on the backend and React vite with Relay graphql client as well as React-oidc-context for oidc with zitadel as the oidc idp. That sounds way more complex than even the average Rails or Django app, let alone the Good Ol' Days™ of CGI scripts.
- jiriknesl 2y agoI am not stuck in the past. I moved to Clojure and jumped to devstacks just like everyone else. Speaking of generative AI, I use and pay for v0 for frontend generation, tried Contember to generate backends from specification (the CEO is a guy I know for almost 2 decades), I pay for Cursor, ChatGPT, Claude Sonnet. I moved from Bootstrap to TailWind (which I don't like, to be honest). But honestly, many things are just much slower than something like Rails/Django/Laravel+Bootstrap.
- nymanjon 2y agoYou might like Yohn's PicoCSS. It encourages semantic HTML everything is ready for you out of the box and he added some features that give it a little Bootstrap utility feel. https://yohn.github.io/PicoCSS/ https://yohn.github.io/PicoCSS/ The "secret" to using these types of CSS is: ```css @import url("/css/pico.min.css") layer; ``` This makes it so there is no usage of `!important` anytime you need to make your own CSS and it would normally be difficult because of the base CSS library you are using. It's nice having everything working out of the box and when I need to override anything it's easy peasy.