When you write an app without using an existing framework, you are bound to write your own framework. And there's nothing wrong with that.
Ask HN: How does one build large front end apps without a framework like React?
101–110 of 197 posts
Re: Ask HN: How does one build large front end apps without a framework like React?
#102Earlier quoted context omitted.
The React ecosystem moves really quickly, and likes to re-invent wheels. But React core APIs remain relatively stable, I've been using React the same way for many years at this point, and you can ignore the parts you don't like, like I'm ignoring hooks and haven't found a single use case where I needed them.
Could you please tell me how are you avoiding hooks? You're not using useState or useEffects?
One of the projects I sometimes work on uses class components + mobx; it runs circles around hooks in speed/debuggability/convenience IMHO.
Re: Ask HN: How does one build large front end apps without a framework like React?
#103Earlier quoted context omitted.
> Not sure how you avoid reinventing any of the component frameworks. You don't do framework nonsense. That is all there is to it. For most people writing JavaScript for employment it is absolutely impossible to imagine any universe where a couple of lines of code could be written without something that looks like a framework. That is not a limitation of the language, but rather a limitation of the given developer's…
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. If the app being built is "large" (which I understand to mean, has high essential complexity), then those tradeoffs matter a lot. If the app is built by a team instead of an individual, the people problems become significant.…
> 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 for the developer. They exist to help the employer with candidate selection and training elimination to expedite hiring and firing. I can understand why a developer who is utterly reliant on the framework to do their job might think otherwise, which is a capability/dependence concern.
Re: Ask HN: How does one build large front end apps without a framework like React?
#104Addressing the very first sentence in this post: > I had a mind-blown-moment when I learnt that Obsidian was built without any frontend JS framework. The comment you’ve linked to is wrong. Obsidian uses the Electron framework for its “front-end” framework. In fact, it was even affected by the recent “Tahoe” Electron bug. https://en.wikipedia.org/wiki/Obsidian_(software)#Availabili...
Framework is unfortunately a term that's both ill-defined and quite overloaded. Electron is a framework in a very different sense than the "JS frameworks" op is asking about. The latter is about libraries with APIs and mental models for producing the UI & UX of web applications. Electron is just a way of running Chrome without the Chrome UI around it, + a few APIs for accessing native OS APIs. You wouldn't say that C…
> Electron is a framework in a very different sense than the "JS frameworks" op is asking about.
The OP doesn't have a good understanding of what they're asking about, and that's okay. That's why they asked the question.
The linked thread is titled "What framework did the developer use to create Obsidian desktop application?". It's not asking about a web application and specifically referencing a desktop framework with: "He must be using some sort of desktop framework in order to push this out simultaneously right?".
> The latter is about libraries with APIs and mental models for producing the UI & UX of web applications.
Obsidian is not a web application. It is a desktop and mobile application. There is presently no Obsidian web application. So it would be odd to be asking about web frameworks for a non-web desktop and mobile application.
> Electron is just a way of running Chrome without the Chrome UI around it, + a few APIs for accessing native OS APIs.
No, Electron is a complete Javascript-based application framework. It does so much more[1] than that.
Re: Ask HN: How does one build large front end apps without a framework like React?
#105Earlier quoted context omitted.
> Hooks are only 5 years old 7. Worth saying that React really only took off 9-10 years ago, so hooks are damn near the beginning of time for _most_ react devs. > The docs were revamped 2 years ago and there's lots of dead links to the old docs page which has a scary warning "These docs are old and won’t be updated. IMO those are not dead links. A link is 'dead' if it links to a page that doesn't exist. Links to old…
None of these are problems taken separately, but put together they're pretty frustrating. Hooks being 5 years old and being the predominant tool for certain tasks shows that the community only figured out how to solve a particular problem 5 years ago. Compare that, in terms of stability, to Python having coming up with the idea of packages a long time ago, and packages are now a stable part of the ecosystem (packag i…
> None of these are problems taken separately, but put together they're pretty frustrating. Hooks being 5 years old and being the predominant tool for certain tasks shows that the community only figured out how to solve a particular problem 5 years ago.
Hooks are ~~7~~ 6 years+8months old, almost 7 years. This may not seem like a significant difference, but IMO it puts them 75% of the way back in time to when react took off versus 50% of the way. That is a significant difference. Please stop repeating the 5 year number. It's _provably_ wrong and not a matter of opinion: https://legacy.reactjs.org/blog/2019/02/06/react-v16.8.0.htm...
> does not seems like something a stable ecosystem would do.
I don't think being a 'stable ecosystem' means owning every part of the dev process, or even most of it; nor have they ever intended to do so (they didn't reimplement npm, webpack, etc). CRA existed to fill a particular need for a time (providing a simpler/more stable interface in front of webpack), and when that was no longer needed by the community, they abandoned it. I don't understand why this matters. Better tools emerged, the React docs/guidance reflect that.
> because I inherited a simple site that should have never used React
I'm sorry that you're in that situation. The React community is not really responsible for that IMO, and I don't think the things you've highlighted have meaningfully contributed to making that worse. I stand by the fact that deprecating CRA once great alternatives emerged was the right answer. Next is probably a good answer for many people too. The react team is and should be writing recommendations for the common case for their library, and the fact that your simple site falls outside of an ideal case for React doesn't mean they're not writing the correct recommendations.
Re: Ask HN: How does one build large front end apps without a framework like React?
#106> JS frameworks move really quickly React is a lot more stable than I think you're giving it credit for. > And the stability also means that more time is spent on delivering features Frameworks/libs also exist to save you time, thus letting you spend more time on delivering features. And fwiw, the obsidian team seems to agree in principle. Your link goes to a forum post of some kind, in which one may find a link to o…
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.
Re: Ask HN: How does one build large front end apps without a framework like React?
#107You can, but if you did you would likely just reinvent concepts that are in the framework. Maybe you will do a better job (problem is that many believe they can, and so do). You could even write your own browser that uses python instead of javascript. However, it would only be compatible with python html pages. We stick with JS for web development because that is how the "browser framework" is designed. HTML, CSS, JS…
There is a process by which functionality is pushed outward from the core to the edge. And there is another process by which functionality is pushed back from he edge to the core.
For example, people did things in JS over and over and over again and some off those things became browser functionality, and some of them became CSS functionality, and some prompted server and browser changes.
Yes, you are right, the process is slow. But when software has a way for people to customize it, that customization is a very egalitarian kind of feature discovery.
Re: Ask HN: How does one build large front end apps without a framework like React?
#108I'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 a decade but still find it too daunting to implement.
Phoenix was a great reminder that a lot of the "frontend engineering" we find ourselves doing as React developers just isn't necessary with the right backend. It's HORRIFIC to look back at all the yakshaving I've done in my career already. Wrangling types (GraphQL, codegen libraries), wrangling queries and data-fetching (react-query, SWR, server components), fiddling with middleware (serverless functions, getStaticProps, CDNs). I've seen teams outright abandon testing because the hours they invested just weren't catching any of the bugs that mattered.
I'm not doing any of that anymore. I'm spending that time refining the core data model, improving test coverage, thinking about go-to-market and making money.
Phoenix may not be a good choice if your product has reached that level of maturity and product-market fit where you really should care about "microinteractions", fine-tuned animations, or advanced use-cases for an SPA like offline support and highly-optimistic UI. But I would argue that even mature products don't truly need these things. Just look at the GitHub UI. I've spent a truly astronomical number of hours in that UI and never wished I had WYSIWYG text editing, or animated skeleton UIs, or the dozen other things that the React community tells us we need.
Re: Ask HN: How does one build large front end apps without a framework like React?
#109You build your own framework in some sense, it's a good learning exercise. Modern component frameworks can be anywhere from highly abstract to relatively light weight. If you're mainly using something like Vue, you just need to figure out where and when to update the dom, where to store data temporarily, etc..
Things get unwieldy at a certain scale when you don't have something like Typescript regardless of whether you have a framework, but you could start by building up small bits of the frontend stack from scratch. I learned how to do a bunch of manual raw js stuff from scratch originally, then did some professional work with YUI at a huge scale which was probably as close to an event driven frontend system as you can get. Start by figuring out how to listen for url changes, make a network request library from scratch, store data somewhere.
Imo one of the beautiful things we now get along with frameworks is a host of independent build tools that make the feedback loop of testing changes nearly instant and loosely coupled from your code.
Re: Ask HN: How does one build large front end apps without a framework like React?
#110First, I decide if I think the app will have lots of client-side interaction. As a shorthand, the question is “Does my idea seem like a spreadsheet, Google Maps, or a video game with lots of interactive clicking?”
If the answer to that question is “No”, then I’m not conceptualizing a SPA and don’t need a framework.
If the answer is “Yes”, I’d ask where I think that interaction will manifest in the experience and if I can isolate it.
If I am not looking at a SPA use-case, then my focus is on using vanilla HTML and Modern CSS with a tiny bit of javascript (as a scripting language versus as a programming language [1]). Then the remainder of the focus is on data modeling (CRUD), auth flows, and business logic development (what the application will do).
Beyond vanilla HTML, Modern CSS, and a tiny amount of javascript, if I need further client-side interactivity, I would consider something like htmx.
If I need interactivity beyond that, then we’re into SPA territory, but at this point the requirements and application have evolved to that point since we initially said we weren’t building that kind of thing.
Overall, the idea is to progressively iterate on the application, keeping the architecture and dependencies reigned in and aligned with the core objectives.
[1] JavaScript as scripting vs programming language: what I mean by this is JavaScript as a language with many warts is not so bad if its scope is kept small. I believe the issues with JavaScript arise when it is pushed to do too much. This then leads to needing to use Typescript as a matter of pragmatism. I aim to never get to the point of using so much JavaScript that I then need Typescript. I would say using it as a scripting language (to fill in gaps that Modern CSS and HTML cannot handle today) greatly minimizes the need for this progression.