Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

Post reply on HN
Print view View original

321–330 of 433 posts

Re: Breaking up with JavaScript front ends

#321

Post by arcturus17 »

sph wrote: post #316
arcturus17 wrote: post #171

Earlier 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?

I've heard that the frontend is stabilising since jQuery came out. Now it's the React devs saying it, but this time for real.

Nearly 10 years after the release of the library, React is by far the most commonly used framework according to the 2021 SO dev survey. It is also the number 4 most loved. [1]

I'm a React dev as much as I am a Python or C# dev. I reach for tools that I know I can build in and hire for. It's been years since I use React with a single command line to kickstart a CRA or Next app, and take it from there. Yes, there are pitfalls once you start building anything non-trivial, but so does Django which has been around since 2005 and by virtue of being back-end should be more stable.

Re: Breaking up with JavaScript front ends

#322

Post by miyuru »

arcturus17 wrote: post #229
esskay wrote: post #223

Earlier 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 was given a old unmaintained react project to build a pipeline and the only way to run it was on node 12. It would not even build on latest node versions.

Re: Breaking up with JavaScript front ends

#323

Post by atomicnature »

jokoon wrote: post #45

Why can't anybody talk about the fact that HTML was not designed for being dynamic? Isn't there any format that is a real alternative to HTML, which is truly interactive, lighter than the DOM, use text as a mediu, is multi usage and platform agnostic, can use whatever scripting language, and be easily rendered? It's not another new format, it's just that a new format is needed to make things simpler. I have zero pati…

This is on point. The frameworks will always remain crippled due to the underlying platform. Of all the things in the Web Landscape, WebAssembly seemed like a practical move towards what you are speaking about. You can compile Rust/Golang/C++ into a "Web Binary", which in turn can be shipped realtime to clients. However, there's a long way to go, before WebAssembly works as a smooth container environment with better APIs for enhancing the user/dev experience for dynamic apps.

Re: Breaking up with JavaScript front ends

#324

Post by boxed »

recursivedoubts wrote: post #250
boxed wrote: post #122

Earlier quoted context omitted.

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.

htmx is focused on hypermedia exchanges in the mode of normal HTML, so client-side stuff is out it does, however, have an extensive event model to hook into, including pre and post request processing: https://htmx.org/reference/#events as well as an extensions API: https://htmx.org/extensions/#defining for client side scripting, I think you are talking about hyperscript, which is definitely more speculative than htmx…

The hooks are very limited unfortunately.

Re: Breaking up with JavaScript front ends

#326

Post by globalise83 »

As a web developer, I can now distribute and "install" a sophisticated software application on the work or home computer of one of my users within less than a second just by sending them to a specific link, and that user can even use it offline, with a lightning-quick database saving all of their data for them. Pretty awesome if you ask me! None of that would be achievable without Javascript frontends.

Re: Breaking up with JavaScript front ends

#327

Post by phist_mcgee »

throwaway999528 wrote: post #216
heather45879 wrote: post #181

Earlier quoted context omitted.

I like to go back to the basics. It irks me that folks don’t think HTML/CSS/JavaScript are good enough as-is—but nowadays the default browser capabilities are incredible compared to a decade ago. We basically have a full programming environment and add WASM to the mix! Back in the day the frameworks were first-and-foremost a platform compatibility solution. People often have it ingrained in their psyche that reinvent…

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.

Everyone's a "pure html/css/js" gangster until they have to maintain state.

Re: Breaking up with JavaScript front ends

#328

Post by phist_mcgee »

t8sr wrote: post #100
qrohlf wrote: post #11

Seems 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…

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…

So you haven't done web development in 12 years, but you're qualified enough to call these frameworks pointless?

I haven't written Java in years so I can tell you with authority that Java 17 is terrible and we should just go back to the good old days of J2EE.

Re: Breaking up with JavaScript front ends

#329

Post by arcturus17 »

sph wrote: post #319
arcturus17 wrote: post #317

Earlier quoted context omitted.

Do you have any real commentary against Next.js not being standard, or only generic snide and feelings of superiority directed at "everyone" but yourself? I'll share a few facts about Next.js: - Their showcase: https://nextjs.org/showcase#all . The number of super-scale websites using it speaks for itself (doesn't include among others Walmart, which another commenter pointed as an example of how terrible Next.js, but…

Don't take this the wrong way, but all those impressive figures you've shown don't compare to actual experience. Some of us detractors have 15+ years doing stuff on the Web and we've seen this cycle play out 2 or 3 times. Everything is cool and the best way of animating divs, until it isn't. I do not like playing the experience card, but when someone tells me React is good and simple, it just tells me they have no id…

I built my first website in the late 90's or very early 2000's - I can't even remember. I also think I knew what simple was when users wanted very little interaction. Then in the middle between then and now, building a website with jQuery was a nightmare. So pray, do tell, what you build your websites or web apps in.

> React is good and simple

I in particular never said it was simple. React, particularly in SPA form, starts creating challenges pretty early on in regards to state management and app architecture. But I have never seen solutions to build large SPAs that don't have pitfalls.

In the SSG/SSR realm, I'd argue Next.js is quite simple.

> don't compare to actual experience

> Some of us detractors have 15+ years doing stuff

> I do not like playing the experience card

> it just tells me they have no idea whatsoever

> it just has great marketing

> Sorry to the devs which are often here to PR

> the last 20% are really where the issues (bad docs, bugs, constant churn) lie.

About 80% of your comment is how much better, experienced and genuine you are than everyone else - as opposed to us schmucks you accuse of doing "PR", you are here to deliver simple, unadulterated truths. I would've engaged with any technical points you had made, but since there aren't many to speak of, I guess what's only left for me to say is that it's fantastic that you feel so good about yourself.

Re: Breaking up with JavaScript front ends

#330

Post by happyweasel »

globalise83 wrote: post #326

As a web developer, I can now distribute and "install" a sophisticated software application on the work or home computer of one of my users within less than a second just by sending them to a specific link, and that user can even use it offline, with a lightning-quick database saving all of their data for them. Pretty awesome if you ask me! None of that would be achievable without Javascript frontends.

whut? You can simply distribute a statically linked binary that does not require admin rights to run? Stores its data in the local users data folder.. How big could a chat app be, for example .. 10mb? 20mb? (without excessive resources) ? With minimal memory use? Use WTL and plain platform api? Pretty doable IMHO. With a lot less dependencies and probably lightning fast dev iteration cycles.
Post reply on HN