Hacker News Reader

Comment by mhd | Hacker News Reader

> [ ] You have reinvented Javascript but worse

> [ ] You have reinvented PHP but worse

I'm trying to think of languages that would fit that bill. That almost sounds like a challenge.

Maybe JScript (Microsoft's proprietary JavaScript) and/or VBScript (VB sometimes shoehorned into a JavaScript-style role) would work for the first one, but to be honest I don't have enough experience with either to know if the "but worse" statement is fair.

Also the "sweet spot" for Lua has some overlap with JavaScript but I don't think the "but worse" complaint is quite fair and I think Lua may actually pre-date JS.

But surely there are a bunch of HTML templating languages that would fit the category of "PHP but worse".

>I think Lua may actually pre-date JS

And it does

JScript is misunderstood. It isn't a proprietary JavaScript competitor. It's just Microsoft's implementation of JavaScript. They had to use a different name when talking about it in order to get around trademark issues.

There were some differences from Netscape's implementation, but they're pretty minor compared to the dialectical differences between competing implementations of pretty much any other language.

You misunderstand the real evil of JScript. Microsoft made it to be a complete clone of Netscape's implementation.

When Netscape decided to standardize the language, they went to ECMA. Microsoft didn't have ECMA completely under their thumb, but did have some control.

Netscape wanted to fix some fundamental issues with JS, but MS had just spent a ton of money making their clone, so they insisted all those problematic bits stay right where they were.

So, JScript is to blame for most of the bad parts of Javascript and is therefore worthy of all the hate you could possible heap upon it.

That's all beside the point. The focus of the discussion was whether JScript could be described as a new language ("you have reinvented...") that's basically Javascript but worse. It can't, because it fails the "new language" test: it's just a different name for the same language.

Arguably:

  PHP is like Javascript but worse.
  Since React, Javascript is like PHP but worse.

document.write called on a loaded document? Reopen it and clear its contents. Yes because that makes sense and I wouldn’t want that to be an error state. Oh JavaScript.

(But also, just don’t use document.write)

What if you actually wanted to replace the entire document contents with a new document? Why should that be an error?

The fact that the meaning of the API is commonly misunderstood is not (necessarily) a fault of the API

Sure, something like a .clear or similar but the default behavior of clearing a loaded document by calling open on it is strange compared to what you would expect to happen with “normal” files/streams.

Edit to add:

I think calling write on a loaded document should have been an exceptional case and you should have had to explicitly call something to unload, replace or clear it.

Brainfuck [0], Whitespace [1] and INTERCAL [2] come to mind :)

Of course, one could argue none of these are 'serious' programming languages.

---

[0]: https://en.wikipedia.org/wiki/Whitespace_(programming_langua...

[1]: https://en.wikipedia.org/wiki/Brainfuck

[2]: https://en.wikipedia.org/wiki/INTERCAL

Are they even similar to JavaScript or PHP?

> [ ] You have reinvented Brainfuck but non-ironically

JS and PHP are worse because people have to use them.

Does PHP modify code client side like Javascript?

IMO this is the inherent difficulty with Javascript. I would prefer that you have the "source code" as two separate things: the hard details of the page and the code to manipulate behaviour.

This [1] current HN front page link would illustrate what I mean. You have a colour palette (hard details) and the behaviour (code to plot the colour palette). Of course this is a simplification, but it shows the way of thinking and the way of optimising use of code and space.

[1] https://news.ycombinator.com/item?id=21937607

That's not really a difficulty of javascript the language - you're supposed to have your javascript completely separate from the HTML and CSS, with everything in static files of that type. Separation of concerns was built into the web from the beginning.

It just happens to be a popular architectural pattern at the moment to reimplement the DOM, HTML and CSS all in javascript and have one big mess of code.

Separation of concerns can be handled in one language. The popular MVC pattern does not require three separate languagues. And in fact that's rare in my experience. So web frameworks moving towards the norm and allowing it to all be handled in the same language should not be surprising or a mess.

>The popular MVC pattern does not require three separate languagues. And in fact that's rare in my experience.

ASP.NET MVC uses C#, (C)HTML and CSS for a total of three languages. WPF uses XAML and C# for a total of two. Android uses XML and Java for a total of two. I think Delphi only uses one, I vaguely remember the designer outputting plain Delphi instructions? I might be misremembering.

React is not exactly encouraging separation of concerns, and in some ways this was better in the times of JQuery. But I don't think this is directly related to the number of languages involved.

Of course when it comes to the web it's three languages underneath. Per the standard, you can't escape that. Now look at apps that are built to run on an OS using MVC. It's usually all in the same language. Why?

Separation of concerns doesn't imply separate languages. There might be some merit to the idea of a DSL for each concern? But if the end result of that experiment includes CSS, I would call the experiment a failure.

Android, WPF and Universal Windows all use XML to specify UI, and the programming language of choice to specify code. That's still two languages, even if it removes the need for a third language exclusively for styles. In each you could use pure code to build the UI but readability and maintainability would suffer a lot, so nobody does that. Once you have the view separated from the controller, writing the view in a language better suited for nested UI seems quite natural.

What are examples of MVC using only one language?

Perhaps Cocoa development, though it typically used a GUI tool for the UI layout, so not really.

Smalltalk, but Smalltalk MVC is different from what MVC typically means nowadays.

FWIW, WPF uses MVVM, not MVC. The differences are as subtle and pedantic as they are important.

I'm not sure how common vs not common Interface Builder usage really is. At any rate, I'd say "typically" is a stretch.

That's fair. My experience on the subject is admittedly pretty ancient. When I was doing it, back in the early 2000s, IB was how everyone I knew did it.

You're right that it's not javascript's fault per se. But the rest of your comment represents a narrow, dated and frankly ignorant viewpoint. Component-based front-end architecture has tremendous advantages. And if you want to see "one big mess", simply examine the CSS of virtually any moderately-sized website or web application.

I've been doing web-related development since the late 90's, and I make a living as a UI Architect. Increasingly my clients are looking for my help to unfk their nightmarish, effectively unmaintainable legacy codebases -- which typically have followed this same cargo-cult "wisdom" to their detriment.

I'll just vaguely gesture in the general direction of the multitudes of developers on HN who both work with front-end frameworks and complain ceaselessly about what a nightmare it is and stand by my statement.

It can have both tremendous advantages and be a mess. Both can be, and are, true.

Fair point.

Component-based architecture doesn't imply JS-based versions of HTML and/or CSS, though. React does it that way, e.g. web components don't.

Not that I'm averse to "reinventing" HTML or CSS in the first place, although doing that in JS would be somewhat ironic.

Huh? How do you think web components are implemented?

Hint: they're JS APIs.

When we're talking about reinventing HTML, there's a bit of a difference between a regular block of HTML between template tags and JSX I'd say.

Svelte.

Care to elaborate? I haven't gone derp w Svelte and Sapper, but have heard good things. Interested in any meaningful critique.

Can you tell why?

> You have reinvented Javascript but worse

Any language that compiles to JavaScript.

https://flak.tedunangst.com/post/technical-debt-and-tacking-...

> lessons learned:

> Those who don’t learn from history are doomed to repeat it. Any day now, I suspect some fools are going to want to write web apps, but they won’t want to use raw javascript and they’ll create some ridiculous custom language to javascript compiler. I can only hope they have the good sense not to tell anybody about it.

> Any language that compiles to JavaScript.

What if I compile javascript... to javascript. So that I can have actually functioning javascript across the majority of fairly modern browsers, while using modern features.

All I'm saying is, honestly. I don't blame people for not writing straight javascript, when even if you do, you still need a build system in between if you want to support all browsers.

Reply on news.ycombinator.com