New Web Broswer with new paradigm

[losnol]

Project description

Intro:

Today, the browsers are basically technologies build upon HTML. While it's great and have a robust support and standards, we're are currently building new concepts upon an old base.

New Web frameworks use JavaScript (or alike ) to create some way to use the DOM. Somethings it can get very nasty and difficult to build huge modular web projects/interfaces based on this approach. With the separation of layers, people try to bring this to the web development, but somethings it's hard, and most of technologies are build upon calls to the DOM and some HTML generator.

Initial Concepts:

My idea is to make an alternative to this, separating the concepts and building new technologies that can make other uses. I know that's very difficult and requires a lot of effort. And it needs a knowledge on standards and how to make this solution more global. But I think we need to start this process, and maybe my idea will make some effort in bringing new paths (if it's only a seed, and people, when they see this idea, are motivated, than I think that I've did my job, even if they try to build/use another tool - with this concepts in mind).

I'm trying to create a browser that accepts REST requests and the webpages won't be on HTML, but another thing. I'm on the very start of the concept, but came with some ideas. They're simple, not too deep, but is a path that I should go to get the results (I'll polish with time and with a better understanding).

Layers:

• View/HTML: A new file template with a DLS based on DRY, JSON and YAML. This will be something like the HTLM, but very specific, it'll be the View layer. The functionality will be to position the containers on the page. I'll care only of this. No logic, no elements.

• Style/CSS: Another template of styling DSL. Like CSS, but with heritage, class and OO simple concepts. I'll be applied to the page template or the containers (listed below).

• Containers/tags: Containers will be like some tags in HTML (, , ). Each one will be like one tag. I'll be referenced on the page viewer template. This will be like something like the controller view (but with some differences).

  Expose/REST: And to communicate with the back-end, a DSL based on REST/HTTP calls. This will expose the containers functionality to the language/framework of the back-end.

  Observations:

  • Everything is early concept. Subject to change as this idea gain maturity.

  • The initial idea is to make some parser from HTML traditional code to this new technology, so, it'll be compatible with the actual websites on production.

  Relevant Technology:

  I did some research. With my knowledge and my results, I came with an early idea of what to use to make this project. But is subject to change, with new ideas from other persons or if I come to a new technology/approach.

  So, initially, I was thinking in:

  Groovy:

  Groovy is a language that it's very dynamic. In this scenario, it'll be able to create inner DLSs (that match the idea of the layers with specific syntax and language domain). It's build on JDK, have a solid community and is maintained by Apache. It's inter-operable with Java and other languages using the JDK. With the JDK, it's possible to ensure security upon system calls, because we don't call the machine assembly directly. It follows the DRY paradigm on the code syntax and operates well with dynamic, OO and modular programming.

  BeakerX:

  BeakerX use interactive tools to build the graphic part. It's the successor of Jupyter Notebook. It uses the JDK to draw upon a application. The initial idea it's to study all the documentation to see if only with this graphic tools, it can build all graphics interfaces needed for generate all components (based on the HTML existing ones). If is possible, I'm thinking in using for generating the website content on the browser.

  Other techs and specifications:

  I'm using some JSON/YAML alike sintax for the DLSs. The idea is to use the DRY paradigm to build the development environment. I'm thinking in maintaining the HTTP/HTTPs protocols for communication. And the REST protocols for calls. So, this part, it'll be very similar to the technology used today on most browsers, but with some minor changes and updates.

  Appends, updates, FAQ:

  I'm thinking in maintaining some feedback here and posting something useful here if I get some feedback.

  Patterns:

  The idea is to adopt W3C as far as possible. Need a study on how it works and what to do to make this a HTML5 full compatible (or as close as possible/I can).

  Compatibility:

  I need some research on this. But the initial idea is to make a parser that transforms the HTML based webpages on the browser syntax and vise-versa. I don't discard a parser and a sub-engine that runs directly the HTML, or integration with other engines (like Google v8). Need a lot of study on that subject.

  What help I'm looking for:

  I'm trying to modularize as much as I can, so it'll be a opensource project that specific people can help on specific topics, without the need of knowing everything. But I'm looking for a few people that understands the idea and can help me with building/managing this type of Open Source structure, as well the software engineering of this project as hole.

  Other subjects:

  I'm thanking everyone that took the time to read this. And thanks, before-wards, everyone that will answer or comment this topic idea.

  And sorry for my bad English.

  Complexity and required time:

  This idea is very complex. The time, probably, will be very long and a continuous development environment (if this idea goes further).

  Complexity:

  • [ ] Beginner - This project requires no or little prior knowledge of the technolog(y|ies) specified to contribute to the project
  • [ ] Intermediate - The user should have some prior knowledge of the technolog(y|ies) to the point where they know how to use it, but not necessarily all the nooks and crannies of the technology
  • [X] Advanced - The project requires the user to have a good understanding of all components of the project to contribute

  Required time (ETA):

  • [ ] Little work - A couple of days
  • [ ] Medium work - A week or two
  • [X] Much work - The project will take more than a couple of weeks and serious planning is required

  Categories:

  • [ ] Mobile app
  • [ ] IoT
  • [ ] Web app
  • [ ] Frontend/UI
  • [ ] AI/ML
  • [ ] APIs/Backend
  • [ ] Voice Assistant
  • [ ] Developer Tooling
  • [ ] Extension/Plugin/Add-On
  • [ ] Design/UX
  • [ ] AR/VR
  • [ ] Bots
  • [ ] Security
  • [ ] Blockchain
  • [X] Futuristic Tech/Something Unique

  KOLANICH commented 5 years ago

  Containers will be like some tags in HTML

  Do you mean custom tags? They are already implemented and widely adopted (for example by Google).

  KOLANICH commented 5 years ago

  Like CSS, but with heritage, class and OO simple concepts. I'll be applied to the page template or the containers (listed below).

  It seems there is no need in classical OOP in CSS. Could you mind a use case?

  KOLANICH commented 5 years ago

  A new file template with a DLS based on DRY, JSON and YAML. This will be something like the HTLM, but very specific, it'll be the View layer. The functionality will be to position the containers on the page. I'll care only of this. No logic, no elements.

  I don't quite understand. Do you mean some declarative non-Turing-complete framework for AJAX applications? Something like html but driven by the data got from websocket without any bit of server-supplied JS? Like a mix of IRC and X11, where server takes role of X-client and a browser tab takes role of X-server?

  losnol commented 5 years ago

  Hello there. Thanks for the reply!

  Containers will be like some tags in HTML

  Do you mean custom tags? They are already implemented and widely adopted (for example by Google).

  Oh. My bad. I was meaning something different. On web development in HTML, we use some tags with attributes and something inside.

  For example:

  <li data-type="veg" data-distance="2miles" data-identifier="10318" data-owner-name="someName">

  My idea was to abstract this and separate concepts. I think it'll be clear if I present some pseudo-code (just a initial idea and to show what I have in mind):

  • My view:

    
    Import "<my_page_component_files.MyDLSExtensonForComponentListing>"
    Import "<my_page_style_files.MyDSLExtensionForView>"
    Head {
    //Some Configurations, like the page, link, etc...
    }
    Body {
    Component: { Component:<MyComponent>,
     ApplyStyle: <MyStyle>,
     Position "<Some simply position Logic>"
    }
    }

  
    * My Components for this page:
  

  MyComponent : <"MyComponentType> { Atribute1: "", Function1: "", //Can have some data and/or triggers }

   * The component declaration (Like a lib):
  

  class MyComponentType extends AbstractBaseComponent implements button, trigger, auto-updatable /some ideas of component heritage/ { def Atribute1; def Function1 = AbstractComponentDynamicFunction(MyTag);

  / Other values... ... ... / @Override void onInit() { }

  @Override void onChange() { }

  }

  
  
  I'm thinking on some static and default components for using in simple things, like button, href (and then you can just call on page components file with default values). And each view file will have the component list relative.

  losnol commented 5 years ago

  Like CSS, but with heritage, class and OO simple concepts. I'll be applied to the page template or the containers (listed below).

  It seems there is no need in classical OOP in CSS. Could you mind a use case?

  I usually can't override data the CSS on some children of a tag. Sure, sometimes is dangerous, but I think it can have a better approach by heritage, with some rules. Maybe some simple OO concepts, that uses some composition or heritage. But maybe I can work around with another ideas too. It was what I tough initially.

  losnol commented 5 years ago

  A new file template with a DLS based on DRY, JSON and YAML. This will be something like the HTLM, but very specific, it'll be the View layer. The functionality will be to position the containers on the page. I'll care only of this. No logic, no elements.

  I don't quite understand. Do you mean some declarative non-Turing-complete framework for AJAX applications? Something like html but driven by the data got from websocket without any bit of server-supplied JS? Like a mix of IRC and X11, where server takes role of X-client and a browser tab takes role of X-server?

  I wasn't thinking by this perspective, but it's quite interesting. My idea is, let's say (very simplified), generate byte-code build for the pages and put on the server. This is what I'll get with a REST GET from the server. And then on my browser I do the logic to get back the data and render the page on the browser.

  genjudev commented 4 years ago

  Are you willing to push in the market or do you want to try something different and maybe get some ideas and solutions to support the existing technologie.

  losnol commented 4 years ago

  Are you willing to push in the market or do you want to try something different and maybe get some ideas and solutions to support the existing technologie.

  Hello! I'm thinking on the second option by now. Maybe, if this goes well, I'm into developing something new for the market.

  amirouche commented 4 years ago

  I sympathize with the background story behind this idea

  Today, the browsers are basically technologies build upon HTML. While it's great and have a robust support and standards, we're are currently building new concepts upon an old base.

  View/HTML: A new file template with a DSL based on DRY, JSON and YAML. This will be something like the HTML, but very specific, it'll be the View layer.

  YAML

  YAML is not meant to write big document [refernce needed]. It is good for small configuration files and anyone that had to deal with Ansible (gasp) will agree.

  JSON

  Really, JSON is not easy to read nor to write by hand.

  Maybe microxml is what you are looking for https://www.w3.org/community/microxml/

  The functionality will be to position the containers on the page. I'll care only of this. No logic, no elements.

  In the strict sense of MVC, the view does ONLY carry presentation information. What you describe "like HTML" does actually carry informantion + presentation hint / instructions.

  Style/CSS: Another template of styling DSL. Like CSS, but with heritage, class and OO simple concepts. I'll be applied to the page template or the containers (listed below).

  CSS is mostly a bad idea even more so if it turing complete. The current web stack, takes several months to learn, years to somewhat pretend mastery. Increasing the number of DSL (and syntaxes) will not help.

  Will the "new CSS" share syntax with the view layer?

  See also https://github.com/ocornut/imgui/

  See also gtk3, qt... What I want to say is that presentation takes years to master and ui/ux designers still dislike it. WYSIWYG anyone?

  Containers/tags: Containers will be like some tags in HTML (, , ). Each one will be like one tag. I'll be referenced on the page viewer template. This will be like something like the controller view (but with some differences).

  This paragraph is too fuzzy. I don't understand.

  Expose/REST: And to communicate with the back-end, a DSL based on REST/HTTP calls. This will expose the containers functionality to the language/framework of the back-end.

  See also GraphQL et al.

  amirouche commented 4 years ago

  I will add that calling that a "new paradigm" is bold claim when the surface is very similar (client-server architecture, HTTP network protocol, wanna-be MVC approach).

  I sympathize with the background story behind this idea. But the proposal is not enough. It is not clear what it must achieve.

  Does aim to cancel legacy cruft and backward compatibility?

  My idea is to rely on peer-to-peer tools and progressively "backtrack" to nix distribution networks. See https://github.com/open-source-ideas/open-source-ideas/issues/163

  losnol commented 4 years ago

  YAML is not meant to write big document [refernce needed]. It is good for small configuration files and anyone that had to deal with Ansible (gasp) will agree.

  JSON

  Really, JSON is not easy to read nor to write by hand.

  Maybe microxml is what you are looking for https://www.w3.org/community/microxml/

  That's a point. I'm still thinking what will be the best choice. The idea is to write clean and simple code, with some complexity and can be manageble by the browser engine.

  In the strict sense of MVC, the view does ONLY carry presentation information. What you describe "like HTML" does actually carry informantion + presentation hint / instructions.

  I agree, but I'm trying to make something a little familiar too for the actual devs. This is subject to change and defined better with time.

  Style/CSS: Another template of styling DSL. Like CSS, but with heritage, class and OO simple concepts. I'll be applied to the page template or the containers (listed below).

  CSS is mostly a bad idea even more so if it turing complete. The current web stack, takes several months to learn, years to somewhat pretend mastery. Increasing the number of DSL (and syntaxes) will not help.

  Will the "new CSS" share syntax with the view layer?

  See also https://github.com/ocornut/imgui/

  See also gtk3, qt... What I want to say is that presentation takes years to master and ui/ux designers still dislike it. WYSIWYG anyone?

  Well... I think that it have to be done something to styling, but it's complicated. It's a tradeoff btween what's new or what devs know. I think that's a hard question/decision to make and to have a solution with these 2 points in mind.

  Containers/tags: Containers will be like some tags in HTML (, , ). Each one will be like one tag. I'll be referenced on the page viewer template. This will be like something like the controller view (but with some differences).

  This paragraph is too fuzzy. I don't understand.

  I was thinking on containers as a piece of functionality/code/small component that repeats a lot, so it can be "clustered" into a small definition/piece of code.

  losnol commented 4 years ago

  I will add that calling that a "new paradigm" is bold claim when the surface is very similar (client-server architecture, HTTP network protocol, wanna-be MVC approach).

  I sympathize with the background story behind this idea. But the proposal is not enough. It is not clear what it must achieve.

  Does aim to cancel legacy cruft and backward compatibility?

  My idea is to rely on peer-to-peer tools and progressively "backtrack" to nix distribution networks. See #163

  Maybe I was too optimistic or exaggerated. But I see some new ideas and maybe a path to achieve.

  I was thinking in make the legacy compatibility as a long term solution. But in a distant future, maybe it won't be needed anymore.

  remram44 commented 4 years ago

  This seems like you need to put more thought into this before you post this as a project idea. It is really not clear what you think you are doing. You are describing things that feel like they could be implemented as a JavaScript framework, running on current browser technology unmodified; in fact it reminds me of Dart.

  If you don't need help and are just "thinking out loud" or drafting a blog post, I'm interested in looking into it when ready, but I'm not sure how this can be an open-source project right now?

  amirouche commented 4 years ago

  Also see https://en.wikipedia.org/wiki/Solid_(web_decentralization_project)

  losnol commented 4 years ago

  This seems like you need to put more thought into this before you post this as a project idea. It is really not clear what you think you are doing. You are describing things that feel like they could be implemented as a JavaScript framework, running on current browser technology unmodified; in fact it reminds me of Dart. If you don't need help and are just "thinking out loud" or drafting a blog post, I'm interested in looking into it when ready, but I'm not sure how this can be an open-source project right now?

  Hello! I have a good idea of where to start. I have the Technologies. Further requirements analysis should be done. But, by the Project nature and the idea, I think it's better to do a more definitive planning during the developing. To summarize, at starting point, it should focus on creating an environment in Groovy with the frameworks I pointed. Then focusing on mapping W3C standards on the initial developmental guide. This is a good starting point IMHO.

  • © Githubissues.
  • Githubissues is a development platform for aggregating issues.

[KOLANICH]

Containers will be like some tags in HTML

Do you mean custom tags? They are already implemented and widely adopted (for example by Google).

[KOLANICH]

Like CSS, but with heritage, class and OO simple concepts. I'll be applied to the page template or the containers (listed below).

It seems there is no need in classical OOP in CSS. Could you mind a use case?

[KOLANICH]

A new file template with a DLS based on DRY, JSON and YAML. This will be something like the HTLM, but very specific, it'll be the View layer. The functionality will be to position the containers on the page. I'll care only of this. No logic, no elements.

I don't quite understand. Do you mean some declarative non-Turing-complete framework for AJAX applications? Something like html but driven by the data got from websocket without any bit of server-supplied JS? Like a mix of IRC and X11, where server takes role of X-client and a browser tab takes role of X-server?

[losnol]

Hello there. Thanks for the reply!

Containers will be like some tags in HTML

Do you mean custom tags? They are already implemented and widely adopted (for example by Google).

Oh. My bad. I was meaning something different. On web development in HTML, we use some tags with attributes and something inside.

For example:

<li data-type="veg" data-distance="2miles" data-identifier="10318" data-owner-name="someName">

My idea was to abstract this and separate concepts. I think it'll be clear if I present some pseudo-code (just a initial idea and to show what I have in mind):

• My view:

  
  Import "<my_page_component_files.MyDLSExtensonForComponentListing>"
  Import "<my_page_style_files.MyDSLExtensionForView>"
  Head {
  //Some Configurations, like the page, link, etc...
  }
  Body {
  Component: { Component:<MyComponent>,
   ApplyStyle: <MyStyle>,
   Position "<Some simply position Logic>"
  }
  }

  * My Components for this page:

MyComponent : <"MyComponentType> { Atribute1: "", Function1: "", //Can have some data and/or triggers }

 * The component declaration (Like a lib):

class MyComponentType extends AbstractBaseComponent implements button, trigger, auto-updatable /some ideas of component heritage/ { def Atribute1; def Function1 = AbstractComponentDynamicFunction(MyTag);

/ Other values... ... ... / @Override void onInit() { }

@Override void onChange() { }

}

I'm thinking on some static and default components for using in simple things, like button, href (and then you can just call on page components file with default values). And each view file will have the component list relative.

[losnol]

Like CSS, but with heritage, class and OO simple concepts. I'll be applied to the page template or the containers (listed below).

It seems there is no need in classical OOP in CSS. Could you mind a use case?

I usually can't override data the CSS on some children of a tag. Sure, sometimes is dangerous, but I think it can have a better approach by heritage, with some rules. Maybe some simple OO concepts, that uses some composition or heritage. But maybe I can work around with another ideas too. It was what I tough initially.

[losnol]

A new file template with a DLS based on DRY, JSON and YAML. This will be something like the HTLM, but very specific, it'll be the View layer. The functionality will be to position the containers on the page. I'll care only of this. No logic, no elements.

I don't quite understand. Do you mean some declarative non-Turing-complete framework for AJAX applications? Something like html but driven by the data got from websocket without any bit of server-supplied JS? Like a mix of IRC and X11, where server takes role of X-client and a browser tab takes role of X-server?

I wasn't thinking by this perspective, but it's quite interesting. My idea is, let's say (very simplified), generate byte-code build for the pages and put on the server. This is what I'll get with a REST GET from the server. And then on my browser I do the logic to get back the data and render the page on the browser.

[genjudev]

Are you willing to push in the market or do you want to try something different and maybe get some ideas and solutions to support the existing technologie.

[losnol]

Are you willing to push in the market or do you want to try something different and maybe get some ideas and solutions to support the existing technologie.

Hello! I'm thinking on the second option by now. Maybe, if this goes well, I'm into developing something new for the market.

[amirouche]

I sympathize with the background story behind this idea

Today, the browsers are basically technologies build upon HTML. While it's great and have a robust support and standards, we're are currently building new concepts upon an old base.

View/HTML: A new file template with a DSL based on DRY, JSON and YAML. This will be something like the HTML, but very specific, it'll be the View layer.

YAML

YAML is not meant to write big document [refernce needed]. It is good for small configuration files and anyone that had to deal with Ansible (gasp) will agree.

JSON

Really, JSON is not easy to read nor to write by hand.

Maybe microxml is what you are looking for https://www.w3.org/community/microxml/

The functionality will be to position the containers on the page. I'll care only of this. No logic, no elements.

In the strict sense of MVC, the view does ONLY carry presentation information. What you describe "like HTML" does actually carry informantion + presentation hint / instructions.

Style/CSS: Another template of styling DSL. Like CSS, but with heritage, class and OO simple concepts. I'll be applied to the page template or the containers (listed below).

CSS is mostly a bad idea even more so if it turing complete. The current web stack, takes several months to learn, years to somewhat pretend mastery. Increasing the number of DSL (and syntaxes) will not help.

Will the "new CSS" share syntax with the view layer?

See also https://github.com/ocornut/imgui/

See also gtk3, qt... What I want to say is that presentation takes years to master and ui/ux designers still dislike it. WYSIWYG anyone?

Containers/tags: Containers will be like some tags in HTML (, , ). Each one will be like one tag. I'll be referenced on the page viewer template. This will be like something like the controller view (but with some differences).

This paragraph is too fuzzy. I don't understand.

Expose/REST: And to communicate with the back-end, a DSL based on REST/HTTP calls. This will expose the containers functionality to the language/framework of the back-end.

See also GraphQL et al.

[amirouche]

I will add that calling that a "new paradigm" is bold claim when the surface is very similar (client-server architecture, HTTP network protocol, wanna-be MVC approach).

I sympathize with the background story behind this idea. But the proposal is not enough. It is not clear what it must achieve.

Does aim to cancel legacy cruft and backward compatibility?

My idea is to rely on peer-to-peer tools and progressively "backtrack" to nix distribution networks. See https://github.com/open-source-ideas/open-source-ideas/issues/163

[losnol]

YAML is not meant to write big document [refernce needed]. It is good for small configuration files and anyone that had to deal with Ansible (gasp) will agree.

JSON

Really, JSON is not easy to read nor to write by hand.

Maybe microxml is what you are looking for https://www.w3.org/community/microxml/

That's a point. I'm still thinking what will be the best choice. The idea is to write clean and simple code, with some complexity and can be manageble by the browser engine.

In the strict sense of MVC, the view does ONLY carry presentation information. What you describe "like HTML" does actually carry informantion + presentation hint / instructions.

I agree, but I'm trying to make something a little familiar too for the actual devs. This is subject to change and defined better with time.

Style/CSS: Another template of styling DSL. Like CSS, but with heritage, class and OO simple concepts. I'll be applied to the page template or the containers (listed below).

CSS is mostly a bad idea even more so if it turing complete. The current web stack, takes several months to learn, years to somewhat pretend mastery. Increasing the number of DSL (and syntaxes) will not help.

Will the "new CSS" share syntax with the view layer?

See also https://github.com/ocornut/imgui/

See also gtk3, qt... What I want to say is that presentation takes years to master and ui/ux designers still dislike it. WYSIWYG anyone?

Well... I think that it have to be done something to styling, but it's complicated. It's a tradeoff btween what's new or what devs know. I think that's a hard question/decision to make and to have a solution with these 2 points in mind.

Containers/tags: Containers will be like some tags in HTML (, , ). Each one will be like one tag. I'll be referenced on the page viewer template. This will be like something like the controller view (but with some differences).

This paragraph is too fuzzy. I don't understand.

I was thinking on containers as a piece of functionality/code/small component that repeats a lot, so it can be "clustered" into a small definition/piece of code.

[losnol]

I will add that calling that a "new paradigm" is bold claim when the surface is very similar (client-server architecture, HTTP network protocol, wanna-be MVC approach).

I sympathize with the background story behind this idea. But the proposal is not enough. It is not clear what it must achieve.

Does aim to cancel legacy cruft and backward compatibility?

My idea is to rely on peer-to-peer tools and progressively "backtrack" to nix distribution networks. See #163

Maybe I was too optimistic or exaggerated. But I see some new ideas and maybe a path to achieve.

I was thinking in make the legacy compatibility as a long term solution. But in a distant future, maybe it won't be needed anymore.

[remram44]

This seems like you need to put more thought into this before you post this as a project idea. It is really not clear what you think you are doing. You are describing things that feel like they could be implemented as a JavaScript framework, running on current browser technology unmodified; in fact it reminds me of Dart.

If you don't need help and are just "thinking out loud" or drafting a blog post, I'm interested in looking into it when ready, but I'm not sure how this can be an open-source project right now?

[amirouche]

Also see https://en.wikipedia.org/wiki/Solid_(web_decentralization_project)

[losnol]

This seems like you need to put more thought into this before you post this as a project idea. It is really not clear what you think you are doing. You are describing things that feel like they could be implemented as a JavaScript framework, running on current browser technology unmodified; in fact it reminds me of Dart. If you don't need help and are just "thinking out loud" or drafting a blog post, I'm interested in looking into it when ready, but I'm not sure how this can be an open-source project right now?

Hello! I have a good idea of where to start. I have the Technologies. Further requirements analysis should be done. But, by the Project nature and the idea, I think it's better to do a more definitive planning during the developing. To summarize, at starting point, it should focus on creating an environment in Groovy with the frameworks I pointed. Then focusing on mapping W3C standards on the initial developmental guide. This is a good starting point IMHO.