Hacker News Reader

Comment by mrtksn | Hacker News Reader

React was my reason to distance myself from Web frontend. Huge complexity just to make the web browser render boxes in a way it’s not intended to do. Huge loss of productivity and tooling in the name of changing a coding paradigm. Some cool ideas and implementations, sure but was it worth it? Maybe it was a job security stunt or something of that sort?

Well it wasn’t just ReactJS, the whole JavaScript ecosystem went mad with its libraries and tooling for all these libraries but React was particularly annoying to get started so they built create react app so you can have a hello world app in a reasonable time.

View on HN

What is your alternative to the problems that React supposedly solves?

I no longer have an idea for the web, I do native mobile apps now. SwiftUI for example shares many ideas with react, like being declarative.

The difference is, in SwiftUI you fire up Xcode and you are up and ready to build the thing you intend to. No tooling setup, no intermediate steps to transpile the code into something you can’t recognize and the “backend” that deals with the logic is the same language with the same paradigms. Mind you, SwiftUI is considered a downgrade when it comes to tooling. Yet everything fits and you didn’t spend mental energy to try to make the tools work as intended.

My mantra now is to use the tool that is built to do the things I want to do and stop trying to make make it work in ways it’s not intended to. That’s why when I want to have a web interface I simply work with DOM directly. That’s how the creators of the web browser intended:) No virtual DOM, no libraries doing magic and managing the DOM for me. I'm sure there's place for ReactJS too, it's just that its not for most use cases.

All I want is tools that I can fully fit in my working memory and don’t spend time trying to make things work so I can do the work I care about. Simplicity and robustness is the paramount.

I'm kind of the same with that. At some point quite a long time ago doing the front-end side of webdev became a chore for me so I stopped. I'm finding SwiftUI attractive because I feel like I make a decent frontend experience for free which allows me to focus on the functionality.

SwiftUI is to UIKit what React is to the DOM.

I think the big difference right now is React has been released for 10 years vs SwiftUI's 5, so people had had the time to shoot themselves in the foot much more with React. IMO it doesn't take away from it still being much better than what it replaced.

> you fire up Xcode and you are up and ready to build the thing you intend to. No tooling setup

> no intermediate steps to transpile the code

Sorry, but how is Xcode not "tooling"? And how is there no compilation step?

It should be obvious to us all that the frontend world needs more stable and reliable tooling. But pretending that native or mobile apps somehow don't need tooling is not a serious position.

> I simply work with DOM directly

Do you care to show us any apps that you've built with this approach?

So much of this debate is people talking past each other about what they need. Some people are building a glorified blog CMS, and jQuery is fine. Some people are building Figma, and think the former camp are insane for suggesting jQuery is fine.

> That’s how the creators of the web browser intended:)

The web is the best application delivery platform we currently have, so people will ship apps on it whether or not that's what Tim Berners-Lee thought they should be doing.

I didn’t say there’s no toooling, it’s just that these tools work great and are mostly transparent. There’s no part where you setup or manage the tool. Even the deployment is just a few clicks.

The overhead is so low compared to the web tech, it’s no comparison.

If you want to do something weird you can complicate things if you like but the defaults are great so most of the time you don’t have to.

You know how on web tech there's many tools like packers, linters etc? Those are all tools you need only because you want to pretend that JS is not JS and you end up putting a distance between yourself and the actual thing that runs so you loose your ability to understand what's actually going on because it's actually not your code that's running in the browser and you had to do the chores to achieve it.

On native development these things also exists(the CPU doesn't understand human readable code, right? However the abstraction layers are straightforward), the packer equivalent would be linker I guess(not exactly but...) but you don't have to even know about that unless you are doing something that explicitly requires you to control how modules need to be connected. These tools are mature and simple, they daisy chain, you don't go through huge configuration files and its usually just a flag you add when you want to do something non-default(which you wouldn't if you are doing something like building UI). For huge projects things can get quite complex but the complexity isn't the default, unlike React & similar.

>in a way it’s not intended to do

Yeah that just isn't true. No matter how much you want it, the days of html pages with anchor tags and <table> elements centering content are gone.

Move on man.

Html, anchor tags, and tables are definitely not gone. Now we center with CSS. I suspect these things will be staying around longer than react will.

I moved on. To native apps.

It’s great.

Btw the web tech has come a long way since. Native browser API is amazing, CSS is wonderful and I’m particularly excited for Web assembly. Drop the virtual DOM stuff and all other Frankenstein BS and working on the browser is actually fun again.

Reply on news.ycombinator.com