[deleted]
Breaking up with JavaScript front ends
291–300 of 433 posts
Re: Breaking up with JavaScript front ends
#292Earlier quoted context omitted.
I agree with everything you say, but I'm in the camp that thinks that front-end is stabilizing. I feel many web projects can go a long way with something like NextJS, a few classic libs (eg, lodash/underscore/ramda), maybe a few libraries for handling data if you really need them. The design frameworks (MaterialUI, Tailwind, etc.) are also fairly stable. Perhaps that's one dependency too many for some?
Next.js is really bad, IMO and perpetuates more bad practices. Both Target.com and Walmart.com are Next.js apps. Both utilize SSR to render the pages (view the markup in the network tab). Both then STILL send the full data model to the UI (check the `__NEXT_DATA__` on Walmart.com and `__TGT_DATA__` on Target.com) because Next.js doesn't quite offer the right amount of control over what to send back (compare this to A…
Next.js also get into many of my govt's websites. It's the worst in any direction. I can explain why with bullets but so tired of these repetitive well-known reasons already.
Re: Breaking up with JavaScript front ends
#293This reminds me a lot of frames [1]. I wonder if the creators are aware that at one time html did have a way to update different parts of a page independently, but due to various limitations, it fell out of favor and is now deprecated.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fr...
Re: Breaking up with JavaScript front ends
#294Earlier quoted context omitted.
According to my browser, the default view in gmail needs 8.32 MiB of javascript spread over 90 files to render. While IDLE, the gmail tab uses 10-30% of an M1 CPU core. That stuff is not down to tracking - it's because the damn thing keeps messing with the DOM, because it has some insane structure where javascript controllers are attached as strings to DOM elements, because it uses about 100 divs to render every row…
What browser are you using? Having Gmail open doesn't even use half of a percent of a single core on my machine (Linux, x86, Chromium).
Same for macOS, Chrome. CPU sometimes jumps to 3%, but that's about it (and I guess that's because it uses slow core).
I have very clean mailbox, though.
Re: Breaking up with JavaScript front ends
#295Earlier quoted context omitted.
I find it funny that the library that you think is helping to stabilize the front-end is called "NextJS".
It's becoming a standard, and yes, I personally like it. There's plenty of other great choices if you don't like it. And even some of the up and coming libs, like SolidJS, feel stable compared to the 2010's - they add incremental improvements but keep things that some people really like, like JSX. In the early to mid 2010's everyone was reinventing the wheel constantly.
Everyone says their favorite library "is becoming standard". The rest depends on marketing budgets.
Re: Breaking up with JavaScript front ends
#296Earlier quoted context omitted.
Throwaway for anonymity. I work at a place that is mostly like this, I can tell you that using html/css/javascript raw, with a bit of bootstrap is a nightmare with a SPA. Menus are constantly broken, back button is a game of roulette, caching is constantly a problem showing stale data, xss and other vulnerabilities are ubiquitous. There are modern affordances in many of these frameworks others take for granted.
The problem was choosing an SPA
Precisely. There was someone here bemoaning how difficult it was to follow generic advice of using profilers to optimise hotspots in the application code.
He started off with something like: "Why don't you try your 'simple' techniques in a tangled web of hundreds of microservices written in different languages and running on different platforms?"
It's like some people can't see the forest for the trees.
In the last few years, I've come across about half a dozen existing web sites with hideous performance problems, all of which should have been vanilla HTML but were written as Angular monstrosities. The same teams -- against repeated advice -- have started new Angular projects for sites showing static data, anonymously, to the general public.
They start off conversations with "We'll need a web app, an API app, a mid-tier, a service bus, and then this, and then that..."
It's madness.
Re: Breaking up with JavaScript front ends
#297Needs a (2016) in the title. The situation is even worse now.
I would say things are improving. Through WASM we are now getting more languages running in the browser. They are starting to bring alternative frameworks and ways of doing things to the table as well. Instead of this frontend / backend notion, we should start thinking again about the notion of networked applications; like we used to do before the web became a thing.
Inevitably you want some computation to be close to the source data (for efficiency) and some other computation to be close to the point of interaction (for responsiveness). It's not an either / or proposition. You can do both. And phones and browsers can do a lot locally these days. So there's no need to pretend that it is still 1999 in terms of browser capabilities. They can do so much more now.
Instead of AJAX, we now have companies like Tailscale doing all sorts of funky networking stuff in a browser. Likewise, people are running entire 3D games, photo and video editing tools, or design tools like figma, etc. in a browser. All enabled by WASM. Most of that stuff does not involve a whole lot of css, javascript, or html. That stuff is increasingly optional. Browser application development and desktop application development are finally merging after being considered completely separate things for more than 2 decades. It's all just application development. It may or may not involve talking to servers via a network. You don't have to limit yourself to HTTP when doing that.
Re: Breaking up with JavaScript front ends
#298Earlier quoted context omitted.
it'll be stable when the JS community stops reinventing the wheel several times a year. Every year we have the 'next big thing' and a whole new JS framework and ecosystem thats set to be the one to beat them all. Fast forward 2 years, its mostly abandoned and upgrading a 12 month old project is a nightmare. That is not stable. I can pick up a PHP, Python, script written 2-3 years ago and know it'll work if I try to d…
I've been coding my front-ends in React for 5 or 6 years. I don't have any of the problems you describe, I can also pick up old projects and run them without much problem. There was the change from classes to hooks but I still remember classes fairly well. Then there's been NextJS which I've picked up in like a weekend. That's it. There are new frameworks popping up all the time. Some look very interesting. But React…
"I haven't died playing russian roulette, you should try it too."
The general experience across the industry in a statistical sense is that JavaScript frameworks are a tyre fire best avoided.
I'm yet to see a JS app that doesn't need constant maintenance to remain compilable.
Meanwhile, the ASP.NET ecosystem had like one significant breaking change since like... 2002.
Re: Breaking up with JavaScript front ends
#299The complexity of the modern web is very off putting to me, but I'm an old timer that spent too long in the land of infrastructure.
I'm doing something similar to HTMX or HotWired, but with 100% vertical ownership. I posted about this some time ago: https://www.adama-platform.com/2022/06/26/making-html-the-be... ; where I am at today: https://book.adama-platform.com/rxhtml/ref.html
The core thesis is to turn the browser into a RIP terminal ( https://en.wikipedia.org/wiki/Remote_Imaging_Protocol ) to some degree where the server is 100% in control like a BBS/MUD. As an example app, the main IDE uses it, and it's great how lean everything is.
I'm enjoying going my own path.
Re: Breaking up with JavaScript front ends
#300What's the accessibility story for Unpoly? I'm always interested in ways of building partial page fetches, dropdown menus etc in a way that is thoroughly tested to work well with common screenreaders. I'd love to see a frontend framework that includes detailed documentation (and ideally video demos) demonstrating how effective their ARIA screenreader stuff is.
Unpoly lead dev here Unpoly takes special care to always move the focus to the next relevant element in an interaction. E.g. when a link updates a fragment, the focus is moved to that fragment. Or when an overlay is closed, focus is returned to the link that originally opened that overlay. More details can be found here: http://triskweline.de/unpoly2-slides/#78 Feel free to install a screen reader and play with the d…
This is excellent - thanks for the reply. Those slides answered my question really well, and it looks like you've put a lot of thought into this.