Live data from Hacker News

Breaking up with JavaScript front ends

triskweline.de

401–410 of 433 posts

Re: Breaking up with JavaScript front ends

#401
post #355

Earlier quoted context omitted.

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

Yes, and even though a lot of tech companies killed the architect role, this is exactly the job function assigned to architects, or more specifically enterprise architects in a lot of more traditional companies.

I haven’t had a lot of luck with architects. In one case I came to a company that got rid of their architect and hired me and another person to replace him (to be fair they were too small to warrant a full time role anyway, not sure what they were thinking).

Especially in the post refactoring era, they tend to have an inaccurate account of what the code is actually like and make bad calls based on bad info. It’s a responsibility that works better when the people have their hands in the code. I’ve had better luck with Architecture as a job description shared by the lead developers. In large enough companies they have Staff Engineer that scratches that itch with perhaps slightly less people skills (though I really don’t recommend it).

Re: Breaking up with JavaScript front ends

#402

Earlier quoted context omitted.

I don't understand the "right amount of control" bit, there are plenty of options to control what data moves to and fro in NextJS, but the CEO of Vercel has replied to you in a sibling comment; he's going to be able to address your technical concerns better than me. I'll just add that I'm not familiar with either of those sites, because I'm sitting in Spain and neither operate here, but on first inspection the UX has…

> I don't understand the "right amount of control" bit Try Astro.js and you'll understand. If the data has been used to SSR and has no function on the client side, don't send it to the client . If two multi-billion dollar, multi-national corporations with multi-million dollar project teams can't get it right in a space where every ms counts, then the average team has no hope.

What you ask for is now possible using Next.js and the new React Server Side components. Check the link in the sibling comment tree.

Re: Breaking up with JavaScript front ends

#403
Wow - lots of opinions on front-end dev. Not much of a surprise. It is a bloated mess. But "breaking up with JavaScript"? There's no way to build anything useful without JavaScript.

Build it without frameworks? Absolutely! Build with HTMX? Makes sense to me. It's a light-weight and isolated extension. It would be great if such partial load semantics was added to the web standard.

Isn't the core question whether the web client is stateless or not?

My front ends have been very stateful for long time. But I build desktop equivalent web apps. I jumped on the AJAX track in 2000 and never looked back. My state has been represented in XML ever since. I sync with server via "updategram" semantics (borrowed from SQLXML), and transform state into HTML with XSLT in the browser. I use no frameworks or libraries/ Has served me very well for 20 years and likely will until retirement.

Re: Breaking up with JavaScript front ends

#404

Maybe it's just me, but needing to press "back" twenty or so times to get back to HN after viewing some of this presentation really made me question the author's authority when it comes to "how the web should work".

Its a matter of preference. I prefer to go to previous presentaton page. You should learn to use browser - there is right click on back button

Maybe in your browser you have that option. Not for me.

Re: Breaking up with JavaScript front ends

#405

Earlier quoted context omitted.

Just want to point out that unpoly has been around for ages (looks like since 2015). This isn’t a copy of htmx.

Would be interested to know if they stuck with it

Author here. Yes, we stuck with it and evolved the concept into Unpoly 2 and soon Unpoly 3:

http://triskweline.de/unpoly2-slides/ http://triskweline.de/unpoly3-slides/

I'd say 95% of the apps we build are now based on Unpoly, the rest on React.

We now believe SPAs are not a good default for the type of apps we're building. We're still reaching for SPAs when requirements demand high-frequency user input and optimistic rendering, e.g. for a chat or online game.

YMMV!

Re: Breaking up with JavaScript front ends

#406

Earlier quoted context omitted.

I don't understand the "right amount of control" bit, there are plenty of options to control what data moves to and fro in NextJS, but the CEO of Vercel has replied to you in a sibling comment; he's going to be able to address your technical concerns better than me. I'll just add that I'm not familiar with either of those sites, because I'm sitting in Spain and neither operate here, but on first inspection the UX has…

> I don't understand the "right amount of control" bit Try Astro.js and you'll understand. If the data has been used to SSR and has no function on the client side, don't send it to the client . If two multi-billion dollar, multi-national corporations with multi-million dollar project teams can't get it right in a space where every ms counts, then the average team has no hope.

That's definitely what RSC accomplishes, which I mentioned in my comment.

Re: Breaking up with JavaScript front ends

#407

Earlier quoted context omitted.

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.

A web application requires connection to the web, which only exists with network connectivity. What you're trying to do is create a desktop application with tools built for the web. Therein lies the problem.

This is not true. Applications only require network connectivity for the initial resources to be downloaded. After that they can be cached, service workers can also be used to provide for offline support. Plenty of applications can run only in the browser and don't need to have a constant connection to a back-end. I can think of a calculator app, where all of the application logic exists on the client in JavaScript, in this case a network connection is an unneeded dependency. But once you build it with a framework like liveview it cannot work without a constant connection.

Re: Breaking up with JavaScript front ends

#408
post #308

Earlier quoted context omitted.

This used to be true but isn’t anymore. For a while they pushed Angular, nowadays I think a lot of teams are using react. GWT is long deprecated and gone.

I think citation needed on that one. From what I understand (no special insider information) React is essentially non-existent inside of Google, and NPM is not even available to engineers (be default)

I am not sure how much I can say, because I used to work there. But I think it's OK to say many Google engineers don't particularly like Angular.

Re: Breaking up with JavaScript front ends

#409

Earlier 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 underlying issue with web applications is that it’s like a square peg going in a round hole. Remember, HTTP is designed traditionally as a stateless protocol delivering static web pages, more or less. But here we are, with stacks-on-stacks-on-stacks of layers emulating what truly should be a native application. “Web Application” should not be a thing. HTML/CSS were supposed to be for content and presentation; Jav…

Yes! This is the core problem due to the historical trajectory (browser invented for static documents, now being used to build applications) -- one that's no longer possible to sidestep at this point.

I believe there is a phrase "path dependence" to describe such situations.

Re: Breaking up with JavaScript front ends

#410
post #383

Earlier quoted context omitted.

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.

I feel qualified, because I’ve been a SWE for 20 years, have worked in lots of domains (including web, sometime ago) and so I feel I am able to draw comparisons. Not for nothing, but when I wrote a couple of web apps recently (most recently a market monitoring tool and a physics simulation in wasm and webgl for rendering), I tried different frameworks, but always ended up dropping them. The end result is snappy and f…

I've also worked as a SWE for many years, and I can tell you hands down that self-rolled frontend codebases are _always_ harder to maintain and add features to, than ones that lean into frameworks and libraries. They are shared understandings that are easily transferrable between contexts.

You don't mention maintainability in your examples, purely things like back button support and disk footprint. They're just pieces in the puzzle.

Post reply on HN