Coffeehouse Thread

36 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Sell your PowerPoint stocks

Back to Forum: Coffeehouse
  • User profile image
    bondsbw

    @Bass: Sure, we have the server side down to an art.  But I say it's time we create a replacement for HTML: a standard bytecode language suitable for transmission.

    Somewhere between HTML and native apps (like Windows 8 apps or Android/iPhone apps), there has to be something better.  HTML is slow and many sites transmit significant amounts of data.

    Apps are fast and transmit less data, but severely lack the openness of HTML.  Apps must be downloaded in advance.  They mostly lack ability to link via URI.  They can't be indexed by search engines.  And they are tied to a single platform (increasing development costs).

    I want something in between.  Do I have to wait until the 2020s?

  • User profile image
    Bass

    @bondsbw:

    The idea of a bytecode for the web was proposed IIRC, and I supported the idea and proposed it here (perhaps independently?) a few years back. I'm actually now quite opposed to any idea that would introduce any kind of bytecode to the web.

    • Bytecodes don't necessarily translate to better performance: people overrate the amount of effort it takes a modern computer to parse a few kilobytes of text. IIRC the amount of effort needed to generate a DOM and actually display stuff on the screen is where most of the work is; as well as manipulating and rerendering the DOM after the fact. Also, HTTP supports compression which reduces the size of the HTML. Performance is not optimal of course, but there are bigger flaws in HTTP that are more low hanging fruit (ie. won't fundamentally change how people develop things) that still haven't been universally addressed (Google has tried with SPDY aka HTTP 2.0, which IIRC is supported in Firefox and Chrome but nowhere else).
    • Bytecodes require special tools to generate, increasing the barrier of entry.
    • Bytecodes are harder to inspect, negating one of the things that makes the web so practical and open (Right Click -> View Source). This feature is I think is how a lot of people learned web development to start with, myself included.
    • Bytecodes can cause an overspamming of programming languages in the market, making web development more complicated and more to learn unless you want to limit your experience on one specific stack. Basically, your skills might not transfer. There are JS-as-bytecode type languages (Microsoft made one called TypeScript, and I personally use CoffeeScript), but don't try to be TOO different from JavaScript, probably because of the limitations of making JS a compile target.
    • Getting an agreement between browser markers on a bytecode will be impossible, especially given all the above. This is probably the most damning point.
  • User profile image
    blowdart

    Google has tried with SPDY aka HTTP 2.0

    Or HTTP 2.0 could be HTTP S&M (Well done MS product namers) which extends SPDY beyond the browser.

    The HTTPBIS group have SPDY won't be 2.0, but will influence it. Hopefully so it protects against CRIME SSL attacks, which SPDY enabled Smiley

  • User profile image
    Bass

    @blowdart:

    Thanks for the info, I didn't realize Microsoft was also involved as well in HTTP 2.0. Having Google and Microsoft working on it is a very good thing, they both have talented engineers. Making the web faster and more secure for everyone is a worthwhile goal, thanks for your effort.

  • User profile image
    evildictait​or

    , Bass wrote

    Bytecodes don't necessarily translate to better performance: people overrate the amount of effort it takes a modern computer to parse a few kilobytes of text.

    And yet browser vendors resort to dirty tricks to get smaller benefits - like pre-emptive TCP/SSL-negotations and DNS-lookups precisely to get millisecond speedups at the start of the page. Connection:keep-alive and Content-Encoding: gzip/spdy/deflate is another example where minor speed benefits warranted major changes in the protocol - so I don't believe that "the parsing cost is negligible" argument is, or has ever been valid for the web.

    Secondly - have you ever tried to actually parse HTML? it's a really horrendous language to parse. The tokeniser takes O(n) on the text (including every comment and whitespace), and tokens are maybe five or six times longer than a bytecode equivilent - so tokenizing is right out-of-the-gate 5 times slower than a bytecode representation.

    Next, there's the huge cost is turning these bytes into a DOM. This is expensive because HTML is badly designed.

    The number of stupid rules in HTML parsing is one of the key reasons why sites don't work cross-browser for free. Rules like <b><p>foo<p>bar</b> turning into <b><p>foo</p><p>bar</p></b> and <b id="_1"><p><i id="_2">foo</b></i><p>bar</b> turning <p><b id="_1"><i id="_2">foo</i></b></p><p><b id="_1">bar</b></p> are cases in point.

    And the redundancy in HTML is appalling. If you want a red bit of text you can use <font color="red">, <span style="color:red">, <span class="redcolor">, <div style="display:inline-block;color:red">. Want to put in a quote? How about using <blockquote>, <q>, <span style="font-style:italic">, <div style="font-style:italic;display:inline-block"> or even <div class="quotestyle_class">

    A consequence of this is that browsers don't actually render the DOM. They convert it first into a pseduo-dom (mozilla calls it a flow-dom, microsoft calls it the render-tree) which is normalized to divs with styles - but because javascript interacts with the non-flow DOM, the browser spends loads of time after each javascript interaction having to regenerate the (now invalidated) flow-DOM.

    Javascript is another example of the web just frankly getting it wrong. Browsers are today squeezing performance out of javascript by inferring types (JITs always prefer strong types because then you can do an ADD instead of a CALL _javascriptThunkVariableAdd for 1+2). But if Javascript was strongly typed to start off with, you wouldn't need to infer the types in the first place - saving valuable milliseconds at the start of each page.

    JITs also have massive pressure to compile quickly - something that normal compilers don't have. This means that is a compiler optimisation gives you 2% speedup but 10seconds to perform, Javascript won't apply that optimisation. If you compiled it to bytecodes, you might.

    Bytecodes require special tools to generate, increasing the barrier of entry.

    Bytecodes can cause an overspamming of programming languages in the market, making web development more complicated and more to learn unless you want to limit your experience on one specific stack. Basically, your skills might not transfer. There are JS-as-bytecode type languages (Microsoft made one called TypeScript, and I personally use CoffeeScript), but don't try to be TOO different from JavaScript, probably because of the limitations of making JS a compile target.

    The argument that HTML makes writing for the web easier is a complete lie. When I write a Win32 program, I can choose to learn C# or C++ or VB, and that will take me comfortably all the way through to a pixel-perfect app that works on anyone's machine, be it Dell or Asus or whatever. It'll just work.

    But let's contrast that with the number of languages you need to learn to be good at the web. To write good Win32 programs, I need to learn C++ or C# or VB. To learn the web I need to learn (C# or VB or PHP or Ruby) and (HTML and CSS and Javascript) and (JSON or AJAX) and SQL.

    And even with all of that, it still won't work for free on Firefox and IE and Chrome! You need to do vastly more testing of a minor website than an equivalent Win32 program.

    And let's contrast the difference between if you get it wrong. If I screw up a C++ app, I might accidentally leave in a heap-buffer overflow. But DEP+ASLR+Heap cookies are likely to make exploitation of that really hugely hard. On the web, that buffer overflow won't be there, but you'll have SQL-injection, code-injection (via php include/eval etc) just littered about the app. You don't get security for free here because the unification of strings and code make it impossible to secure for free.

    Bytecodes are harder to inspect, negating one of the things that makes the web so practical and open (Right Click -> View Source). This feature is I think is how a lot of people learned web development to start with, myself included.

    Designing a language which goes out of its way to make programs written for it easy to plagurize is baffling. In my mind, it is a major weakness of the web, rather than one of its strengths.

    I learnt C# without much difficulty using online tutorials, books and just plain old fashioned trial and error. I didn't need to learn by viewing the source of other people's apps. I don't see why web developers are such a special case that they can't learn like a normal person - you know - but not stealing other people's IPR.

    Getting an agreement between browser markers on a bytecode will be impossible, especially given all the above. This is probably the most damning point.

    Getting an agreement between browser manufacturers about anything is impossible, so I reject that argument directly. You want a box-shadow? You better be prepared to put in six completely vendor specific CSS names to get it. How about a linear gradient? Again, you're going to need some -moz- and -webkit and -o prefxes there. The list goes on.

     

    My contention then is this: The web is not successful because of HTML and Javascript. It is successful despite them.

    If HTTP, HTML and Javascript had been properly designed, I'm under no doubt that the experience of the web would be better right now.

  • User profile image
    Bass

    @evildictaitor:

    I realize you're not a big fan of web technology. I don't think web technology is perfect, but it is worth looking on the positives and the negatives. The combination of simplicity, ease of access, openness, security, marketshare, etc. etc. the web is often the best solution for exposing a user interface to your applications.

    Also I don't think it's productive to linger too much in "it's not perfect enough" territory. As much as I think the English language is completely and utterly broken (and there are far better designed natural languages), I'm still using it because that's the best way to "interoperate" with people on this forum. I tend to look at technology stacks in the same fashion, as much as I enjoy Erlang, it's not realistic to rewrite a 1 million line codebase in it because I don't like how JavaScript's faux-equality operator works in corner cases.

    I personally haven't been actively seeking web development work, nor have I specifically trained for it. But it seems to be what the people who pay me want. It's always either "write a web app" or "convert this thick-client thing some random guy made 10 years ago into a web app" for me. I did so some thing with Winforms/C# a a few years back, but that was only because the project manager decided it would be difficult to do using web technology (probably not the case any more, with the latest advancements on the web).

    In the end of the day the market decides technology choices. Not dictators. Smiley

  • User profile image
    Bass

    I'd also like to mention that with node.js and MongoDB, you can have JavaScript (or CoffeeScript Smiley) all the way up and down the development stack (incl. the DB layer).

  • User profile image
    evildictait​or

    , Bass wrote

    @evildictaitor:

    I realize you're not a big fan of web technology. I don't think web technology is perfect, but it is worth looking on the positives and the negatives. The combination of simplicity, ease of access, openness, security, marketshare, etc. etc. the web is often the best solution for exposing a user interface to your applications.

    The problem is that, as I see it the web fails on most of those fronts.

    As I said before, to write a good webapp you need to learn (C# or VB or PHP or Ruby or node.js) and HTML and CSS and Javascript and (JSON or AJAX) and SQL. So it loses on simplicity compared to my just C# (the compiler can automake the crufty SQL/JSON/HTML/CSS/JS crap for you - there's no reason to have a billion crappy half-hearted languages for the web).

    It's probably quite good for ease of access - but it's not a panacea. I can write documents and fill out spreadsheets on a plane with Office 2007, but I can't with Google Docs.

    And openness is a bit of a joke too - my Word documents are mine because it runs on my machine. But my google docs? No - that belongs to Google. If Google wants to charge me for it in future, I have to cough up the cash. If Google wants to change the interface or drop features I need? Sucks to be me. With Office on my machine at least I get to veto a change of interface.

    Case in point; I like the VS2010 interface. I don't like the VS2012 interface. I have chosen not to upgrade. If Visual Studio was on the web, I would have zero choice in the matter.

    Facebook and Google and increasingly Microsoft go to lengths to wrest your data out of your hands and they don't like giving it back. That's quite a contrast to lots of apps on my desktop who put all of my content in easy-to-access forms in files on my desktop.

    And security? Are you high? SQL injections count for almost all 0-days. They are easy to find and easy to exploit - in total contrast to native apps.

    Also I don't think it's productive to linger too much in "it's not perfect enough" territory. As much as I think the English language is completely and utterly broken (and there are far better designed natural languages), I'm still using it because that's the best way to "interoperate" with people on this forum. I tend to look at technology stacks in the same fashion, as much as I enjoy Erlang, it's not realistic to rewrite a 1 million line codebase in it because I don't like how JavaScript's faux-equality operator works in corner cases.

    I wasn't trying to linger. I was just opposing the notion that "neat" HTML output is somehow a thing that end-users give a damn about.

    And for the record - I do occasionally write websites. But I do so by writing C# code that interact with abstractions that spit out HTML. That way I get to make a one-size-fits-all login page and use that for all sites I make that use a login page. I have no sentimental attachment to HTML, because if tomorrow the W3C ordered a change of HTML to something different, I just change the backend of the abstractions. The top level code stays the same.

    This is in contrast to most web-developers who re-invent the wheel so many times that most can write a login page blindfolded. It's completely backward. If people actually abstracted rather than just wrote yet another script to spit out text (which let's face it is what PHP is), the web would be a better place right now.

    And if people stopped thinking that everything is a string (you know, like Javascript has no types and PHP has no types and SQL is a string) then we'd probably not have quite so many XSS, code-inclusion/arbitrary-upload bugs or SQL-injections on the web causing customer details to get lost to hackers or companies to crash and burn in lawsuits.

    In the end of the day the market decides technology choices. Not dictators. Smiley

    Nah - at the end of the day, bad choices by developers mean that the market is still good for dictators. If people wrote fast, secure websites and apps, I'd be a poorer man Smiley But don't try and pretend to me like the web is fast or secure. It just isn't.

  • User profile image
    Bass

    If you don't want to do web development or participate in the advancement of the open web that's your choice. I personally enjoy it. And I'm happy to work with people who share similar passions with mine. Smiley

  • User profile image
    evildictait​or

    , Bass wrote

    If you don't want to do web development or participate in the advancement of the open web that's your choice. I personally enjoy it. And I'm happy to work with people who share similar passions with mine. Smiley

    Wow - an open web. That sounds almost as good as world peace and an end to world poverty.

    But be my guest. Your crappy code takes money away from your company and goes into my pension, so I don't really care.

    But you keep focusing on the "open web". After all, that's what really matters. Not the security of your users or their user-experience. They love their credit card details being in the open air as part of your "open web".

  • User profile image
    Bass

    , evildictait​or wrote

    Your crappy code takes money away from your company and goes into my pension, so I don't really care.

    De nada.

  • User profile image
    bondsbw

    Good discussion. I'm still hung up on the other part of my post:

    , bondsbw wrote

    Somewhere between HTML and native apps (like Windows 8 apps or Android/iPhone apps), there has to be something better.

    This isn't entirely a question of language.  It's a question of a thin-client application architecture that has the openness of the web.  (Sorry EvilDictator  Scared)  But here, I'm talking about a different openness, the kind that capitalizes on open content.

    This made the web great.  I couldn't imagine the Internet becoming what it is if we didn't have search engines and aggregators and hyperlinks.  Wait... I can.  It's the mobile apps we have today.

    App stores increase exposure of apps compared to desktop applications, but they don't come close to the openness of the web in general.

    I can't really create a link to another app like I can to a website.  Well, I can sort-of, but the user may not have the app and the link would fail.  Best case, the user needs to download it in its entirety (which could be huge if it represents a major portal which, as a website, would contain hundreds of pages).  This brings me over to the app store, where I click on the details to see what it is I'm downloading.  Then I find the button to install the app, and I click it and perhaps have to enter account details (like a password).  Finally, it's on its way to downloading, and minutes later, I have it on my computer.  Wait, what was I doing?  It didn't preserve the link, so I have to go back to the original app and... well, I'm bored by this point and go start watching Channel 9 videos.

    Apple might be quick to point out how many hundred thousand apps they provide on their store, but how does that compare with the many millions of web sites?

    The point is, I like the way the web works.  But mobile apps exist for a reason.  Otherwise, Apple's original idea of web-only apps would have flourished.  The mobile versions of websites have mostly been inadequate.  Mark Zuckerberg said that Facebook's biggest(!) mistake was coding their mobile app in HTML5.  Converting it to native made it 3 times faster, made it pull down less data, and now allows the company to focus resources on implementing new features instead of optimizing old ones.

    HTML is inadequate.  The evidence exists in substantial amounts.  Despite its many issues, HTML has been forced into the job of supplying the world's thin client applications.  But it doesn't fit the bill for mobile applications, so we need something else.  What I want is something else that works mostly the same, but without the issues of the HTML stack.

  • User profile image
    Bass

    @bondsbw:

    I think Apple was ahead of its time when it had web only apps. HTML5/CSS3 was more theory at the time. There wasn't any mobile JS libraries really. A lot has changed since.

  • User profile image
    bondsbw

    @Bass: Agreed, but it's obviously not enough.  Facebook still transitioned from HTML5 to native, and companies around the world are investing more and more in mobile apps.

  • User profile image
    magicalclick

    I am guessing there is some kind of parallax JS library running behind it? Except they didn't use a good parallax library that work with all major browsers. So, it is a big fail on them IMO. Because there are plenty of better parallax libraries out there and they failed to choose a good one, or they are dumb enough to build their own library that fails.

    http://smashinghub.com/7-jquery-parallax-and-scrolling-effect-plugins.htm

     

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    cheong

    , evildictait​or wrote

    *snip*

    And secondly, the whole point of development is abstraction. Instead of writing HTML, write wrapper classes that write the HTML for you. That way after a while you won't have to write HTML anymore. You just interact with the classes you've written.

    *snip*

    Agreed, "For the most time".

    The problem of abstraction is that, whenever the wrapper has bug, or being too helpful to add unwanted code that breaks your code (maybe interfering with another library you use), unless it's opensource, you'd have no way to fix it.

    And no, no web developer should ever allow to skip Javascript classes. Even the most fine-tuned sever-side library I know for now requires you to put javascript code here-and-there if you want to do anything beyond "basic" level. So the "You just interact with the classes you've written." part is questionable for web development.

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    exoteric

    I like it. It looks quite cool. It reminds me of infographic animated presentations like the Beast File:

    On the more modest side, Rob Pike has a nice presentation which interactively runs Go code (elsewhere):

  • User profile image
    fanbaby

    @exoteric: Rob Pike is one of my favorite tech personalities. Here's what Miguel de Icaza (who is currently holding the dotnet torch) have to say about him:

     Rob Pike's talk on Concurrency is not Parallelism. Rob is one of the crisper minds in software development, anything he writes, you must read, everything he says, you must listen to. (ref)

    About that concurrency slide deck, you know waht's more amazing? Watch this deck: http://talks.golang.org/2012/go-docs.slide , It gets really amazing after slide 20 or so. [spoiler: they created a text based slide language]

     

    One more thing: Rob Pike is one of the creators of the coolest new systems language, and he knows his way around HTML and friends.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.