Hacker News Reader

Comment by acemarke | Hacker News Reader

Your comment seems to be a bit of a non-sequitur.

Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser.

Would you prefer to build your application using Make, Scons, Waf, CMake, QMake, Tup, Bash scripts, Maven, Gradle, Ant, Buck, or something else? The build tool question is _totally_ solved, right? :)

Yes, the JS community has been reinventing a number of wheels. Yes, the browser environment and JS standard lib have weaknesses. On the other hand, it's also allowed developers to build useful applications that are immediately distributable to pretty much anyone who has an internet connection.

View on HN

The benefits you acknowledge (distribution) are not because of the tech but in spite of it.

At the end of the day all it would take is one of the 3 major browser vendors to offer an alternative. That alternative could be distributed to a large percentage of desktops in a relatively quick manner saving billions if not trillions of dollars in wasted productivity.

It will never happen though.

* EDIT: This comes from someone who uses React, Redux, webpack, etc.. daily

No-one could even agree on making HTML5 valid XML - in order to leverage all the tools and knowledge that exist in that space.

Not that I even like XML. But having another XML dialect that's not actual XML shows that the only hope is to build valid tools and abstractions on top of all the crud.

There's nothing "not actual XMLish" about HTML. HTML is formally describable in its entirety using SGML (see my project at http://sgmljs.net/blog/blog1701.html), just not by the XML fragment of SGML.

Is it possible to scrape random html5 pages off of the internet and transform them with xslt 2?

Or write content/metadata schemas (distinct from a DTD schema that simply describes html5) using XSD?

Unlike xhtml, my understanding, was that the current tooling around XML won't just work out-of-the-box for html5.

You're missing the point. HTML wasn't XML because XML didn't exist then. SGML did. XML is a "an SGML dialect that's not actual SGML," not the other way around. The people who designed XML knew the SGML spec, as they wrote XML as a subset of it, and they knew what was in HTML. They could have written XML so that HTML conformed. They chose not to. But the HTML spec at the time was absolutely conformant SGML.

What cwyers said. Plus, XML was designed to replace HTML as XHTML, but it didn't happen. Doesn't mean you need to give up markup processing alltogether. Just use full SGML, which has additional features such as tag omission/inference and other markup minimization features for text authoring not in the XML profile of full SGML such as markdown and custom Wiki syntax support. You might actually like it.

You can parse HTML 5 into XML using my HTML 5 DTD [1] and eg. OpenSP's osx tool or my upcoming sgmljs.net tool.

What do you have against DTDs? They do the same as XSD, and then some.

[1]: http://sgmljs.net/docs/html5.html

> But having another XML dialect that's not actual XML…

HTML is based on SGML, it was never an XML dialect.

>"At the end of the day all it would take is one of the 3 major browser vendors to offer an alternative."

You mean like Dart?

Besides, languages that target WebAssembly are almost certainly going to evolve to fit that space.

I have serious doubts that WebAssembly is really going to come to dominate the web the way many people here seem to believe it will.

The idea that all of sudden there is going to be a rush to push compiled/closed sites after so many very successful years of using free-and-open stacks seems rather non-logical to me.

Time will tell.

The success of the JavaScript stack was not dependent on source being shipped to the browser, and the push for WebAssembly is not motivated by keeping source away from the browser.

What? It absolutely was. Whole generations of today's JS people trained themselves with View Source.

....decompiling minified Javascript?

Sorry, this ship has sailed.

That was before minification. I think that ship already sailed.

> The idea that all of sudden there is going to be a rush to push compiled/closed sites after so many very successful years of using free-and-open stacks seems rather non-logical to me.

Well, then we have minified JS that isn't exactly readable. Similarly with multiple-compiled JSX-to-ES6-to-ES5/JS code.

Also, there's a number of JS obfuscators, whose main purpose is to smuggle a piece of closed code into those theoretically “free-and-open” stacks.

Thus, I think, after wasm becomes generally supported, there will be more incentive to write code in your language of choice and compile it to a common platform, than to write code in JS or one of its derivatives and minify/compile it anyway.

I see your point. But I'm more optimistic. We devs like to jump on hype trains. We only need one good reason to do so.

>"compiled/closed sites"

It's worth noting WebAssembly isn't compiled into a form only computers can understand. There are plans to offer 'View Source'-style functionality for WebAssembly. WASM is a compressed AST rather than hardware-specific bytecode.

> Besides, languages that target WebAssembly are almost certainly going to evolve to fit that space.

And are already but now targeting JS. Like PureScript, ReasonML, Elm and even TypeScipt to some extend.

If this is such a good and valuable idea, why will it never happen? Seems the major internet-interface makers (Google via Chrome, FB via their app, for ex), are vying for control over the way people develop web applications too. Making an alternative that gets adopted would be invaluable to them.

It won't happen because none of them will implement the other guy's new thing. Chrome would do the Google thing, Edge would do the Microsoft thing, and Firefox would sit back and balk that none of that junk is standardized. Then webdevs would just stick with Javascript and friends because it's the only thing that mostly works everywhere. That's exactly what happened to Dart, right? It had aspirations of hopping into Chrome along side JS but who else was going to put it in their browser? Now it's just another thing that compiles to Javascript because that's the only way you'd get anybody to adopt it.

You could also see it the other way around. That we've come pretty far with standardization based on JavaScript and HTML5 (and CSS and SQL and POSIX and IP ...). What do you expect exactly?

Mozilla is probably in the best position to do something. If it's good enough to get developers to switch and rave about it, ms and google will follow to keep mindshare.

JavaScript was invented by Netscape, the predecessor of Mozilla. Also Firefox came out in a phase of browser stagnation, but Chrome in particular and the other browsers are so powerful today that I'm more worried we're going to loose web standards to "whatever WebKit does". So I wouln't hold my breath.

Not true, see webassembly.

The parent and grandparent were talking about unilaterally developed tech, "At the end of the day all it would take is one of the 3 major browser vendors to offer an alternative." etc

The correct comparison there is Dart. WebAssembly is a joint effort being developed by a team comprised of folks from every major browser vendor, so it isn't really an example of what they're talking about.

That already happened and is called webassembly. And it is backed by not one, but all of the major browsers.

Dart is shipped with chrome, or not? I don't see any huge success :)

Not anymore:

https://www.chromestatus.com/feature/6682831673622528

> Would you prefer to build your application using Make, Scons, Waf, CMake, QMake, Tup, Bash scripts, Maven, Gradle, Ant, Buck, or something else? The build tool question is _totally_ solved, right? :)

Yes.

I've worked with CMake, Gradle, Maven, Ant, with webpack, makefiles, and the entire rest. And you know what? I went back to ES5, just because it's easier than fighting the JS environment. Comparing your average build.gradle with a webpack config is downright insane.

Why does the web environment have to be so much more complicated than the native world? The web could be so much more powerful if they'd study history, and learn from it.

With what webpack config though?

Half the problem with the web stack is inexperienced people making things way more complicated than they need to be. A minimal webpack.config is pretty damn simple.

> Qt is big and complicated.

I'd encourage every developer considering Electron to give Qt/QML a try. It merges the declarative nature of WPF with a nicer syntax and the ability to use JS directly in the QML file, obliterating the need for converters of formatters (that plague XAML/WPF and JavaFX). Writing custom components is trivial and intuitive, with zero syntactic overhead (if a QML file "MyCompX" is present, you can instantiate its contents with "MyCompX" without any additional setup).

For Android, it has the advantage of being able to hot-reload the UI without jumping through hoops (simply serve them over HTTP and install a small reload handler in your app that can be triggered either from the app of by something like a UDP message from the host). (Change one like in the app's main and you are able to pull the QML files from a local directory so you can modify them on the tablet without a PC or internet connection ...)

I'm actually reluctant to mention Qt/QML because I consider it to be my secret magic silver bullet for portable (non-web) UI development.

Regarding the license (there's a lot of misinformation, including Qt's main site trying to coerce you into using the commercial license): if you link dynamically, commercial usage is not a problem (LGPL). (This is usually only an issue on iOS.)

The recent Electron situation (needed on one hand, loathed on the other hand) is a unique opportunity for Qt to gain (back) some developer mind share, but to avoid alienating web developers with scary C++ stuff it would help to decouple QtCreator from the Qt C++ API: offering a version that only exposes the QML editor and interface generator, and ships qmlscene as execution runtime and an option to deploy the QML-only application with a rebranded qmlscene (embedding the QML resources and a custom icon). To be clear: this all exists right now, but with the C++ part enabled (which will scare off some developers even if they can create applications without it).

>The recent Electron situation (needed on one hand, loathed on the other hand) is a unique opportunity for Qt to gain (back) some developer mind share, but to avoid alienating web developers with scary C++ stuff it would help to decouple QtCreator from the Qt C++ API

For me it's exactly the other way around. If I'm using Qt it's because I want to use C++ to make my app as efficient as possible in terms of CPU and memory usage. Now that JavaScript is in the picture, I'm less likely to consider Qt for a cross platform app because I can just as well use any of the other more popular options like Electron or ReactNative.

Qt used to be a C++ GUI framework. Rebranding it as something else won't work. They won't get the web crowd and they will alienate people who want to avoid web technology.

> Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser.

Actually, Java, C++,QT and co are going through great length to make development simpler and all the compilation pipelines easier. Let's take Java for instance, groovy, maven and war packaging considerably made Java server development easier. Java frameworks like Spring are trying very hard to make servlet development easier, by making complexity opt-in. Java is getting constructs like modules which will help with library development, C++ too, QT is streamlining its API ... So I'd totally disagree about your statement. The success of Go yet another proof of this. People are tired with unnecessary complexity and are ready to give up on "elegance" for the sake of simplicity.

And the Javascript world has gotten a defined syntax for modules, package managers, and build tools that implement build pipelines, compilation, and linking. Same concepts, new language and environment.

My point is that building complex software inherently involves _some_ amount of complexity on the development side, which is reflected in the language syntax and tooling used with that language. Now that people are building complex apps in Javascript, we're seeing catch-up in the tools used to build Javascript apps to match the tools that have existed for years on the desktop/native side.

I don't know about Java frameworks and build tools really making things easier. They just shift problems around so that instead of having to deal with the Servlet API (say) you have to deal with Spring idiosyncrasies, IDE integration troubles, cognitive overload by too much tooling, and endless discussions about the "right" way to use a particular frameworks or design pattern. Saying this from 20 years of Java experience.

The word Java and "simple development" is just absurd for any real application much less most enterprise applications.

Is it that absurd?

Building Java applications using Undertow with a build setup in gradle is not _that_ different from a node.js service using Express and package.json for dependencies, or a Ruby, Sinatra and Rake stack. After having tried all three, I ended up going back to the JVM. It's not a perfect ecosystem, but it's damned good one.

If you're on gradle you're already pretty cutting edge compared to most enterprise java setups. Probably most projects are still using maven.

Also there's definitely been some cross pollination of ideas from at least the Ruby world to the Java (Rails inspiring Grails and probably Play too), so it's getting better. Add java8 lambdas, and it's quite nice.

> Probably most projects are still using maven.

Aren't you optimistic.

Maven's pretty big still.

https://github.com/search?l=Maven+POM&q=pom.xml&type=Code&ut...

https://github.com/search?l=Gradle&q=build.gradle&type=Code&...

And that's public github, which is supposed to be more cutting edge than the legacy code that powers most companies. I started a project with gradle on my last team and everyone complained because they had never used it before.

Yeah, I would love me some maven...

just got rid of a project using a 10 year old custom patched ant.

Rust, PHP had simple af builds/packaging. So no, not everything is complex, just old dinosaurs AND web.

I would never want to use php's "just recompile it with the new dependencies" approach ever again. It's a complete mess as soon as you go off the rails of what's included by default.

I will never believe people recompile PHP binaries every day.

PHP's packaging was only "simple af" until you had a binary dependency that wasn't part of your operating system.

Complicated things exist.

But now you're hitting on one of the main points that was always criticized in PHP: the fact that it came with a lot of batteries included. The upside of this is that it makes PHP applications very easy to deploy, because often, you either don't need to resort to binary dependencies outside the realms of your OS's packaging system, or there will be a `php[major-version]-[library_binding]` package for your OS probably already in your OS's official package mirrors. Say all you want about PHP, but of all the application stacks I've had to deploy, PHP was and is probably still the simplest. The advantage of that shouldn't be underestimated. The only serious competitor in that space that I've ever touched is probably Go.

Yeah, you can recompile PHP 2-3 times per year, and it's just long line of args, nothing more. And you can compare it with every-time compilation of modern js apps. What an equation! And you forgot to mention Rust, but let's pretend it's normal way of arguing.

Doesn't composer do that? Ie. https://packagist.org/packages/anam/phantomjs-linux-x86-bina...

The most disappointing part of all of this is that in the JS environment no build step is required, but it is often there anyways...

What do you mean? Are you referring to gulp and other similar tools?

I am referring to any build step. Do you need a build step to execute JS?

Reply on news.ycombinator.com