7 ms·

I've worked on a lot of web projects, but still I don't understand why we want to build applications in browsers. Don't get me wrong, I love the web and I've be

by xj9 10y ago

I've worked on a lot of web projects, but still I don't understand why we want to build applications in browsers. Don't get me wrong, I love the web and I've been hacking on it for a long time, but browsers can't do shit. Servers do all of the heavy lifting, even with "modern" web apps. Yet our browsers are resource-hungry monsters. I'm currently working in the peer to peer application/protocol space and the biggest thing that stands out to me is the impact these technologies could have in developing countries. The challenge is making things light enough to run well on the weak hardware most people have to work with. Browser apps don't make the cut.

forthefuture 10y ago
I can't tell you how happy I'd be if someone made a network of applications you could download and install in under a second that ran in any other language.
- n00b101 10y ago
  ran in any other language When you say "language" here, are you referring to the web languages (HTML, JS)?
  - mcav 10y ago
    I think they're referring to any non-web language, e.g. if I could host and distribute C apps with the ease of the web. (Getting end-users to actually run and use a program with one click, rather than having to download a binary, run it separately, etc.)
    - imtringued 10y ago
      Are you thinking of something along the lines of `ceylon run com.example.helloworld/1.0.0`? This command downloads the module if it's not locally available from the remote repository and then runs it to print "Hello, World!".
- khedoros 10y ago
  Ditto, because most things I use online load in the >10 second range and don't "install" in any meaningful sense of the word.
- spdustin 10y ago
  So, RDP/VNC to a server running a full desktop GUI application with folder redirection to access local files?
- flukus 10y ago
  You mean like apt or chocalatey or any other package manager?
- venuzr 10y ago
  Is there a way to extend a running javascript app without restart. Say I have a Single Page APP (built on React if that matters) and I want to allow third party developers to add Components / modules/ themes/ plugins to a registry. I want to be able to allow end users to choose third party plugins from the registry to extend the capabilities of the SPA. Is this possible? If so, is there any guidance on how to achieve this? Thanks
  - icebraining 10y ago
    Sure it's possible. As an example, Odoo is a full Python webapp "platform", with a core upon which the user can choose and load plugins to add features (from a simple contact list to a full-blown ERP/CRM/accouting/CMS) and extensions to those features. On the frontend side, when you install a module, it loads the .js file (using a regular <script> tag) which contains a single function. The Odoo core passes its main JS object (the base of the core API) to that function, which then initializes the whole module and uses the Odoo API to configure stuff, setup hooks, etc. There's no security, though: by design, a module is trusted and can do anything on the platform. I'm not sure if and how one could contain them. (Disclaimer: I'm a developer working for an Odoo partner, we write modules and host it as a SaaS.)
    - Gaelan 10y ago
      I don't speak Python, but on the client modules could run in web workers.
- xj9 10y ago
  I'm pretty much solo on this, but I'm trying to build something along those lines.[1][2] [1]: https://www.infinite-automata.com/ https://www.infinite-automata.com/ [2]: https://gitlab.com/infinite-automata/ https://gitlab.com/infinite-automata/
deleted 10y ago
[deleted]
ycombinatorMan 10y ago
It's not like its the developers choice...
formula1 10y ago
I think I understand but anyone should free to correct me. In every single other environment there is little to no distinction between "front end" and "back end". In fact, other than the web, the ui is a library within the language a developer chooses while in the web the scripting language is secondary to the ui. These concepts may hurt or cripple early developers since html/css is obvious and easy while the concept that globals, scope and the database is in an entirely seperate location seems odd. What makes it worse is that xmlhttp requests arent very kind. The concept of the single page app and "serverless" architecture seems to be a fools errand to build (or influence big names to build) complex html applications without the need to spend money or wrappers to bridge the gap. Meteor, northwest.js and electron are celebrated for attempting to accomplish these goals.
- flukus 10y ago
  > I think I understand but anyone should free to correct me. In every single other environment there is little to no distinction between "front end" and "back end". In fact, other than the web, the ui is a library within the language a developer chooses while in the web the scripting language is secondary to the ui. It depends. A desktop application may have a backend, like a central web service to connect to. Even if it doesn't, there is still likely to be a logical separation of layers which may or may not be in different languages (think c++ backend with a c#/xaml front end).
  - formula1 10y ago
    In those situations, does the c++ service render the xaml or provide the c# to execute to provide the xaml? Or does it provide a shared storage/events/peer resolution/info collecting. Usually a server provides something much different than a web server does
    - vizeroth 10y ago
      C#/XAML on the front-end could mean that .Net/WPF is rendering the XAML and wiring up the C#. The C# might do little more than handle events triggered by the user interface and update the user interface in response to events triggered by the back end. As the potential capabilities in front-end web development increase, the differences between web development and "desktop" software development are reduced, because web developers find themselves facing more and more of the same questions software developers have always faced when dealing with distributed software architectures at scale.
rpedela 10y ago
Because I can build my application once and it works everywhere (mostly). Because I can update it whenever I want and I don't have to support multiple versions. Because there is very little friction for users to use my application, they don't have to manually download or upgrade it.
- kaoD 10y ago
  This. This so much. And it's safer for the user. Have you ever tried distributing binaries on the internet? People are very reluctant to run a random binary (and rightly so). Also IMH developer perspective HTML+JS+CSS is surprisingly a not so bad UI toolkit, and React makes the development experience even better. I will always bet on standards and, at least for now, modern web is the standard that I can trust.
  - nkassis 10y ago
    The value of the browser sandbox is often dismissed but it's doing a great job at allowing people to run untrusted code from the web without much thought behind it. I also strongly believe users are much more willing to try websites than download entire app anyways just to see if it's any good.
- xj9 10y ago
  None of those things are tied directly to web technologies.
  - bastawhiz 10y ago
    Which other platform truly allows you to write software once and deploy it seamlessly to just about every kind of desktop and mobile device in the world?
    - xj9 10y ago
      The browser has a great deployment story and incredible market penetration, I agree. However, none of that is because of web technologies. Browsers are special because they are everywhere, not because they are good or because JS+CSS+HTML is a special magic sauce that nobody else can replicate. We can do better.
qwtel 10y ago
> but still I don't understand why we want to build applications in browsers because that's where people's attention is. where people's attention is, is where apps are going to be built, with whatever is there to build them. if you think javascript is bad, get ready for SnapchatScript (that's not an actual project, but it all too easily could be, and something like it will be an actual project, some day)
angryasian 10y ago
>Browser apps don't make the cut. I just don't get this at all. The fact that chromium books and in the past netbooks do so well is for this reason. I can't understand why you wouldn't want browser applications at this point. Outside of write once run anywhere, security and accessibility is another benefit of the browser. We still have a huge issue with the walled garden in the app space. I'm assuming you mean primarily in the mobile space ? I think this is largely due to a failure on Apple and Google's lack of wanting to innovate because they control the app stores.
- xj9 10y ago
  I'm talking about performance. Browser applications are very resource intensive. That isn't a problem for rich people in developed countries, but most of the world can't afford to throw hardware at their problems. Besides, do we really think we'll be able to double hardware performance every year ad infinitum? Even Intel has given up on that pipe dream by now.
  - angryasian 10y ago
    Again Ill have to disagree, there were many efforts on delivering laptops for people in third world countries that ran linux and used browser apps primarily. Even chromebooks work fine in most educational spaces in the US. http://one.laptop.org/ http://one.laptop.org/

by xj9 10y ago

forthefuture 10y ago

I can't tell you how happy I'd be if someone made a network of applications you could download and install in under a second that ran in any other language.

n00b101 10y ago
ran in any other language When you say "language" here, are you referring to the web languages (HTML, JS)?
- mcav 10y ago
  I think they're referring to any non-web language, e.g. if I could host and distribute C apps with the ease of the web. (Getting end-users to actually run and use a program with one click, rather than having to download a binary, run it separately, etc.)
  - imtringued 10y ago
    Are you thinking of something along the lines of `ceylon run com.example.helloworld/1.0.0`? This command downloads the module if it's not locally available from the remote repository and then runs it to print "Hello, World!".
khedoros 10y ago
Ditto, because most things I use online load in the >10 second range and don't "install" in any meaningful sense of the word.
spdustin 10y ago
So, RDP/VNC to a server running a full desktop GUI application with folder redirection to access local files?
flukus 10y ago
You mean like apt or chocalatey or any other package manager?
venuzr 10y ago
Is there a way to extend a running javascript app without restart. Say I have a Single Page APP (built on React if that matters) and I want to allow third party developers to add Components / modules/ themes/ plugins to a registry. I want to be able to allow end users to choose third party plugins from the registry to extend the capabilities of the SPA. Is this possible? If so, is there any guidance on how to achieve this? Thanks
- icebraining 10y ago
  Sure it's possible. As an example, Odoo is a full Python webapp "platform", with a core upon which the user can choose and load plugins to add features (from a simple contact list to a full-blown ERP/CRM/accouting/CMS) and extensions to those features. On the frontend side, when you install a module, it loads the .js file (using a regular <script> tag) which contains a single function. The Odoo core passes its main JS object (the base of the core API) to that function, which then initializes the whole module and uses the Odoo API to configure stuff, setup hooks, etc. There's no security, though: by design, a module is trusted and can do anything on the platform. I'm not sure if and how one could contain them. (Disclaimer: I'm a developer working for an Odoo partner, we write modules and host it as a SaaS.)
  - Gaelan 10y ago
    I don't speak Python, but on the client modules could run in web workers.
xj9 10y ago
I'm pretty much solo on this, but I'm trying to build something along those lines.[1][2] [1]: https://www.infinite-automata.com/ https://www.infinite-automata.com/ [2]: https://gitlab.com/infinite-automata/ https://gitlab.com/infinite-automata/

deleted 10y ago

[deleted]

ycombinatorMan 10y ago

It's not like its the developers choice...

formula1 10y ago

I think I understand but anyone should free to correct me. In every single other environment there is little to no distinction between "front end" and "back end". In fact, other than the web, the ui is a library within the language a developer chooses while in the web the scripting language is secondary to the ui. These concepts may hurt or cripple early developers since html/css is obvious and easy while the concept that globals, scope and the database is in an entirely seperate location seems odd. What makes it worse is that xmlhttp requests arent very kind. The concept of the single page app and "serverless" architecture seems to be a fools errand to build (or influence big names to build) complex html applications without the need to spend money or wrappers to bridge the gap. Meteor, northwest.js and electron are celebrated for attempting to accomplish these goals.

flukus 10y ago
> I think I understand but anyone should free to correct me. In every single other environment there is little to no distinction between "front end" and "back end". In fact, other than the web, the ui is a library within the language a developer chooses while in the web the scripting language is secondary to the ui. It depends. A desktop application may have a backend, like a central web service to connect to. Even if it doesn't, there is still likely to be a logical separation of layers which may or may not be in different languages (think c++ backend with a c#/xaml front end).
- formula1 10y ago
  In those situations, does the c++ service render the xaml or provide the c# to execute to provide the xaml? Or does it provide a shared storage/events/peer resolution/info collecting. Usually a server provides something much different than a web server does
  - vizeroth 10y ago
    C#/XAML on the front-end could mean that .Net/WPF is rendering the XAML and wiring up the C#. The C# might do little more than handle events triggered by the user interface and update the user interface in response to events triggered by the back end. As the potential capabilities in front-end web development increase, the differences between web development and "desktop" software development are reduced, because web developers find themselves facing more and more of the same questions software developers have always faced when dealing with distributed software architectures at scale.

rpedela 10y ago

Because I can build my application once and it works everywhere (mostly). Because I can update it whenever I want and I don't have to support multiple versions. Because there is very little friction for users to use my application, they don't have to manually download or upgrade it.

kaoD 10y ago
This. This so much. And it's safer for the user. Have you ever tried distributing binaries on the internet? People are very reluctant to run a random binary (and rightly so). Also IMH developer perspective HTML+JS+CSS is surprisingly a not so bad UI toolkit, and React makes the development experience even better. I will always bet on standards and, at least for now, modern web is the standard that I can trust.
- nkassis 10y ago
  The value of the browser sandbox is often dismissed but it's doing a great job at allowing people to run untrusted code from the web without much thought behind it. I also strongly believe users are much more willing to try websites than download entire app anyways just to see if it's any good.
xj9 10y ago
None of those things are tied directly to web technologies.
- bastawhiz 10y ago
  Which other platform truly allows you to write software once and deploy it seamlessly to just about every kind of desktop and mobile device in the world?
  - xj9 10y ago
    The browser has a great deployment story and incredible market penetration, I agree. However, none of that is because of web technologies. Browsers are special because they are everywhere, not because they are good or because JS+CSS+HTML is a special magic sauce that nobody else can replicate. We can do better.

qwtel 10y ago

> but still I don't understand why we want to build applications in browsers because that's where people's attention is. where people's attention is, is where apps are going to be built, with whatever is there to build them. if you think javascript is bad, get ready for SnapchatScript (that's not an actual project, but it all too easily could be, and something like it will be an actual project, some day)

angryasian 10y ago

>Browser apps don't make the cut. I just don't get this at all. The fact that chromium books and in the past netbooks do so well is for this reason. I can't understand why you wouldn't want browser applications at this point. Outside of write once run anywhere, security and accessibility is another benefit of the browser. We still have a huge issue with the walled garden in the app space. I'm assuming you mean primarily in the mobile space ? I think this is largely due to a failure on Apple and Google's lack of wanting to innovate because they control the app stores.

xj9 10y ago
I'm talking about performance. Browser applications are very resource intensive. That isn't a problem for rich people in developed countries, but most of the world can't afford to throw hardware at their problems. Besides, do we really think we'll be able to double hardware performance every year ad infinitum? Even Intel has given up on that pipe dream by now.
- angryasian 10y ago
  Again Ill have to disagree, there were many efforts on delivering laptops for people in third world countries that ran linux and used browser apps primarily. Even chromebooks work fine in most educational spaces in the US. http://one.laptop.org/ http://one.laptop.org/