I haven't scroll the whole way through, and am a complete novice to webdev but this is reminding me of htmx a little. Is it just me?
Unpoly predates htmx by a couple years.
Breaking up with JavaScript front ends
261–270 of 433 posts
Re: Breaking up with JavaScript front ends
#262Implementing these library/frameworks are just a small piece of the application. You implement strict development policies and standards that these frameworks wrap around, fit within the architecture. Too many devs rely on the framework to be the architecture.
A SPA is a piece of an overall architecture and these frameworks are still just a piece of the overall architecture.
Almost all of these frameworks can/will assist in strict standardization. Bootstrap is a good example. BS with a well designed style guide is a blessing, without it's the wild west. Angular, React, Vue are all very useful (back button included) if thought out and as part of an architecture.
In the end, they get you much further along with support, than a team could do with vanilla.
Re: Breaking up with JavaScript front ends
#263The usage of browser history for this page is un-ironically a nightmare.
Re: Breaking up with JavaScript front ends
#264What'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…
Probably the right place to ask this:
The slide said
> DEMO OF SERVER-SIDE APP ISSUES
> Link to demo app (https://demo.unpoly.com/)
> (press Start Classic on first page)
but there is no “Start Classic”?
Re: Breaking up with JavaScript front ends
#265I 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 cy…
> ASP.net core recently, and I think that boring razor pages
Came to a similar conclusion lately. It's a superior, cleaner alternative to traditional MVC controllers. Currently building a side project with Razor Pages + HTMX.
Re: Breaking up with JavaScript front ends
#266Welp, I couldn't back out of that site after making 100 url changes. Your argument would be a lot more convincing if you addressed that issue. That's such an old issue, please don't bring that back with your new throw-back style.
This is a slide show presentation. The website is here: https://unpoly.com/
Re: Breaking up with JavaScript front ends
#267Your first problem is you're using Angular.
There are ways to keep things simple with the front end, only add js for the things where you want instant visual feedback. It requires a little pushback on the part of the dev team, against UX and Product management.
Re: Breaking up with JavaScript front ends
#268Wow. So much complexity here that they seem to not realize that they've added. Feels like they're just replacing one problem with another, rather than solving anything.
Re: Breaking up with JavaScript front ends
#269Clients are getting more interactive over time. People want more interactivity, not less. Interactivity increases with visual complexity, which in turn requires increasingly complex code. UIs are evolving in the direction of more realtime updates, more animations, more menus and options, etc., etc. It's no coincidence the most popular frameworks are analogous to video game game engines. They both listen to user input…
> People want more interactivity, not less. Nobody cares about "interactivity" or "immersive" experiences except the devs who make them. People want to get their shit done as quickly as possible using software that feels simple and works as they expect the first time. A SPA might be the best way to achieve that. But often it isn't.
That's not what the trend shows. Apps have added more interactivity like live chats, conferencing calls, more editing options (i.e. editing videos when uploading to YouTube), and this is probably going to keep going adding things like voice commands, customizable layouts, and more realtime information being displayed at any given time. The reason it converges with video games, is because both are clients and both process lots of user inputs and then display the result to the screen.
edit: i should add I'm not saying it's ALL going this direction, but certainly the big apps with lots of users.
Re: Breaking up with JavaScript front ends
#270Earlier quoted context omitted.
Tools like htmx aren't the reason the gmail tab uses a GB of memory. You'll find the majority of cases where pages are using way more resources than it should, are due to reasons forced on web developers, like a billion different trackers and several different ad networks, and workarounds to ad blocking to sell more subscriptions, etc. This is what is so shocking to me when HN spends such an absurd amount of time ral…
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…
Well google use all of their own internal 'frameworks', so you can't really use their web applications to judge the rest of the web.