> 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.
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.
A programming language is not supposed to match human intuitions. We are trying to take things from the physical world an represent them in the digital world.
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?
"very good Javascript programmers can be significantly better in a better language."
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.
You said it. You're not an expert. You are comparing a prototype based language to oop languages. You're basically putting the wrong fuel in a car and blaming the car. You are lazy in my opinion because yes there are few resources that teach you how to use the language properly but plenty that compensate for those who want to make it familiar to back end devs. If you looked for good resources you will slowly discover that most JavaScript developers do not understand the language well because of the same assumptions you are making. It's a highly misunderstood language due to human stupidity.
"The big selling point for me with React is that I no longer have to learn yet another templating language."
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.
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.
> 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.