E.g. Typescript gives you literally all of JS - and a way to keep things tidy.

Typescript which is a compile-to-js language in a weird way proves how lacking js is - while still buildiing on top of it.

This is not how it works.

Take this idea that JavaScript is a "badly designed language" out of your head and understand that about 99% of JavaScript's behaviours are intentional.

The majority of gotchas in JS are shown by people who don't understand type coercion, prototypes or who expect it to behave like x language.

It is not just misunderstood by your average Joe JS dev, but also by many who claim to be pros and experts.

JavaScript is a language that doesn't tell you how to do things, there are no constraints. This is why so many people suck at it.

They want to use statically typed classical inheritance constraints on a language oriented around higher-order functions, coercion and literally everything being an object.

If you are somebody who is intuitive enough to create your own restrictions on what to use and what not to use in JS from the POV of the language's architecture then you will love it.

If you are convinced that there is already a holy grail structure to programming languages then you will always have problems with JS.

TypeScript is miserable. I see people building libraries in TypeScript and it's sad because they will never know how much better their performance could be or how small their lib size could be because the can only think in OOP.

OOP languages are already hugely problematic when it comes to complexities. So imagine how overly complex the JavaScript eco system is becoming due to a generation of developers who want it to be more like x OOP language it does not have the foundation to be like.

There is no defacto solution for software engineering everything still sucks, and nobody remotely has it figured out.

Respectfully, no. The impressive thing about it is it was written in 3 weeks. Edit: I also didn't say Javascript was a badly designed language, at least not in the post you replied to.

The rest of it is like PHP (yes, I have programmed a fair bit in that as well).

> and understand that about 99% of JavaScript's behaviours are intentional.

So much worse ;-) There is one good defense for Javascript IMO and that is it was made in a very short time.

Intentionally leaving in a heap of footguns like Javascripts type coercion isn't brilliant, it is either pragmatic, myopic or evil. I say pragmatic in this case.

> The majority of gotchas in JS are shown by people who don't understand type coercion, prototypes or who expect it to behave like x language.

The classic Perl defense I'd say: ~you don’t understand the beauty of it.

> TypeScript is miserable. I see people building libraries in TypeScript and it's sad because they will never know how much better their performance could be or how small their lib size could be because the can only think in OOP.

Well, every thing you can do in JS you can also do in TS.

In a sense you can say this is our implementation of what you said above: "If you are somebody who is intuitive enough to create your own restrictions on what to use and what not to use in JS from the POV of the language's architecture then you will love it." And here you are right: Typescript is quite a lovely language:-)

Also: By this logic we should be programming in assembly.

Actually 10 days, with 22 years of development, but that has nothing to do with how it fundamentally works.

> The rest of it is like PHP

Are you joking? Ok so, JavaScript is a prototype based language PHP is (now) an OOP language. They are not remotely the same with the exception of dynamic types and even that is nothing like PHP due to the nature of JS engines like V8. But because if the prototype system it can emulate classical OOP.

JavaScript is also a higher-order language which mean it is a psuedo-functional programming language.

PHP and JS could not be further apart.

> The classic Perl defense I'd say: ~you don’t understand the beauty of it.

It's not about beauty, I'm saying that most people who think the language is making mistakes or doing something wrong just don't understand how it works. They blame it for their lack of knowledge.

> Well, every thing you can do in JS you can also do in TS.

But that's not why people use TypeScript, they use it to do TypeScript styled things.

> what you said above: ~ intuitive enough to create your own restrictions

That's the problem, TypeScript comes with a bunch of constraints, that's its purpose. Yes you can choose to use them or not. You could also buy a new phone and throw it off a cliff, but that's not generally why people buy phones.

> Also: By this logic we should be programming in assembly.

Assembly serves a purpose well, so does JavaScript. I'm just saying rather than trash things why not learn them first properly.

And once that lib gets larger then 4 files, it becomes slower and slower to maintain, because JS. Spinning up new devs on any large JS project is a pain. Typescript, no problems.

Lib size differences are ~0.

What exactly do you propose? I will test it out.

I use Typescript as well.

Or maybe it's a highly misunderstood language because it doesn't match human intuitions. That makes it a poor language, like the OP said.

A programming language should be modelled on physical life. But we still haven't figured this out yet.

I don't think many people understand what a poor language is, you really need to understand the spec fully and experiment with every paradigm in production to claim that JS is a poor language. Can you genuinely say that you have?

I'd say that's a flat out false conjecture. Given a choice between two programming languages, one which better matches our intuitions and one which doesn't, the one which does will always yield programs with fewer bugs because we will simply be better able to express our solution to the problem being solved, and we will be better able to understand the program and so extend it.

It's like saying that door knobs are not supposed to match human intuitions, they're just supposed to open doors in the best manner possible. Well guess what property opens doors in the best manner possible when humans are the ones opening doors? A door knob that's most intuitive and natural for the majority of humans to use. HCI and ergonomic factors are seriously underappreciated in computer science.

> you really need to understand the spec fully and experiment with every paradigm in production to claim that JS is a poor language. Can you genuinely say that you have?

I've used OO, FP, prototype-based, logic and constraint-based programming languages. Yep, I think I can say JS is not a good language. It's improved somewhat, but still not great. It's not Brainfuck-bad, but it's not particularly good either.

> A door knob that's most intuitive and natural for the majority of humans to use.

Ok so let me explain better:

The UX = Human End-users POV (intuition)

Programming syntax = Human Developers (intuition or whatevr)

Tools to deliver (Browser API, CSS) = The domain/s

The way in which we structure work = the things we are building = things that exist in real life.

Websites are mis-leading because many pages appear alike people tend to believe that there's a lot of repetitive components but there really isn't in general.

So inheritance is usually way over used despite the style of programming.

I am not discussing how we use a door knob. I'm arguing about how we build the door knob of different variants in mass production.

> It's not Brainfuck-bad

Brainfuck is not a "bad" language, if it serves it's purpose well then it is good. I think Brainfuck is doing exactly what it intended to do.

There are people who have been using JS for 20 years who think it is terrible. It's because they have never taken time out to learn the language properly. Most JS devs don't

I'm not convinced that you have because you clearly wouldn't be saying x is a poor language. No language that is in high demand today is a poor language.

Well that's clearly false. COBOL was in high demand at one point. The popularity or prevalence of a programming language has very little to do with its technical merits. We've seen this play out dozens of times over the past few decades.

And "X is bad" is typically intended as a relative measure. JavaScript would have been a great general purpose language compared to the state of the art in the 50s and 60s, maybe even as late as the 70s. It was maybe ok as an embedded document language at the start of the web in the mid 90s, since everything was so experimental and quickly evolving. It's not a good language now, and hasn't been for some time. It has some good qualities, but also many bad qualities that run into bad software engineering practices.

Finally, I'd say that any language that many people would rather use a transpilation/compilation target rather than use directly, is clearly a bad language.

<there class="is-no"><extra>Mental Step</extra></there>

Currently aside from JSX and things like mustache some devs are using h https://github.com/snabbdom/snabbdom#inline-example and Cycle has a syntax not far off from what I'm proposing http://widdersh.in/tricycle/ . But the syntax is not actually the big deal, the biggest benefit is the complete separation of logic from semantics.

I don't expect everyone to like it but I don't think it's horrible or difficult to look at when used in a real project.

Then maybe allow JSX? The way I write my React components, the view is what you find in the `render()` method, and there is little to no logic there. The big selling point for me with React is that I no longer have to learn yet another templating language. Which seems to be somewhat where you are leaning as well. But being able to read HTML as, well HTML (or something very close like JSX), has a lot of benefits. Just going between code and the browser debugger for example. The mental step of translating between what I see in the browser and what's in my code, is in fact a step.

Hmm, I get the impression you're tired of having to learn something new and you're happy to stick with what just works for you. . I understand but I'm not sure everyone feel that way, but I would be honest enough to say I think most people in FE development are on your wavelength.

Here's the entire syntax documentation: - Tags are functions - Attributes + props are object literals - Strings are text nodes, - Remaining parameters are child elements

It's nothing but basic JavaScript.

The separation is not enforced by API it's a discipline that can't be forced into React via JSX as far as I've tried.

Here you have: - No transpiler - No logic mixed in semantics - No vague component separation - No wrapping everything in a div (use ...spread) - No new syntax to learn

Maybe it's not for you, but the advantages are more than obvious.

If you are having performance hits with SVG you are using it wrong. It's like developing a video console game for the first time without any prior knowledge to video game development, memory techniques, asset loading, and so on...you will make a shitty boated game. 99% of active web developers & designers mis-understand SVG under the hood so don't be surprised if you can't find one predominant example of SVG in production.

In regards to the viewBox, what is its purpose? It is there to keep content in proportion. But why? why is the viewport not the viewBox?

Because the viewBox was created around 1999 when computers were slow and SVG was also heavy and slow. The viewBox had two apparent agendas, i) To reduce scaling of content, that would require more calculations to render ii) To be more in-line and proportionate to CSS. Because CSS in 1999 looked terrible on high res monitors.

The viewBox was a way to downgrade SVG for practical use back then, but the beauty of it is that it can be tweaked to behave in a full screen scalable fashion. This is why SVG is more desirable for the future.

So no, the ViewBox solves nothing in CSS, SVG is an amazing technology that people refuse to understand because they don't want to think too much.

SVG is not actually slower than canvas, if you see two equivalent examples of SVG and canvas the canvas may seem faster but that's because it can not do as much. If you now try to add multiple events to animated element SVG will perform faster.

People need to stop the obsession with CSS and learn SVG so vendors can improve the performance, spec and so we can make shit look good on the web!

You don't need to be a "computer scientist" to understand vector based graphics are the future of the web.

How that area will be fit into the viewport is determined by the "preserveAspectRatio" attribute.

If you don't define any viewBox then there will be no scaling - 1px in the viewport coordinate system will be mapped to 1 user unit in the abstract initial user coordinate system.

There's too much talk about "typescript" and not enought about what problems Angular 2 solves compared to "not" having a ready made framework or how many problems it adds.