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

Ask HN: How does one build large front end apps without a framework like React?

news.ycombinator.com

Post reply on HN
Print view View original

141–150 of 197 posts

Re: Ask HN: How does one build large front end apps without a framework like React?

#141

Post by shawa_a_a »

juliend2 wrote: post #112
brendanmc6 wrote: post #108

I've abandoned Next.js and React for Elixir / Phoenix. I am able to build a perfectly pleasant user experience with just a sprinkle of vanilla JS via Phoenix hooks. The fact that I have been able to build a multi-user collaborative editor experience without a single additional dependency is incredible. I previously worked for a well-established and well-funded React team who had this feature on their roadmap for half…

I'm curious what is specific to Phoenix that made this so productive for that project? Is the frontend using something like HTMX?

They're probably using some features of LiveView; I'm not too familiar with how HTMX works, but with LiveView you can define all of your logic and state handling on the _backend_, with page diffs pushed to the client over a websocket channel (all handled out of the box).

It comes with some tradeoffs compared to fully client-side state, but it's a really comfortable paradigm to program in, especially if you're not from a frontend background, and really clicks with the wider Elixir/Erlang problem solving approach.

https://hexdocs.pm/phoenix_live_view/js-interop.html#handlin...

Hooks let you do things like have your DOM update live, but then layer on some JS in response.

For example you could define a custom `` component, which is inserted into the DOM with `data-points=[...]`, and have a hook then 'hydrate' it with e.g. a D3 or VegaLite plot.

Since Phoenix/LiveView is handling the state, your JS needs only be concerned about that last-mile JS integration; no need to pair it with another virtual DOM / state management system.

https://hexdocs.pm/phoenix_live_view/js-interop.html#client-...

Re: Ask HN: How does one build large front end apps without a framework like React?

#142

Post by austin-cheney »

rudi-c wrote: post #131
austin-cheney wrote: post #103

Earlier quoted context omitted.

> When you're writing only a "couple lines of code", you can do pretty much anything you want. There's no real tradeoffs to discuss except in a theoretical sense, because the stakes are so small. The JavaScript logic in the browser is comparatively small compared to the total application. This is absolutely more true when you remove the bloat imposed by a large framework. Frameworks do not exist to alleviate problems…

That you believe frameworks were invented to serve employers is a cynical point of view. I'm sorry for whatever bad experience you've had with the frameworks or people using them that caused you to develop this viewpoint. A developer choosing to use a framework doesn't mean they are reliant on it, any more than choosing a particular language, library, text editor, tool, etc. It simply means they decided it was a help…

I hear the exact same self absorbed reasoning on other subjects from my autistic child almost daily. The psychological term is fragile ego.

For example: It’s not that the developer reliant on the framework is less than wonderful. It’s that everyone who differs in opinion is obviously wrong and/or arrogant, because the given developer cannot fathom being less than wonderful.

Re: Ask HN: How does one build large front end apps without a framework like React?

#143

Post by runjake »

rudi-c wrote: post #136
runjake wrote: post #134

Earlier quoted context omitted.

You can just admit you were wrong instead of continuing to move the goalposts. :)

Everyone else in this thread is talking about (React/Angular/Vue/JQuery/etc) v.s. (Plain JS/Direct DOM manipulation/etc). Running that code on top of Electron or not is entirely orthogonal. So I admit I'm confused why you're fixated on bringing Electron into the conversation. Op's question appears to me like it references the last part of the linked thread: "I’d like to know what JavaScript framework (e.g. Vue, React…

I thought we were talking about this (pasted from your comment above):

> "I’d like to know what JavaScript framework (e.g. Vue, React) Obsidian desktop application is using for creating the user interface?

And the answer to that question is: Electron.

Is that not the question?

Re: Ask HN: How does one build large front end apps without a framework like React?

#144

Post by jdsleppy »

runjake wrote: post #134
rudi-c wrote: post #132

Earlier quoted context omitted.

I mean, you're correct that Obsidian doesn't run on the browser. But it's built on web technologies. As a result, I would argue that the overlap between the skillset and work needed to build an app like Obsidian overlaps more with most web applications than most desktop and mobile applications. You're also correct that Electron provides APIs beyond those available in the browser, such as access to the native filesyst…

You can just admit you were wrong instead of continuing to move the goalposts. :)

I can second the other commenter: you are having a different discussion than the rest of the comments and OP.

Re: Ask HN: How does one build large front end apps without a framework like React?

#145

Post by jvalencia »

Large software projects are an interesting use case because once you get large is precisely when the framework becomes valuable.

A large enterprise project will need security, testing, auth, (AI now too). I'd hate to implement SAML without a library, that would be torture, and likely incompatible with most systems.

While I've often written small self projects from scratch, I wouldn't dream of building a large one that way unless you are sure to have an army of engineers and QA.

As an aside, this is where AI code fails as well. Speed of dev is easy, stability over time and compatibility is hard.

Re: Ask HN: How does one build large front end apps without a framework like React?

#146

Post by rudi-c »

runjake wrote: post #143
rudi-c wrote: post #136

Earlier quoted context omitted.

Everyone else in this thread is talking about (React/Angular/Vue/JQuery/etc) v.s. (Plain JS/Direct DOM manipulation/etc). Running that code on top of Electron or not is entirely orthogonal. So I admit I'm confused why you're fixated on bringing Electron into the conversation. Op's question appears to me like it references the last part of the linked thread: "I’d like to know what JavaScript framework (e.g. Vue, React…

I thought we were talking about this (pasted from your comment above): > "I’d like to know what JavaScript framework (e.g. Vue, React) Obsidian desktop application is using for creating the user interface? And the answer to that question is: Electron. Is that not the question?

Electron does not belong in the same category as React & Vue. JavaScript frameworks are commonly understood to mean:

- Third-party libraries, almost always implemented in JS (technically it could be some language compiled to WASM but I'm not aware of any commonly used WASM framework)

- Dynamically loaded from a CDN or bundled with application code at build time

- Provide an high-level API for creating and updating UI

- Whose implementation edits the DOM (a browser's low-level UI representation)

In contrast, writing an app _without a UI framework_, therefore implies writing first-party JS code that interacts with DOM APIs directly, without that level of abstraction in-between. This is not a common choice these days, and could be considered an impressive accomplishment, hence this Ask HN.

To create that UI, you use the same low-level DOM APIs in Electron as you would in the browser because well, it is a Chromium browser engine.

Example of each combination:

- Framework-using apps running in the browser: Airbnb, Figma

- Frameworkless apps running in the browser: HN

- Framework-using apps running in Electron: Figma's desktop app

- Frameworkless apps running in Electron: Obsidian

I wouldn't consider Electron as an answer to the question. It would be best described as a framework for running web apps as a standalone desktop app, but not a framework for creating user interfaces. Just using Electron doesn't make any progress towards having a solution for managing the complexity of writing code that interacts with the DOM.

Re: Ask HN: How does one build large front end apps without a framework like React?

#147

Post by ohthatsnotright »

dotandimet wrote: post #106
gg2222 wrote: post #91

Earlier quoted context omitted.

Unrelated to the topic, but wow, they're still using moment? I thought it was kind of deprecated and been trying to use other libs.

I think most of the complaints about moment are that it's really big (because of i18n and timezones). Obsidian isn't a web page/app, so it doesn't need to optimize bundle size too much.

It's unexpectedly mutable unless you've closely read the documentation, been bitten by the mutations, or are doing very simple date manipulations.

It's a great library, but it does need fewer footguns. date-fns is a good alternative.

Re: Ask HN: How does one build large front end apps without a framework like React?

#148

Post by brazukadev »

kristopolous wrote: post #116
ludicrousdispla wrote: post #97

I'll add a secondary, or implicit, criteria that the approach you take should not require a 'build process' for the front end app. M -> the MODEL is managed by the backend server, or in-browser via WASM V -> the VIEW is defined by the HTML and CSS C -> the CONTROLLER can be solely Javascript in the front-end, solely backend server processes, or most likely a mix of the two

model is html view is css controller is js that's why there's 3.

er... no. html+css is view, js is model and controller.

Maybe, if by html we are saying html+dom+webAPIs (indexeddb, localstorage, sessionstorage, cache API), then yeah, you'd be right.

Re: Ask HN: How does one build large front end apps without a framework like React?

#149

Post by reactordev »

All you need is fetch, document.querySelector, some sort of observable, and patience. It's really just a software architecture problem of component reusability which is going to be true whether you use a framework or not. How do you compose your views, process events, update information, and send data? Sometimes it really is just as simple as
Post reply on HN