Stories
Slash Boxes
Comments

SoylentNews is people

posted by CoolHand on Thursday February 11 2016, @10:47PM   Printer-friendly
from the code-on dept.

A link to an interesting article appeared in my e-mail box this morning with the following introduction:

I just watched an interesting discussion of Java and Node supporters on Youtube, that got my brain ticking. This article is an explosion of various ideas I have about Java, Node, JavaScript, and explicitly typed and weak typed languages.

I won't go into any more detail about the ideas that were produced as the result of the "explosion", but I'd be interested in reading about what others have to say. I will start the discussion with the following snippet from the article:

I don't remember the first release of Netscape browser with JavaScript, but I remember the reasons behind JS introduction:

  • Provide a simple scripting language "inspired by" Java to control embedded Java applets in web pages.
  • A simple scripting language to control forms.

Later, the public DOM representation of the page (partial initially), visible for JavaScript was introduced by Netscape, to provide some support of page changes driven by user actions beyond forms.

As you can see, the initial motivation was not to create a complete and powerful language to develop web client applications.

History is replete with examples of programming languages that have been bastardized and transmogrified into doing things they were never intended to do originally.

Enjoy!


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Thursday February 11 2016, @10:53PM

    by Anonymous Coward on Thursday February 11 2016, @10:53PM (#302997)

    Scala

    • (Score: 2) by Post-Nihilist on Thursday February 11 2016, @11:16PM

      by Post-Nihilist (5672) on Thursday February 11 2016, @11:16PM (#303005)

      or Groovy if you are not a Type lawyer

      --
      Be like us, be different, be a nihilist!!!
      • (Score: 2) by Marand on Friday February 12 2016, @12:34AM

        by Marand (1081) on Friday February 12 2016, @12:34AM (#303034) Journal

        (Or [Clojure] (if you (have a (parentheses (fetish)))))

      • (Score: 2) by Nerdfest on Friday February 12 2016, @02:53AM

        by Nerdfest (80) on Friday February 12 2016, @02:53AM (#303060)

        I've been using Groovy quite a lot lately. I tend to prefer typed languages so I generally use the @CompileStatic option. Best of both worlds really, little templating, dynamic typing where it's handy, Traits, cleaner syntax if you prefer, and full Java compatibility. There are also lots of libraries available, including one that flips collection based processing to fully parallel, generally with nothing more than adding an annotation. There are probably nicer languages out there, but the popularity of the JVM, Groovy's use in Android, Gradle, etc, make it a great choice.

      • (Score: 5, Insightful) by Francis on Friday February 12 2016, @04:35AM

        by Francis (5544) on Friday February 12 2016, @04:35AM (#303084)

        The attitude of some people towards types is downright bizarre. Types are something that you really need until and unless you're careful enough to no longer need them. This whole business of starting people out on untyped languages makes little sense to me as the types themselves represent a check to make sure the code is doing what you think it's doing.

        • (Score: 1, Interesting) by Anonymous Coward on Friday February 12 2016, @10:42AM

          by Anonymous Coward on Friday February 12 2016, @10:42AM (#303150)

          You're already at Score: 5 so I can't mod you up.

          One can pretend to ignore typing as long as you want, but it's a fool's paradise.

          Type mismatches are responsible for an entire class of bugs, yet people willfully ignore the very reasonable checks that are built-in to modern languages.

          They defer these added/perceived complexities in development to the debugging phase, to everyone's detriment.

        • (Score: 2) by SanityCheck on Friday February 12 2016, @02:43PM

          by SanityCheck (5190) on Friday February 12 2016, @02:43PM (#303213)

          Yes a type is a sort of built in assertion. Very useful indeed. What you will see now is the people who claim that strong type is useless doing assertions to make sure their variables hold certain values :/

  • (Score: -1, Offtopic) by Anonymous Coward on Thursday February 11 2016, @10:54PM

    by Anonymous Coward on Thursday February 11 2016, @10:54PM (#302998)

    A link to an interesting article appeared in my e-mail box this morning

    Lucky you! The only thing I get in my mailbox are offers to enhance my anatomy. Hm, yes, I have always wanted to use my dong as a billiards cue!

    • (Score: -1, Offtopic) by Anonymous Coward on Friday February 12 2016, @12:24AM

      by Anonymous Coward on Friday February 12 2016, @12:24AM (#303028)

      Then you'd better get cracking.

  • (Score: 4, Informative) by Gravis on Thursday February 11 2016, @11:09PM

    by Gravis (4596) on Thursday February 11 2016, @11:09PM (#303001)

    they both suck.

  • (Score: 5, Insightful) by Mr Big in the Pants on Friday February 12 2016, @12:15AM

    by Mr Big in the Pants (4956) on Friday February 12 2016, @12:15AM (#303022)

    The vast majority of modern scripting languages all seek to lay claim to simplicity and almost always have it as one of their prime motivators. They all attack standard languages for being not simple enough. They typically use specifically chosen (but functionally irrelevent) examples of their code versus something like Java and claim "success" because they are shorter, have more code shortcuts (AKA: syntactic sugar) and pretend to be unaware of things such as code completion, maintenance and readability as well as the importance of 3rd party libraries and a large support network.

    Many, if not all, end up being just a different flavour of "not simple" when you examine a fully fledged code base from a real application. e.g. the studies that showed Ruby was quick to get going but on large projects was no time saver than Java. (yes with grains of salt)

    The problem is that fully features languages are inherently complicated by nature. And for major projects, the ones that count, code maintenance, 3rd party libraries and preventing bugs (e.g. by strong typing) is FAAAR more important than slightly easier code creation.
    Yes there are better and worse ways to achieve this (e.g. C++ vs Java syntax) but cutting corners from the outset in the naive hope you can just sidestep complexity is...well naive.

    There are niche areas where a simple language is useful, but even these almost always tend to sprawl - a good example of this is: https://autohotkey.com/ [autohotkey.com]
    Started as a basic way to map keyboard commands with a "very simple" language...became an unintuitive monster just like all the others. e.g.

    • (Score: 2, Insightful) by MichaelDavidCrawford on Friday February 12 2016, @12:21AM

      by MichaelDavidCrawford (2339) Subscriber Badge <mdcrawford@gmail.com> on Friday February 12 2016, @12:21AM (#303026) Homepage Journal

      but then The Java Platform(TM) grew a library the size of the known Universe.

      I don't see the simplicity of a language being of much advantage if I have to learn a big library to get any real work done.

      --
      Yes I Have No Bananas. [gofundme.com]
      • (Score: 4, Insightful) by Mr Big in the Pants on Friday February 12 2016, @02:07AM

        by Mr Big in the Pants (4956) on Friday February 12 2016, @02:07AM (#303053)

        That was java being a platform, not just a language. There is a trade off between providing a stable base for all to use or having it provided with every download. They opted one way which some will not like.
        In people's rush to slam Java they forget how many platforms it runs on and why.

        And if you think you can and should write modern software without 3rd party libraries then you don't know what you are doing or are working on a dinky little program.

        And who is making you learn it? Ignoring it is no different to not having the library there aside from download which is negligible considering. For example, there is no need to learn the UI library if you are web only.

        • (Score: 2) by Common Joe on Friday February 12 2016, @05:25AM

          by Common Joe (33) <{common.joe.0101} {at} {gmail.com}> on Friday February 12 2016, @05:25AM (#303093) Journal

          And if you think you can and should write modern software without 3rd party libraries then you don't know what you are doing or are working on a dinky little program.

          This bothers me. I don't disagree with you. What you say just makes me squirm. 3rd party libraries sometimes stick around and sometimes don't. If you learn to lean on them and then suddenly it goes away, it can make life very difficult. There is a program I'd like to write, but part of it hinges on one guy writing one library. I'd hate to base my foundation on that, yet if I am going to write my program, I will have to use what he wrote. Yes, if he's hit by a truck tomorrow, the library will still be there, but will it still be functional in 6 months or in a year?

          • (Score: 2) by Mr Big in the Pants on Friday February 12 2016, @06:29AM

            by Mr Big in the Pants (4956) on Friday February 12 2016, @06:29AM (#303108)

            That is why picking the right library is more than just looking at a list of bullet point features. My time as an architect made me quite good at evaluating the longevity and support of a given package and we stuck to open source wherever we could. My first inherited project as lead architect had a million lines of java code and yet had many, many more contained in the plethora of 3rd party libraries we used. It would be insanity to suggest that we should just write all that ourselves because it would be "better".

            On the other hand, I have seen "roll your own cowboys" do more damage to projects than anything else. (the same project had many examples of this also!) They start by grossly underestimated the time to develop an alternative, overrate how much better their "amazing" (as yet undeveloped) solution will be and completely overestimate their ability to achieve said solution in a reasonable timeframe. I have picked up the pieces of this sort of thing (it is a cliche in the enterprise industry) many times.
            They tend to start by saying how "simple" they will make it and go from there...much like they do with all these "simple" scripting languages. Mostly it is just an unhealthy heap of pure arrogance.

            Going back to the Java example, the Spring framework was an excellent framework with an amazing and active community. You simply could not do better yourself no matter how much you overrated your own skills. If you attempted to do all that by yourself your project would never be complete and terrible.

            If you ARE able to do it all yourself, you project is tiny and feel free to do whatever you like. Everything is a tradeoff though and you have to always be aware of that.

    • (Score: 1, Funny) by Anonymous Coward on Friday February 12 2016, @02:54AM

      by Anonymous Coward on Friday February 12 2016, @02:54AM (#303061)

      a good example of this is: https://autohotkey.com/ [autohotkey.com]
      Started as a basic way to map keyboard commands with a "very simple" language...became an unintuitive monster just like all the others. e.g.

      Auto Hot Key's language (if you can even call it that) should be the poster child for how not to design a scripting language.

      It is awful, it has different ways of calling different functions (literally, different syntax depending upon the function). In fact, it looks like what one would get if four different, unrelated, drunks designed extensions, without first even bothering to look at what was done before their alcohol fueled stupor came about.

      • (Score: 2) by Mr Big in the Pants on Friday February 12 2016, @04:38AM

        by Mr Big in the Pants (4956) on Friday February 12 2016, @04:38AM (#303085)

        Yes, and the reason it is like that is because they started with the exceptionally naive goal of being "super simple" and targeted towards hotkeying specifically.

        So what did they do? They started with as many syntactic shortcuts as possible, removing as many pet peeves and personal vendettas as they could.

        Then came the job of solving all the typical stuff you want to do in a programming language.... aaaaannnnnd....that is where it got messy.

        Other languages have more subtle problems than this.

      • (Score: 3, Funny) by dmbasso on Friday February 12 2016, @05:00AM

        by dmbasso (3237) on Friday February 12 2016, @05:00AM (#303089)

        In fact, it looks like what one would get if four different, unrelated, drunks designed extensions, without first even bothering to look at what was done before their alcohol fueled stupor came about.

        In other words: Perl.

        --
        `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
        • (Score: 3, Insightful) by Vanderhoth on Friday February 12 2016, @12:53PM

          by Vanderhoth (61) on Friday February 12 2016, @12:53PM (#303167)

          Had to mod that funny. But I have seen some really elegant, readable and useful Perl scripts.

          For some languages, it comes down to is the developer. Just because a language will let you get away with something easily, doesn't mean you should do it. When I see people complain about how some languages are designed a lot of the time it boils down to, Yeah you can do that, but you shouldn't. And the unreadable buggy code is because the developer took short cuts. When I was young (15 years ago) I did it too, but having to maintain some of my own monstrosities for a few years helped me learn my lesson.

          Don't do things you describe as "cool" when you're young to make a program work. It's almost guaranteed it's a short cut and you won't understand it in 10 years when it starts acting up because of other updates to the application.

          --
          "Now we know", "And knowing is half the battle". -G.I. Joooooe
    • (Score: 0) by Anonymous Coward on Friday February 12 2016, @06:34AM

      by Anonymous Coward on Friday February 12 2016, @06:34AM (#303109)

      What's needed is a language that can be strong-typed and "strict" for the underlying API's and deeper guts, but also be scriptish when needed for gluing together the hardened components via short event handling snippets and glue-code. The top layers generally work better under scripting while the middle and bottom layers are best done with more "anal" languages, or an anal mode of a language. I've yet to see a language that can do both sides fairly well. I've kicked around drafts myself, and am yet to be satisfied, but feel it's probably doable.

    • (Score: 2) by tangomargarine on Friday February 12 2016, @02:54PM

      by tangomargarine (667) on Friday February 12 2016, @02:54PM (#303222)

      Yes there are better and worse ways to achieve this (e.g. C++ vs Java syntax) but cutting corners from the outset in the naive hope you can just sidestep complexity is...well naive.

      I'm getting a lot more familiar with C++ in depth since I started a unit testing job a couple months ago, and I have to say I'm gaining a whole new appreciation for how different Java and C++ are. The syntax is very similar, sure, but C++ has all kinds of crazy edge cases and fiddly bits.

      I'm still kind of a dumb recent college grad, but I get the impression that all these crazy language features in C++, while they allow you to do horrible, horrible, unsafe things, also allow you to do stuff in C++ that you probably can't even do in languages other than that (and C) and assembly.

      --
      "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
      • (Score: 0) by Anonymous Coward on Friday February 12 2016, @08:20PM

        by Anonymous Coward on Friday February 12 2016, @08:20PM (#303390)

        C++ has all sorts of complexity and "crazy" behavior mostly because it was originally just a thin "hack" atop C (so it had to remain 100% C compatible) -and- because it claimed to offer the absolute best performance with a motto of "you don't pay for what you don't use" which meant almost no language features to make life easier for the programmer could be adopted since they "added overhead."

        C++ served a purpose as a transitional language, the path of least resistance, to get the mass of programmers in industry to adopt object oriented programming.

        At this point, though, it survives mostly because almost nobody (few organizations of weight) have pushed a language to replace it in its domain. It's inertia that keeps it rocking along.

  • (Score: 5, Informative) by Marand on Friday February 12 2016, @12:26AM

    by Marand (1081) on Friday February 12 2016, @12:26AM (#303029) Journal

    First, unrelated to anything else, I'm amazed to find that he wrote "moar" instead of "more" in the article. No idea how that sort of mistake gets into a published article. Now, with that out of the way...

    Some of this guy's remarks about JS are way off. He's making all sorts of assumptions about intent that don't match up with remarks I've seen made by the creators themselves elsewhere.

    I don't remember the first release of Netscape browser with JavaScript, but I remember the reasons behind JS introduction:

    1. Provide a simple scripting language "inspired by" Java to control embedded Java applets in web pages.
    2. A simple scripting language to control forms.

    There was more to it than just "throw some shit together in a week and ship it", according to a story [brendaneich.com] by Brendan Eich about his joining Netscape and the origins of Javascript. Borrowing from a comment I made on a similar topic a couple weeks ago:

    "He claims that he was enticed to join Netscape by promises of creating Scheme in the browser. Netscape explicitly wanted something closer to the scripting language side of things, with the question of whether it could be a new or existing language undecided. Then someone up on high dictated that it must "look like Java", so instead of getting a mature language adapted for the browser, we ended up with Javascript."

    JavaScript is the result of lack of innovation. There is no "trascendental reason" or no "deep thinking" about how to make a good language good enough for a long future. For instance, the "prototype" feature was just a quick idea to create a mediocre object system, a mediocre version of Java and OOP

    This assertion seems contradictory to another remark from Eich, in the same link above, claiming that he was happy to have made Scheme-like [wikipedia.org] first-class functions and Self-like [wikipedia.org] important parts of the language. That doesn't sound like a "quick idea to create a mediocre object system", it sounds more like they wanted prototype inheritance instead of traditional classes.

    You may not like the decision -- and the author's tone indicates he clearly does not -- but that doesn't mean no thought went into it. The tone isn't surprising, though, considering the entire article's point seems to be "I have an axe to grind about node.js and I like Java." Not that I blame him, since I don't particularly like JS and think using it server-side is silly, but really, why make shit up when you have things like this [youtube.com] available? The entire article reads like a fluff piece about how awesome he thinks Java is. Sure, he tossed in a token negative-but-not-really where he says "but most people agree that [other stuff] is better", but that's not a real critique. Even when confronting a negative (Java's excessive verbosity and boilerplate) all he really says is "but it's a good thing!!!!"

    Instead of bitching about JS and talking up Java, maybe he should try a language [clojure.org] that targets [clojure.org] both* [clojure.org] and hides a lot of the annoyances of both. Especially since, at the end, he gives a half-assed assertion that Node.js is fine short-term because it's quicker to get started but is a poor long-term choice. If we assume this is correct (not that we should, given some of the other WTF remarks, but for the sake of argument) then Clojure should be a no-brainer. Start with ClojureScript on node, build something fast, and then switch to Clojure on the JVM -- which will share much of the same code -- if it becomes necessary, rather than planning for scale you may never need. Make it work, make it right, make it fast.

    TL;DR: Article was a waste of time and I probably should have done something more productive than reading it and then commenting on it. The author just wanted to proclaim his love for Java for the world to see. Not really a surprise when his author profile on that site is this:

    I'm the father of ItsNat AJAX Java web and ItsNat Droid Android frameworks, RelProxy hot Java/Groovy class reloader and Java scripting, JNIEasy, LAMEOnJ, JEPLayer and JEPLDroid libraries (and very old stuff like XPDOM), supporter of the Single Page Interface (SPI) paradigm, writer of the SPI manifesto and currently Android native guy.

    Bias much?

    * and the CLR [clojure.org] if you're into that sort of thing.

    • (Score: 2) by Marand on Friday February 12 2016, @12:29AM

      by Marand (1081) on Friday February 12 2016, @12:29AM (#303031) Journal

      Correction: above it should have said "he was happy to have made Scheme-like first-class functions and Self-like prototypes important parts of the language."

      Bolded word was unintentionally left out. I missed that in the preview, sorry.

    • (Score: 3, Interesting) by tibman on Friday February 12 2016, @02:59AM

      by tibman (134) Subscriber Badge on Friday February 12 2016, @02:59AM (#303063)

      For instance, the "prototype" feature was just a quick idea to create a mediocre object system

      His comment on prototype tells me he hasn't even used it.
      Given:

      typeof({}) == 'object'
      typeof(function(){}) == 'function'

      So let's look at the prototype of each:

      {}.prototype == undefined
      (function(){}).prototype == 'object'

      Then objects don't have prototypes :P But functions do!

      --
      SN won't survive on lurkers alone. Write comments.
    • (Score: 0) by Anonymous Coward on Friday February 12 2016, @07:31AM

      by Anonymous Coward on Friday February 12 2016, @07:31AM (#303122)

      "JavaScript is the result of lack of innovation."

      I have studied a lot of languages and JavaScript is the more innovative in my mind even if you compare it to all the news langages that try to be new by replacing "var" by def, val, let or whatever you want, and "function" by fn, fun, func, etc...

      • (Score: 0) by Anonymous Coward on Friday February 12 2016, @08:29PM

        by Anonymous Coward on Friday February 12 2016, @08:29PM (#303395)

        I agree that Javascript *is* innovative. While it may not have *invented* prototype inheritance, it certainly brought it to the masses.
        Having had years of experience to judge prototype inheritance, most programmers have declared it a failure.

  • (Score: 2, Interesting) by Anonymous Coward on Friday February 12 2016, @12:33AM

    by Anonymous Coward on Friday February 12 2016, @12:33AM (#303033)

    No matter how these types of articles - and attitudes - try, they can't really make programming easy because it isn't easy.

    As a program becomes more complex we end up using more complex approaches to address the needs of the application and the problems it is supposed to solve. Can a language make a difference? Sure it can, but so can a methodology, or a library, or a series of design decisions.

    It's never going to be quick or easy or cheap to create reliable, stable, useful and complex software.

    • (Score: 3, Informative) by bzipitidoo on Friday February 12 2016, @04:22AM

      by bzipitidoo (4388) on Friday February 12 2016, @04:22AM (#303082) Journal

      The article is flamebait in the Programming Language Wars, as well as psuedo-erudition (fake geekery) about programming language features, a popular past time since the days of OOP being touted as the successor to Structured Programming, and it turning out not to be so simple. Whenever someone starts throwing around "weak typing" vs "strong typing", the terminology is about to get thick. What exactly are these properties? People bandy those terms too freely and often, not appreciating that they are poorly defined, and old and no longer much applicable. Much better to talk about type safety than strong typing. Really, C is the canonical example of a weakly typed language. There was an unstated thought that this might be an unavoidable tradeoff, that either a language could be flexible and weak and unsafe, or inflexible and strong and safe. C's weak typing is recognized as a shortcoming, and every language since has tried to thread this problem by allowing the same or more flexibility as C allows, but with more safety. Does that make these languages strongly or weakly typed? Both, in a way. There is no dilemma; language designers have found ways to be both flexible and safe. What then were the strongly typed languages? One was another popular language of the 70s and 80s, Pascal.

      Structuring a program is relatively easy. Employing OOP is more challenging. There are many people who can cobble together simple scripts but who cannot employ OOP because they don't really get it, nor do they need it. They fear recursion, fear that it is too hard to understand. Even Structured Programming can be too much for some. I've seen code that was created by using the power of a decent editor to repeat a few lines of code hundreds of times, and not because they were trying to optimize by doing loop unrolling by hand, no, it was all because the programmer wasn't comfortable with the concept of a loop. Such programmers are completely bamboozled by advanced concepts in programming languages, such as currying, lazy vs eager evaluation, the idea of treating a function as something that can be a parameter, same as any other data. Even competent programmers can have trouble grasping these ideas, as they are often not well explained or demonstrated.

    • (Score: 0) by Anonymous Coward on Friday February 12 2016, @09:03AM

      by Anonymous Coward on Friday February 12 2016, @09:03AM (#303133)

      Like Socrates teaches (ha!) us, it is very very hard to determine or specify anything with good enough clarity and precision. No matter how much we pamper it with syntax and rules and how much we hide specifics of underlaying program execution infrastructure and environment, this problem can't go away.

      • (Score: 0) by Anonymous Coward on Friday February 12 2016, @09:05AM

        by Anonymous Coward on Friday February 12 2016, @09:05AM (#303136)

        Socrates ... in the end they actually did gave him free meals for life ...

  • (Score: 3, Funny) by Anonymous Coward on Friday February 12 2016, @02:54AM

    by Anonymous Coward on Friday February 12 2016, @02:54AM (#303062)

    (original source) [theregister.co.uk]

    Language: Erlang

    • Pros: The original practical FP language that has really been put through its paces in the field. By reputation so robust you can change boards in the machine on which an Erlang program is running with no deleterious effect. Or switch the whole thing off, and drop it in a bucket of ice water.
    • Cons: Syntax is incomprehensible gibberish.

    Language: Haskell

    • Pros: A shining, elegant-as-a-snowflake, expressive-as-Dame-Maggie-Smith language of immense power and no dirty compromises. Pure. Hugely influential. Its very functional farts smell of fresh strawberries.
    • Cons: Primarily a CV decoration language. Code is typically written to be admired rather than compiled; this is technically known as the "lazy execution model."Besides, you won't understand it.

    Language: Scala

    • Pros: Close relationship with Java, and underlying JVM implementation, means it offers all the features of that platform.
    • Cons: Close relationship with Java, and underlying JVM implementation, means it offers all the features of that platform.

    Language: F#

    • Pros: A Microsoft .NET language with roots in ML.
    • Cons: Redundant to write anything here, because you have already made up your mind. Haven't you?

    Language: Clojure

    • Pros: JVM platform with ports to .NET and JavaScript.
    • Cons: It's just LISP in functional clothing, for heaven's sake. This, in the Year of Our Ford Quarter Past Eight. Will those pesky Lispers never desist? Mark my words: next stop, FUNCOBOL

    Language: JavaScript

    • Pros: It's what you'll end up using.
    • Cons: The most dysfunctional functional language. On top of all its well-known flaws that disrupt ordinary primitive programming, it lacks many allegedly must-have functional gewgaws. Its variables are mutable, its type holes are indubitable, its 'eagerness' unsuitable, its modules are inscrutable, tail recursion disputable, scoping inexcusable, and I'll stop there, with 'refutable' (to name but one) still in the bank, just because you were kind enough to beg me.
  • (Score: 3, Interesting) by darkfeline on Friday February 12 2016, @04:01AM

    by darkfeline (1030) on Friday February 12 2016, @04:01AM (#303079) Homepage

    No one seems to be interested in talking about what the poster intended?

    >History is replete with examples of programming languages that have been bastardized and transmogrified into doing things they were never intended to do originally.

    For the most part, things end up worse for it. No matter how skilled you have gotten, using hammers to drive screws doesn't work as well as a screwdriver. Web applications are for the most part big hacks piled onto other big hacks. You can have "web" applications, but they shouldn't be driven with a WEB BROWSEr. Web browsers are for browsing the world wide web, not for accessing applications via web protocols.

    Imagine an intuitive HTTP client used to drive RESTful HTTP APIs. All you need to do is set up a de facto standard for driving the client, and you have a full featured, portable, locally run front end to the API: a "web application".

    High level example: I write a client called RESTful Driver. It can automatically connect to a URI hosting a RESTful API. It uses a de facto standard to pull a specification file, essentially containing code for the driver to run to act as a frontend and hook up to the API. Of course you would have to be careful whether to trust random Internet code to run, but it's the same with JavaScript now.

    One immediate advantage is that you don't have to rely on HTML to build a fucking application. No hacks needed for mouse movement, keyboard input, UI events, etc. No need to load 10 MB of JavaScript to hack a pretty parallax animation into fucking markup language.

    --
    Join the SDF Public Access UNIX System today!
    • (Score: 2) by Common Joe on Friday February 12 2016, @05:42AM

      by Common Joe (33) <{common.joe.0101} {at} {gmail.com}> on Friday February 12 2016, @05:42AM (#303098) Journal

      Fully agree and spot on. I think the only way to untangle the World Wide Mess is to come up with something different from HTML / CSS / Javascript. As an IT society, we have the knowledge and experience to design something better that replaces the web browser. It would effectively toss everything out the window and be extremely painful in the short term, but it would be worth it in the long term.

      Of course, it would have to not be made by a committee. The whole process to get HTML5 going was insane. The best way to do it is get a grass roots thing going. (Unfortunately, I do not have the time, money, nor expertise to do so.)

    • (Score: 3, Informative) by gnuman on Friday February 12 2016, @06:37AM

      by gnuman (5013) on Friday February 12 2016, @06:37AM (#303110)

      You can have "web" applications, but they shouldn't be driven with a WEB BROWSEr. Web browsers are for browsing the world wide web, not for accessing applications via web protocols.

      Welcome to software development. You must be new here.

      All successful software ends up with feature creep. There is no way around it unless you want to kill your own product. Web browsers ended up with lots of extra stuff than simply rendering HTML because this new stuff is useful to someone. But these are not all bad decisions either. You have CSS, which decouples style from old HTML. You have JS, which gives views functionality. Then more interactive protocols were added to work around broken old ones. Now we are finally at a cusp of replacing old HTTP with HTTP/2.

      Your idea of "throw the baby out with the bathwater" is not a new idea and it's a bad idea. The worse thing you can do now is start to re-engineer the web browser. You'll end up with a browser that is completely useless, bloated and no one will use it.

      So yes, maybe not everything "belongs" in the original web browser, but that's not what we have anymore. We have a very powerful VIEW tool in the MVC system that is the internet applications. Browser is just a legacy word, like the original hacker.

      • (Score: 0) by Anonymous Coward on Friday February 12 2016, @06:45AM

        by Anonymous Coward on Friday February 12 2016, @06:45AM (#303112)

        I agree. The web stack has turned into a monster. Time for a better GUI standard. For example, let the server control resizing and auto-flow and send only absolute coordinates to the client. That will greatly simplify and standardize the client. 2 diff brands won't "flow" differently. I really hate that in current browsers.

        • (Score: 0) by Anonymous Coward on Friday February 12 2016, @08:57AM

          by Anonymous Coward on Friday February 12 2016, @08:57AM (#303132)

          Remember websites "optimized" for 640x480 screens? That's your server-side rendering. Fuck that shit with a red hot poker. Along with mentality of "it has to look the same everywhere". No, it just has to be usable everywhere. I, the user, should be in control. If your design bothers me enough, i just might use some layout ideas from csszengarden and figure out how to apply it to your monkeyface design through greasemonkey.
          equally, would love to pepper spray say the USA Today webgeeks. Their floating ui stuff just sucks ass when using a smartphone to view their stories via Google News. But also equally bad are so-called mobile optimized" websites.(m.slashdot.org, beta.slashdot.org anyone?)