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

61–70 of 433 posts

Re: Breaking up with JavaScript front ends

#61

Post by hn_throwaway_99 »

sph wrote: post #29

Needs a (2016) in the title. The situation is even worse now.

> The situation is even worse now.

Is it really? I have the exact opposite opinion. I mean, I feel like the industry has pretty well standardized on React in Typescript for the front-end on web apps. Sure, there are other technologies that do different things (e.g. Svelte, and someone else mentioned Phoenix LiveView), but for the standard "I'm building a CRUD-focused web app", there are simple choices to make and it's easy to "do the right thing". I contrast this with 2016, when things were still in flux so it was much easier to make what turned out, in hindsight, to be the "wrong" choice (e.g. Angular or Flow). Plus, tooling support is much better now.

Re: Breaking up with JavaScript front ends

#62

Post by npilk »

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…

Have you tried htmx? Maybe HTML wasn't designed to be dynamic, but IMO htmx does a great job extending it to provide interactivity in a way that feels natural and simple.

Re: Breaking up with JavaScript front ends

#63

Post by pjmlp »

strife25 wrote: post #56
whatever1 wrote: post #17

Earlier quoted context omitted.

SPAs solved a labor problem I think. It was the reason that front end development grew so fast. It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.

Labor wasn't the issue, it was UX. Users wanted responsive UIs and Gmail showed the power of AJAX in the browser. In the mid-2000s, server power, network latency, and maintaining state were the challenges. The UX was more powerful when the client tracked state, only requested the data it needed, etc. Things have flipped. SPAs became bloated as abstractions were introduced. Network latency and server power is not an i…

Ajax was created by Microsoft to show Outlook on the browser....

Re: Breaking up with JavaScript front ends

#66

Post by jrochkind1 »

NegativeLatency wrote: post #33
jrochkind1 wrote: post #21

It's interesting that they appear to plan to use with Rails as a back-end (they mention Rails bindings), as Rails 7 release corresponded with a solution which appears somewhat similar to me, turbo/stimulus. (I want to provide a link to it, but I honestly don't know any great docs for it!) But I haven't used stimulus/turbo myself. I'd be interested in a compare/contrast between Rails' Stimulus/turbo and "Unpoly" cover…

The readme seems to give a pretty good overview of turbo: https://github.com/hotwired/turbo-rails

Perhaps. And here's stimulus' official web page. https://stimulus.hotwired.dev/

Re: Breaking up with JavaScript front ends

#67

Post by jrochkind1 »

ransom1538 wrote: post #32
jrochkind1 wrote: post #21

It's interesting that they appear to plan to use with Rails as a back-end (they mention Rails bindings), as Rails 7 release corresponded with a solution which appears somewhat similar to me, turbo/stimulus. (I want to provide a link to it, but I honestly don't know any great docs for it!) But I haven't used stimulus/turbo myself. I'd be interested in a compare/contrast between Rails' Stimulus/turbo and "Unpoly" cover…

"I want to provide a link to it, but I honestly don't know any great docs for it!" I setup a demo, rails7/mysql[1]/turbo/docker - one command setup you are playing with it. https://github.com/james-ransom/rails7-on-docker-mysql . Give me a star you have a friend for life! * not Postgres!!

I don't consider a demo app with no docs (that presumably uses stimulus and turbo?) to be anything to close resembling good overview docs on what stimulus and turbo are, but thanks.

Re: Breaking up with JavaScript front ends

#68

Post by chiefalchemist »

qrohlf wrote: post #19
ramesh31 wrote: post #16

Earlier quoted context omitted.

>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, What's old is new again. There's an entire generation of developers now who have no concept of the old world. They started with React/Angular/Vue and have no idea that SSR was the standard default for decades. And now it's a "new idea" that is held up against JS development with no…

I both agree and disagree with this take. I started out hand-coding static html pages, graduated to Drupal and Wordpress php stuff circa 2009 (glad that's over!), then worked on a largely server-rendered Rails SAAS in the APM space that I guarantee you've interacted with if you've been in the web game for more than a couple years. These days, I may sling React for my 9-5 but a lot of my personal projects and internal…

Yes "app-like-ness" when that's appropriate. But a lot of the web isn't that. Yet devs / agencies are using a sledgehammer (e.g., React) when a Phillips head screwdriver is what's need.

Users get experiences they don't need (nor want). Site owners gets a maintenance dependency they don't want (nor need).

Re: Breaking up with JavaScript front ends

#69

Post by etchalon »

This slideshow is relatively old, and frameworks have gotten better, not worse, since then.

Server-side DOM mutation is deeply interesting, but I don't think it can be grafted onto existing server-side frameworks. Someone will need to rethink the MVC model with client-side state in mind.

Re: Breaking up with JavaScript front ends

#70

Post by temporallobe »

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…

HTML wasn’t designed to be dynamic but it certainly evolved to be, and personally I don’t think it’s that bad per se, but modern frameworks such as Angular and React have added so many unnecessary layers of complexity, that most developers have to reason about and work with several layers of abstraction just to make simple things work. There isn’t a real alternative because all the popular modern browsers only fundamentally understand HTML, and have been evolving and refining this over the past three decades or so. What would be nice is to have a new markup that is natively rendered and handled by the browser and that behaves similar to the document/page model everyone is used to but with built-in persistence, session handling, and dynamic rendering with a very simple and intuitive API. Obviously we have all of these already in one form or another but it’s all just hacked-together HTML/JS/CSS under the hood. Edit: minor corrections because mobile devices suck
Post reply on HN