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

You also could stop misusing the browser as an application frontend, and write a proper frontend with a cross-platform toolkit, and distribute that.

I don't understand why developers so often choose the browser as a frontend. Are there better rationales besides having at least some frontend for tyrant-controlled devices like iOS'es, and just using the skills one already has?

For the first, just tell the people to get proper devices.

Because of the second, I see schooling efforts for JavaScript by the tech giants so negatively. It leads to masses of people using JavaScript where it shouldn't be.



Perhaps you don’t remember back to the days before the browser was used for application front ends. The problem was no one wrote the front end on some “nice cross platform toolkit”. Instead everything was some crappy windows only app and Linux and Mac users were left out in the cold. Give me the browser any day.


If there was another way to ship an application that can be accessed in one click, in less than a second, with shareable urls, I'd be interested.

Other nice things to see: multiple independent open source implementations of the application platform; a stable and battle tested sandbox, such that users can run code from hundreds of different vendors every day without much worry about being pwned.

The web is old and hoary, but to me there isn't any comparison. For most apps I build, the second place choice isn't even close.


> just tell the people to get proper devices

That seems like a great way to have no users.

An incredibly obvious reason would be that it is the largest application delivery platform with the highest level of user familiarity and comfort.

If you compare two services where one of them offers you a direct login to the app and the other offers you a 200MB download, most people will choose to log in to a website. It's a better user experience. Especially for things that will see infrequent use.


If you _only_ care about the number of users, then I see a point. However, at least for non-commercial programs, why care at all about the number of users?

The scenario you are drawing is not a proper comparison. There is no reason why a native toolkit couldn't support rendering the program before it's fully loaded, so I see no reason a native program would need more data transfer upfront than a JavaScript one. Though I think too that being prompted to download the program, then install it and find the way to run it can be cumbersome, but the solution to this is to not do it this way. Why not integrate with the native way to obtain applications and make it transparent and convenient for the user?

After all, I think there might be fundamentally different goals when developing a software, and that explains the difference. If one has accepted advertisement-based financing of projects, then them and I would probably disagree in many ways. I think users devices must only and exclusively work for the user.


>You also could stop misusing the browser as an application frontend, and write a proper frontend with a cross-platform toolkit, and distribute that.

This is pure insanity. There are tons of applications built on the web stack now that are supposed to run on local networks. There has never been a requirement that "Network == Internet".

For example, enterprise software. Dynamics CRM? Dynamics NAV? Dynamics... anything? Sage CRM? Everything runs on the browser now.

Why would anyone pass up a gigantic, proven, powerful software stack that represents >90% of all applications in the world?

The error is in the stack, not that people would want to use the easiest, most powerful tool for the job.

We might as well be advocating to go back to FoxPro.

>For the first, just tell the people to get proper devices.

It must be super nice to live in a world where you can dictate what devices the clients use, as opposed to a huge investment of pre-installed devices, or, devices users bring from home.

Whatever job you've got, I want it. Because it's completely alien to my career experience.




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

Search: