Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why would a tech company not build its flagship product natively on the platforms where it runs? It seems like a generation drift: an obliviousness to the world outside of JS/web dev, and a general disregard for application performance.


Put simply: time to market. Experienced front-end devs with a designer on hand could put together the UI inside of a day, with a workable user experience.

Hell, if you're not afraid of bloating in the codebase, you could use a large number of libraries to put together a basic, working version inside of a day or two. Stretch that to a couple of weeks (at most) and you have a prototype you can release.

The proof is in Atlassian and Microsoft chasing after Slack on this. Very few people came forward to wave the "Let's just go back to IRC" flag.

It's shiny, new, you can drag and drop gifs and files into it, and it runs pretty swiftly (ignoring all of the obvious flaws). Most, especially less technical, users would find it a charm to work with. In my experience, they do -- and above all of the competitors.

The rest of your points are rather valid. But maybe its not so much obliviousness, as eagerness and impatience, and the reality of the market being as timely and pressing as it currently is. It's a race -- just like the telephone and the radio (for my point I'm ignoring the scale of impact here).


> Experienced front-end devs

That's the problem right there(?). People bringing a DOM to the desktop because the developers were fluent in JS.

> time to market

If there were no drawbacks in terms of complexity/performance/size etc then I'd agree, but now when you have a perf issue that is too large it might be a huge issue to fix. You also only get one chance for a first impression - and poor performance is a huge turnoff. Looking blingy and having all the features doesn't save an app with a 200ms lockup. or a 10% CPU at idle.


Agree, I think this is a combination of lack of imagination by developers who only know JS, and management who has bought the myth that cross platform development is 3x faster than making native apps.

I saw this happen at work. My team were all experts on native mobile development. We could crank out stuff fast, because we knew our tools well. But then some management dude got the idea that we would do it 2-3x faster if we went with JavaScript.

Turns out it was more like 2-3 slower than making all the native versions, because we did not have strong experience with these tools and APIs were more limited, poorely documented, buggy, and the tools were subpar.


Definitely won't argue with you here. Like most things that are gradually corrupted the root cause is money.


Perhaps because it allows them to iterate faster if they don't?


because they don't need to. Our phones and computers aren't where they were 10~15 years ago. The end user doesn't even notice if an app is native or running in Electron.

Given that constraint, time to market becomes crucial as the huge cross platform barrier is significantly reduced by Electron.

It's also a demographic shift. Young developer's aren't coding in Java peak world anymore. We haven't even reached peak Javascript yet.


Definitely a demographic shift. And maybe business smart: cheaper to hire and onboard web devs etc. But that doesn't mean the company and its product shouldn't be critiqued for its architecture (even more so because it is a software company).


[flagged]


> I can see someone is downvoting comments that doesn't agree with time to market being an important driver in influencing architectural decisions. This is someone who is very mature and well seasoned in Java architecture.

Ah yes. Someone who downvotes you, which you assume to be about the time to market comment of your argument, must naturally be a person "who is very mature and well seasoned in Java architecture".

What does that even mean to be "well seasoned in Java architecture"?




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: