Hacker News Reader

Comment by niftich | Hacker News Reader

The salient points of the article:

- People are stuffing websites into Electron and packaging it as a native application

- HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience

Although the article doesn't say it, this seems to imply that:

- Full-native development unique on each platform is considered too much effort, when you can get a cross-platform app with Electron

- Other platforms are not very 'hackable'; why is this?

Is this purely because JS has a higher mindshare and marketshare than [preferred platform language] on [preferred platform toolkit] on [preferred platform], or do HTML/CSS/JS applications actually tend to hit a sweet spot in terms of separation of presentation, view logic, business logic? Or is it about the view-understand-edit-deploy lifecycle being easier with HTML/JS apps?

View on HN

All of the above. If your application can be designed as a web application, you can use responsive designs and progressive enhancement techniques to create an experience that works across any platform with a web browser - with one code base. This is a pretty amazing thing, and for various business-related reasons this may seem like the right move.

This whole thing just stinks of forcing the browser to be a (terrible, poorly functioning, and inconsistent) abstraction over the OS. The browser/webapp model of application development is just awful.

I don't think anyone would argue that web development is perfect. What is? But, thanks to the ubiquity of the web browser, it is the only way to create a common user interface across any platform. Given that context I am grateful to have it.

Common user interface across any browser (platform) that supports it, you mean. Like any other language.

The only progressive enhancement today's generation of web developers is capable of is showing a blank page if JS is turned off. Stop lying to yourselves that you care about usability or accessibility.

> HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience

I think that's related to the high fault-tolerance in Javascript. A good developer is good in any language, so she can work with Javascript. A beginner or even a bad developer can make things happen in Javascript, when that is not always possible in other languages. So the entry point level is so low that a lot of people is using it.

> Other platforms are not very 'hackable'; why is this?

I prefer strong typed languages. I use TypeScript when I have to do some JS work as it is easier to maintain in the long term. But that means that you need to know what you are doing before starting to do anything. Compile, fix errors, repeat.

I can see that for starters JS is more fun and "hackable", as it was BASIC for me when I started.

>> > HTML/CSS/JS is considered 'hackable' because it's widely understood by today's semi-power-user audience

> I think that's related to the high fault-tolerance in Javascript.

Also, in Electron apps you can access the Chromium Dev Tools directly in the app (unless the app author has disabled it). Chromium's Dev Tools are pretty much the gold-standard for hacking during runtime.

> Chromium's Dev Tools are pretty much the gold-standard for hacking during runtime

... if you don't include any IDE with a built-in debugger.

Chromium dev tools essentially IS an IDE with a built-in debugger. You can set breakpoints, step over/into/out of code, monitor network requests, view/edit the DOM tree, edit CSS in real time... For some code, you can even edit it while it's executing. Plus it exposes a REPL at window scope.

SmallTalk and Lisp would have something to say about that.

I can assure you that a bad developer can make things happen in any language. And it will look and behave like shit in all of them. There is no language that makes a developer write good code by magic.

There are languages where non-developers can make SOMETHING happen (like make the monkey dance[1]). There are languages where non-programmers can't -- you have to be SOME kind of programmer, good or bad, to make C do something other than look at you unkindly.

1) http://programmers.stackexchange.com/questions/221615/why-do...

I think it's the mixture of both. Editing something, pressing f5 and watching new changes getting into your webpage is really great, and a form of instant gratification. This workflow will always be better than for example restarting jetty web server to reload some servlet... Also when you have everything packaged inside you don't worry about runtime libraries. That's another headache in native app deployments. And the third is great ecosystem of libraries, editors, tutorials, snippets, etc. Low entry barrier makes it easy to quickly adopt.

What makes JS more "hackable"? Someone find that cartoon about the gaunt-looking guy and the laid-back kid when the girl asks them to hold her coffee and link it [edit: http://i.imgur.com/76Wtthy.jpg ].

...Because it gets the hell out of they way and holds your coffee for you and doesn't slap it out of your hand and throw a tantrum because it was actually a medium coffee...and it gives you the simplest no-BS object/array literals you can get...IMO opinion everyone wailing and beating their chest bemoaning the fact that JS got where it is fails to understand that it got there because it the "UX" of coding JS is just a lot more pleasant - and you can treat it as a compile target and do your work in a more type-obsessed thing like Typescript if that's your cup of tea without imposing on the underlying "hackability" of the language.

Typescript is sufficiently close to JavaScript that it doesn't really feel like it's treating JS as some invisibly underlying assembly-like layer.

In practice, you can use as much or as little typing as you want, and the compiler will occasionally tell you "I think you're doing something dangerous here", but even then you're only one <any> away from ignoring its generally good advice (or more sanely, you would annotate the ambiguous bits a bit better so typescript understands you really meant to do that.)

But otherwise, all the usual js hacks still very much apply.

Anyway, that's why typescript is my cup of tea|coffee.

Hmm not convinced.

Is it pleasant UX that you can put petrol in your diesel car because the nozzle fits? Would it be pleasant UX to have your bank let someone withdraw money from your account without ID? Bleach bottle with no safety cap?

Also the laid back kid of JS will throw a tantrum if the coffee is not a coffee. He'll throw the tantrum at your customer though (at runtime), not your developer (at compiler time). Which arguably is a good UX for coding but not the bottom line.

Considering the variety of fuel sources a diesel engine can use (oil, deisel, etc), I'd say it is pretty useful... ;-)

Yeah, and good luck dealing with that remote API that now gives you an extra field in the JSON or XML, and your compiled client in a few thousand workstations needs to be updated and redeployed because of said fit.

> Yeah, and good luck dealing with that remote API that now gives you an extra field in the JSON or XML

Java C# and every other decent typed language has good serialization and deserialization support. The extra field poses no problem.

I've had to consume Java generated wsdl in C#, having response types of "Object" from the Java side, meaning the .Net side has no properties on the responses from those methods, I'd have to disagree...

Nothing to do with static vs dynamic typing. Just get Java and C# to talk in another protocol. How about JSON or vanilla XML

It would be pleasant if your engine didn't care whether you put gas or diesel in it and just ran. I think that's the point made in the cartoon.

I like that the kid just holds the cup and pours it when I tell him to. If I wanted him to pour coffee and gave him a cup of beer, I'm ok saying that's my fault. I'd still rather have the kid. Having a guy that only accepts "Large cups of coffee" is necessary at lower levels (c), but keep it out of my scripting language.

In this analogy I'd say the engine cares in both JS and Java.

In Java you get an annoying compiler error.

In JS you get a trashed engine at runtime.

To continue the analogy what happens when you accidentally pass him a cup of bleach?

> it gives you the simplest no-BS object/array literals you can get

I really don't think that:

    {
      "foo": "bar",
      "baz": ["quux", 1, true]
    }

is simpler than:

    ((foo bar)
     (baz (quux 1 true)))

Quite the opposite, really.

That does look nice. Is that, LISP? To my eye, they look roughly equivalent, though - and a lot of what I consider the "No-BS object system" occurs after the literal is declared - adding and manipulating properties, etc.

> Is that, LISP?

Well, S-expressions, which can be used for Lisp code, but can also just be used for plain data.

> a lot of what I consider the "No-BS object system" occurs after the literal is declared - adding and manipulating properties, etc.

Yeah, it's definitely convenient to use, even more so than Python's objects. I prefer a stronger type system for my own software though.

Question: Can s-expression list-of-lists really be used to represent an unordered map when it comes to operations like equality? Or rather, does one simply use expectations/context to compare this object to, say

  [["foo", "bar"], ["baz", ["quuz", 1, true]]]

making it a non-issue?

> Question: Can s-expression list-of-lists really be used to represent an unordered map when it comes to operations like equality?

With the right predicates, anything is possible grin

I think that context unavoidable: one can't just read a JSON value into a generic data structure, or even into a typed structure: one has to apply the types of one's business logic (e.g. 'user-id' must not only be a string, but a string beginning with either 'E' or 'C'). In that context (pun intended), then it makes sense for equality comparisons to be at the business-object layer, not at the freshly-deserialised JSON object layer.

The bottom is definitely ambiguous.

What's ambiguous? If you don't like that it's using a list to represent a map, you could always use:

    (map (foo bar)
     (baz (quux 1 true)))

But you might reflect on the fact that JSON uses an ordered sequence of bytes to represent an unordered collection of properties and values.

Yeah I find the "hackability" question really interesting. It is incredibly neat that I can hit a few keys in a browser and get an editable live source of what I'm looking at which is, to some extent, declarative and easily mappable from source to output. Yes, this is less true as more sites rely heavily on minified javascript for all of their implementation, or incomprehensible (to me) css that hides or moves things around in non-obvious ways, but it still mostly works. I definitely can't think of any commonly used native apps that are so easy to inspect and edit! Interestingly, though, I think you lose all that with something like Electron. At least, I don't know how to do that in eg. the native Slack client.

ALT -> View -> Developer -> Toggle Developer Tools

Just saw this. That's really cool, I had no idea that was there!

> "Full-native development unique on each platform is considered too much effort, when you can get a cross-platform app with Electron"

Yes, it's this. Full native development is awful since every platform is completely different, and other cross-platform solutions like Qt are a bit behind the web in terms of modern look and feel and developer base.

But Electron is also awful, since a hello world app uses 100mb of RAM.

Desktop GUI app development is horrible... meaning it's slightly worse than mobile GUI app development. GUI development in general is a horrid ghetto where your choice is between bad and completely proprietary.

"But Electron is also awful, since a hello world app uses 100mb of RAM."

Is it that awful, though? Most computers come with 4-16GB of RAM.

Yes, that is not just terrible it is embarrassing.

8-bit 4mhz CPU, 64k RAM:

https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system)

https://www.youtube.com/watch?v=5OT3DoPty4Y

Yes - some of us want to use our multitasking systems for multitasking.

How many tabs do we have opened in our browsers? I rarely have less than a dozen. I think it's fair to say that "browser as a runtime" isn't incompatible with multitasking.

You can say that it would be better to share a common Electron instance, but it's not an argument against the idea of using web technologies for desktop programming.

Yes, if hello worlds uses that much then how much do complicated apps use?

I guess I believe it is common that if a platform becomes popular enough for developers - solutions will appear to allow them to reuse their knowledge in developing applications outside of their original target platform.

Furthermore in the attempt to woo developers from one popular platform to another a myriad of solutions will appear to allow the developer to move their existing tools, methods, and general knowledge from their comfortable and familiar platform onto the new one.

I'd suppose anyone that has more than 5+ years experience and has moved between at least two types of platforms can point to examples in their mind.

Personally I dislike this habit of using tooling to solve platform movement and escape the time constraints inherent in learning to develop for a new platform; I can however see the attraction, because, it really does ease time and effort in learning something new even if to provide this easing it acts a buffer to any deep understanding of the target platform.

There are more advantages than just not having to learn something new. There are really compelling reasons you might want to use the same code in some combination of: a web browser, web server, Windows app, Mac app, iOS app, and Android app.

For instance, when FB used React Native for building one of their ad manager apps, they had 87% code reuse between iOS and Android (https://twitter.com/brindelle/status/618114397098102785) The implications that has on a company's eng organization are huge.

Another example is the code sharing between client and server in Meteor. That has big implications too.

The main reason Javascript is winning as the lingua franca is that it's pretty much the only language you can use in a browser. The main alternatives are things that compile to JS, like Babel, TypeScript, and for a while Coffeescript and Dart were gaining traction too. If browsers could run, say, Python, I suspect you'd see more Python used in this way as well.

>There are really compelling reasons you might want to use the same code in some combination of: a web browser, web server, Windows app, Mac app, iOS app, and Android app.

I agree, but it is my experience that this always comes with a downside that you don't know some of the platforms you are running on and there are deficiencies. The Native is better argument

Part of it is also, custom looking UI, not confined to the platform widgets, is not easy to do on many of the desktop platform libraries. It is incredibly easy to do with HTML/CSS.

10 years ago everyone hated on java because it didn't look native. Now no one wants anything to look native.

There is no "View source" button for native applications, and you can not modify them and see the results immediately.

This is not true. Electron comes with the full suite of Chrome Dev Tools (CTRL-SHIFT-I is default when enabled). You can certainly achieve a live-coding experience with Electron[1].

[1]: one of many boilerplates - https://github.com/chentsulin/electron-react-boilerplate

Probably 90% of .NET/JVM apps, you can hitch a decompiler up to and "View Source".

Patching the byte code and having it run is a little tougher...

JS is safe C with types and pointers stripped from the syntax.

I don't get why people don't understand its popularity.

HTML lets you put boxes on the screen and CSS lets you paint-by-number(id/name/selector).

If you aren't doing any of those things, I am very curious to know what exactly you are doing.

I think people hate the quirkiness of it and the dynamic typing.

JS is most definitely not safe C. It has a brace based syntax with if statements and for loops but other than those superficial similarities it's semantics are vastly different.

    x += 2;
    call(param);
    data.key = cache[0];

Just like PHP :-)

Reply on news.ycombinator.com