They were using Angular - enough said.
Breaking up with JavaScript front ends
141–150 of 433 posts
Re: Breaking up with JavaScript front ends
#142Stop breaking my god damn back button!
Re: Breaking up with JavaScript front ends
#143Earlier quoted context omitted.
That might sound convincing to someone who already prefers working on the backend, but you can basically invert your statement to describe a typical serverless setup: “You need a frontend anyways. Shifting to a client-side codebase is eliminating duplication, and arguably browsers have better DX so win win.”
Most backend developers are used to maintaining high quality codebases, however. On the other hand...
Uhh. Cheap shot, very constructive…
Re: Breaking up with JavaScript front ends
#144The biggest problem facing the front-end space today isn't so much of complexity of a particular library, rendering technique, or view/model architecture, but rather lots of bad ideas glued together, creating nightmare scenarios for companies trying to maintain products. A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea. Using un-opinionated "librar…
To me one of the unsung skill sets of the industry is tool selection. The ability to look at a tool and imagine how it’s going to behave for different pay grades of coworkers, different specialties, and to predict how that will pan out in the future.
Sometimes you pick the simpler tool, and hope it has legs. Sometimes you tweak your product roadmap to dovetail with the tool’s. Sometimes you push to get 25% of a feature set released so you can make progress. Sometimes you temporarily add another tool, and sometimes you fork for a while.
What most people just do though is measure power of the system, ignoring the Principle of Least Power for third party code, if not in fact for the entire project. Approachability is often better than power. Quickly knowing what a tool can or cannot do is generally more productive and results in less politics (who hasn’t worked on a project where person A keeps criticizing Group B for not knowing the framework can just do the thing they wrote, but it’s not immediately obvious that it can? That’s someone tearing down the team to boost their own ego. I don’t like it. I liked it even less when I was the one doing it. Don’t be That Guy, he’s an asshole)
Re: Breaking up with JavaScript front ends
#145[deleted]
Re: Breaking up with JavaScript front ends
#146Earlier quoted context omitted.
Alternatively, web developers could calm down and just write mostly HTML with some plain javascript where warranted. I've recently done some web development for the first time in 12 years, and I was horrified at all these pointless frameworks that break every usability win web browsers have made in the past 20 years, cost extra bandwidth and have atrocious performance. Like, why? Can web devs really not learn the 4 f…
Gmail is just poorly written. The old version of Gmail was still an SPA, and it was perfectly quick.
Well, get ready for it. GitHub is moving towards React, Next, etc. I bet it will be another disaster like Reddit.
Re: Breaking up with JavaScript front ends
#147(2016)
I summon @dang in attack mode.
Can you add (2016) to the title? Thanks
Re: Breaking up with JavaScript front ends
#148Seems like a half-baked agency-built version of htmx[1], no? I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke ro…
I've tried to use htmx exactly two times. Both times it just ran directly into a brick wall, because it's so limited and has no escape hatch where you can put your own logic. Their solution to this is their half baked new language, which isn't ready, a new language, and seems very much unclear. All they needed was proper hook points.
In my opinion Unpoly does this in a very nice way, with what they call “compilers”.
Re: Breaking up with JavaScript front ends
#149I still don't consider myself a veteran but I saw the web evolves from 2010 up til now. And imho we took a wrong direction. Web apps and pages have become so bloated and complex that's crazy.
I'm just starting to recover from my previous work. I had to maintain migrate and add features to a legacy system (built in 2017) which had initially a GraphQL api and a SPA, but that was later split in 12 microservices (with cycling dependencies because hey why not) and 3 Big react applications, all of that in Javascript + Typescript (added later with all the gradual typing stuff that makes you think that your code is correct).
All of that to serve 300 monthly users between 35 and 50 years old, who just cared about filling forms here and then and have some charts over data. 0 rocket science.
So far I remember history going like this: - 2010 Clean SSR with rock solid boring technologies and some vanilla JS where it made sense, I remember page load where crazy fast and you could not feel the need for an SPA. - 2012 NodeJS arrives. It came to save us from slow blocking IO apparently (??) - 2016 React arrives. It came to save us from boring old SSR apps - 2017 All React + SPA frameworks (in house often) - 2017+ Someone has the brillant idea to do SSR with React. "It's a revolution" - 2017 GraphQL arrives. You are saved. - 2020 Nextjs arrives. You can now do static generation for SEO and SSR and apis ! That's great. Thank you Next ! - 2022 Someone wants now to do Server Component that will make your page load going insanely fast (which we already did in 2010 when we carefully loaded vanilla JS at the time)
I learned a bit of ASP.net core recently, and I think that boring razor pages are still relevant.
I remember my first lead in 2010 telling me that ORMs and SPA where completely overrated. I didn't agree with him at that time. Now 12 years later I think he might have been correct.
I'm not saying SPA have not their place. Some apps can't do without it. I'm saying that we are victims of "hype driven development" which involve having some trendy hashtags in your resume and convince your manager that you have seen an incredible new tech that will make the business incredibly wealthy. Except it does not and you end up with a legacy system that nobody wants to maintain because too complex.
Maybe like Jonathan Blow stated in one of his videos, we make a confusion between going forward and progress. Now all the new kids learn React in some boot camp or online but have no idea how to implement a map function. And I feel old and grumpy. And tired by all this.
Re: Breaking up with JavaScript front ends
#150Seems like a half-baked agency-built version of htmx[1], no? I'm actually very intrigued by the whole "let's take a step back and move a lot of our logic back to the server" approach to modern dev, but IMO when you need more than statically rendered pages, it should look a lot more like htmx or Phoenix LiveView (if you're using a framework) or something ultra-minimal like Slimvoice[2] if you want to go the bespoke ro…
My problem with liveview IMHO is that it requires an active internet connection and doesn't have offline support, which is a step in the wrong direction in terms of UI performance to me. It makes sense for a subset of applications that require connectivity but many apps or tools should be able to work offline or without a constant connection.
Livewire is intended to be used where you’d otherwise need to do an API call anyway. It is not intended to handle every single click and toggle and key press. You still do that on the front end, usually with Alpine.
It is a way to avoid writing backend APIs.
If you’re sending every click or every key press then it’s not the tools fault. I agree though, that this should be better explained in their docs.