Announcement

Collapse
No announcement yet.

Rust 1.14 Released With Experimental WebAssembly Support

Collapse
X
Collapse
 
  • Page of 2
  • Filter
  • Time
  • Show
Clear All
new posts
Previous 1 2 template Next
  • cj.wijtmans
    replied
    Originally posted by Stoatally View Post

    It's especially frustrating as PHP integrates with libxml and libxsl really well, I've personally been involved in many PHP projects that did render valid XHTML, but for whatever reason the world seems perfectly content with the utter pile of trash that is WordPress.
    you know anything better?

    Leave a comment:

  • Stoatally
    replied
    Originally posted by caligula View Post

    XHTML is a problem for code generation. You can't just copy and paste strings without keeping track of the DOM. People using the lesser languages such as PHP can't be bothered to learn anything new. They want web pages to simply work like any play text file written using latin1 encoding or some other 1980s code page.
    It's especially frustrating as PHP integrates with libxml and libxsl really well, I've personally been involved in many PHP projects that did render valid XHTML, but for whatever reason the world seems perfectly content with the utter pile of trash that is WordPress.

    Leave a comment:

  • starshipeleven
    replied
    Originally posted by bug77 View Post
    "Lesser evil" implies alternatives were considered and there was no better option.
    "No better option" does not mean that they are/were good and that they shouldn't die in a fire asap, only that:
    -alternatives were worse
    -there was no (credible) alternative at all

    Or, in other words, "lesser evil is still evil, just less than other options considered".

    Leave a comment:

  • bug77
    replied
    Originally posted by starshipeleven View Post
    *almost always about technologies that were choosen as the "lesser evil" even if they weren't that good to begin with.
    "Lesser evil" implies alternatives were considered and there was no better option. Hindsight is always 20/20 and I think that is especially true for software.

    I'm all for evolving code (aggressive refactoring is one of my things), but before you tear something down, you'd better make sure you have something else to put in place. Something that covers all the existing, non-deprecated use cases.

    Leave a comment:

  • starshipeleven
    replied
    Originally posted by bug77 View Post
    If I had a dime for each time I've heard "this technology is bad and need to die". It's almost always about technologies that have carried us for a decade or more. To name just a few we have: C, http, Java or Xorg.
    *almost always about technologies that were choosen as the "lesser evil" even if they weren't that good to begin with.

    Leave a comment:

  • skierpage
    replied
    Originally posted by mmstick View Post

    Seems that would be simple to do if browser vendors were to work together on an ultimate standard. Basically, we would just need a new universal HTML standard with strict requirements (no special browser-specific features), and when the web browser encounters a webpage that has a tag telling the browser that it's the new standard, it chooses the correct HTML parsing engine internally.
    We have that, just put <!DOCTYPE html> and the browser knows it's seeing an HTML5 page and use its no-quirks latest parser. The excellent WHATWG specs tell browsers exactly what to do. It's still up to developers to test for features and use fallbacks or polyfills to support functionality they require; that's hard work compared with just getting it to work on current Chrome, but browser makers and developers have a spec to follow.

    The idea that closing tags to make a validating XHTML document would somehow improve web compatibility is laughable. XHTML concerned itself with the wrong problem.

    Leave a comment:

  • bug77
    replied
    Originally posted by Luke_Wolf View Post

    HTML still needs to die in a fire and be replaced with an actual standard for web applications to run as efficiently as a native desktop application, keep in mind that it requires a minimum of 3 engines internally in order to "correctly" parse HTML, one for conformant interpretation, another for loose interpretation, and another for quirks, and then there may be additional ones for compatibility with other browsers.
    If I had a dime for each time I've heard "this technology is bad and need to die". It's almost always about technologies that have carried us for a decade or more. To name just a few we have: C, http, Java or Xorg.
    • Likes 1

    Leave a comment:

  • liam
    replied
    Originally posted by mmstick View Post

    Not completely, but mostly. WebAssembly is an emscripten technology and requires Javascript to import/execute it. Javascript can be used as glue code while machine code from compiled languages like Rust do all the heavy-lifting, sort of how Python is often used for on the desktop.
    Just a nit: js isn't REQUIRED but suggested (and it's expected that these early wasm implementations will use the js engine). Through opaque reference types they want to allow wasm to directly manipulate the page through web apis.
    Keep in mind that, despite its name, wasm isn't intended just to use on the web. They mention some other deployment types they'd like to accommodate like stand alone apps or platform target.

    Page not found ยท GitHub Pages
    http://webassembly.org/docs/gc/#opaque-reference-types

    Non-Web Embeddings - WebAssembly
    http://webassembly.org/docs/non-web/

    Leave a comment:

  • liam
    replied
    Originally posted by Luke_Wolf View Post

    HTML still needs to die in a fire and be replaced with an actual standard for web applications to run as efficiently as a native desktop application, keep in mind that it requires a minimum of 3 engines internally in order to "correctly" parse HTML, one for conformant interpretation, another for loose interpretation, and another for quirks, and then there may be additional ones for compatibility with other browsers.
    It's not just html but the DOM (and css...but css itself might be salvageable). Until we get an alternative (not necessarily a replacement, but an alternate way structure your app.....frankly, if XHTML had been fully developed and adopted it might've done the trick) to that, we're just shoe horning a general application framework into a system designed for creating documents.
    Regardless, web components are certainly moving things forward, and along with new layout engines coupled with hardware accelerated rendering, it is getting easier (react doesn't hurt either).

    Leave a comment:

  • caligula
    replied
    Originally posted by Luke_Wolf View Post

    That would be great, but in principle that was called XHTML and much tantruming was had by web developers that weren't willing to write well formed XML documents so it got killed and we got stuck with the continued status quo with HTML5. So I'm not really hopeful on any sort of actual strict standard coming into place anytime soon as opposed to the "Don't Let the user see any errors" that it is now.
    XHTML is a problem for code generation. You can't just copy and paste strings without keeping track of the DOM. People using the lesser languages such as PHP can't be bothered to learn anything new. They want web pages to simply work like any play text file written using latin1 encoding or some other 1980s code page.

    Leave a comment:

Previous 1 2 template Next
Working...
X