Sounds like Elm [0] (pure, functional, very very easy to start with but lacks abstractions), Purescript [1] (pure, functional, powerful, the best language for the web right now, imo) or ReasonML [2] (functional but impure, familiar syntax, focused on pragmatism) would be right up your alley.
If you're ok with a dynamic language (i.e. strike rigour), then look no further than Clojurescript [3], Clojure's [4] little web brother. An elegant and simple Lisp, it makes almost all other dynamic languages completely obsolete.
There most definitely are sane options for developing for the web if one is willing to use a compile-to-js language.
Not everybody wants to spend next 5 years learning thinking bottom-up, mastering category theory, monads and all that for such a task like writing a silly webpage you wouldn't rather be doing.
[rant] Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology. I program in Haskell/Scala but pushing functional programming everywhere is IMO just insanity and everybody is silent about many warts and weirdness of purely functional programming. [/rant]
https://medium.com/@eeue56/why-type-classes-arent-important-...
"Right now, any Elm developer can examine Elm code that another developer has written, and fully understand what is going on. I consider this a major thing that Elm has got right."
And
"Elm is targeted at the main source of users it has — Javascript developers. Javascript developers may be familiar with typeclasses, but it is less likely that they are than Haskell developers. Alternatives like Purescript provide more abstractions and powerful type systems suited to those from the Haskell community. There are many of us Haskell users who sit happily with Elm too."
Elm favors simplicity and pragmatism over academic FP lingo. You need to change your way of thinking a bit, true, but it benefits the architecture. And it'll take weeks, not years!
You will not find the words "monad" or "category theory" or "algebraic datatype" used in the Elm docs.
I would recommend Typescript then.
> Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology.
True, FP excels at concurrent programming, but that's far from its only strong point. I'd propose that React-like architectures (which are based around a pure Model -> View function) and functional languages are a match made in heaven.
Funny, all people using Typescript I know use it in functional way (computer vision/AR in a browser).
Scala and ML-variants like Ocaml, F#, Reason.js are perfectly good imperative languages. They don't force you to go purely functional. I always recommend that my students (whose first language is Java) start by treating Scala as a "nicer Java", and then slowly explore Scala's more powerful features. Indeed, I'd argue that Scala and the aforementioned ML-variants are (slightly) better general-purpose imperative languages than the Javas, Pythons, PHPs and Javascripts of this world, because they are more consistent, they have types/type-inference, and their statefulness fully supports higher-order state and powerful modularisation without restriction, not to mention pattern matching.
Being able to use functional idioms without compromise if and when desired (including, but not restricted to, pure functional programming) is another benefit of Scala and ML-variants.
The biggest problem of very functional code on the web is simply debugging it. So much control flow is buried in compositions that there isn’t much to grab on in terms of break points or variable inspection. Pure languages exacerbate this problem by making state more difficult to dig out and pin down at run-time.
I don't see why that's a problem with FP and not just the lack of tooling in most FP languages. Debugging in F# via Visual Studio is a breeze, and OCaml's time travelling debugger looks pretty good.
do
x <- newIORef 0
writeIORef x 2
print =<< readIORef x
[0] https://en.wikipedia.org/wiki/Software_transactional_memory
The notion of monad comes from category theory [...] It first arose in the area of homological algebra, but later was recognised (due to the work of Kleisli and of Eilenberg and Moore) to have much wider applications. Its importance emerged slowly: in early days, it was not even given a proper name, but called simply a "standard construction" or a "triple" [...] Eugenio Moggi proposed that monads provide a useful structuring tool for denotational semantics [...] He showed how lambda calculus could be given call-by-value and call-by-name semantics in an arbitrary monad, and how monads could encapsulate a wide variety of programming language features such as state, exception handling, and continuations. Independent of Moggi, but at about the same time, Michael Spivey proposed that monads provide a useful structuring tool for exception handling in pure functional languages, and demonstrated this thesis with an elegant program for term rewriting [...]. He showed how monads could treat exceptions [...] and non-deterministic choice [...] in a common framework.
[1] P. Wadler, The essence of functional programming.
I've been learning Elixir (a functional language) for a new project I'm working on and even with only being able to allocate 20-30 minutes a day on it, I don't feel like I need to relearn everything. This is with no prior functional language experience, just a bunch of general experience with Python and Ruby.
I have no formal CS education and while I've heard the terms category theory and monads before I have no idea what they are. In my mind, monads are some Haskell related meme and category theory is thinking about whether or not to use categories on a blog engine.
I found Elixir to be curiously easy to adapt to. I spent like 15 minutes glancing Elixir's documentation and now I'm running a Phoenix based web app (somewhat comparable to Rails but not really) following an "error based development" work flow.
This is where you try to do something, completely fail at it, look up the answer and figure out how to apply it. I don't even know how most of Elixir / Phoenix works yet I'm able to accomplish real things.
After spending 15 minutes reading Phoenix's docs on routing, I actually feel like I understand Phoenix's routing system better than other frameworks in different languages that I've worked with for years. This is partly because it's so easy to just trace a function call back to another function call and understand what's going on (plus their docs are badass).
...which targets JavaScript in addition to the JVM (and being an officially supported language for Android development): https://kotlinlang.org/docs/reference/js-overview.html
I ended up going with vue which uses mutations instead of having to return structure copied from functions.
Just made more sense to me. Maybe MobX does this for react? Idk
Those are all great languages. It is important to realize that they will increase bundle sizes, which is a common rant about web pages these days. Hello world in Bucklescript/Reason, for example, is 23 KB (anything touching the std lib at least), Elm much bigger than that. My friend's 500 line Clojurescript/Reagant app was over 500 KB uncompressed, 5k lines of JS will come in at 140 KB.
It's worth being aware of the tradeoffs you are making, because often when people are selling new tech they tend to overstate advantages and understate disadvantages.
Absolutely, and it wouldn't make sense to program a tiny static webpage in e.g. Purescript.
That said, to put that into perspective, pulling 350 npm modules for a bigger project is kind of the norm now. Using compile-to-js languages will incur more overhead still and it depends on the project whether that's acceptable or not, but many times it most definitely is (also, I hope webassembly will help with bundle sizes in the future.)
I'm not really up-to-date re Clojurescript's package manager, but I know people who've specifically stated that one of the reasons for using Clojurescript is that package management and bundling is just so much easier than the standard JS npm/yarn/bower/gulp/webpack/etc amalgamation.
Being able to use modern JavaScript and with linting/prettier will in practice make it pretty rare that you end up doing stupid things due to language limitations. And if you want types you have TypeScript that works very well in most work flows.
html/css is pretty ok to work with these days and libraries like React and that echo system makes it pretty easy to scale web development so that many people can be involved in the same code base.
Most sites are not applications and never will be. Most businesses will never need a complicated site. Most of the Web has zero beneficial use for React or ECMA 6. Factually that's easily demonstrated just by looking at data compilations of what the Web largely consists of: static content, typically pushed out into the world via a basic CMS. That isn't going to change. Most of what's going on is an evolution in the top tiers, up the value chain. Facebook & Co have dramatically greater technology demands than Joe Small Business or Susan the blogger.
Oh, you mean setting up a state of the art web application? Years ago we had to roll our own pipeline, often building our own bundler and you had to use a ton of separate tools not meant to work together. There was no package manager so we had to download all of the stricts from random websites and hope for the best sticking them in a /vendor folder.
Nowaway you use the CLI of your favorite framework, type 1 command and you have an app all configured for a real world production environment. It's never been easier (and is easier than pretty much any other type of software development).
The only thing that changed is that since its so easy, you are expected to produce a high quality app if you want to be taken seriously. That part is hard.
Now you have a react app with a development up and running. To create a production build write "npm run build". To add a package write "npm install the-package".
It is, but it's getting better because so many different approaches have been tried that some of the more scalable and maintainable ones have been worked out. Also, (thank heavens) browser support is a lot more consistent now.
> I need to build a website soon and I’m dreading the front end.
If you're a software developer, I recommend some atomic/functional CSS toolkit, like Tachyons. That will free you from having to do probably 90% of the CSS work you used to have to do, and it matches a more programmer-type mindset to styling elements.
I'm building a site now, and so far it I've just needed to define some style classes for the colours, and the rest of the styling is already included out of the box via their reusable classes.
For the JS side, really depends what sort of dynamism you're looking for. You can go with a tiny JS library for polyfilling and standardizing browser behaviour [1] if you're just doing simple DOM manipulations, or if you expect to be doing a lot of AJAX with dynamic rendering, go with something like Surplus [2], or Vue, React or Mithril if you want something more standard.
I’m not familiar with the Elm ecosystem, but I would be surprised if they don’t have pretty good (or likely excellent) tooling as well. I’ve seen syntax highlighted Elm and it’s well known for it’s excellent error messages. Any language change is likely to involve changes in the tools you use, but I don’t think that lack of tooling is a reason to avoid either of these.
I assume web assembly will bring sanity to the frontend PL world, which will be a step forward.
How come?
On the other hand, many developers don't know much about programming and JavaScript, and therefore tend to have unjustified criticism of the language.
JavaScript was a perfect choice for Node.js. It's event-driven design is a perfect fit for a performant web server. Python would have been a bad choice, because it didn't support asynchronous programming when Node.js was created. Furthermore, using the same language in the backend and frontend will reduce context switching, enable code reuse and generally speaking improve implementation efficiency.
modern js is still js. the fact that linters are _required_ to keep code sane is proof enough. typescript is a different language, i'd wager it doesn't count, even though i agree it's a considerable improvement.
au contraire, many developers know exactly what programming in js looks like, especially compared to other languages. i used to think that c++ and boost compilation was crazy. now i look at glorified web pages with 200MB+ of dependencies and wonder how we got there.
i agree that js was a perfect choice for node.js, because it was the only choice for node.js - to use the same language that runs in the client. that doesn't make it a good - or even sane - choice in the greater perspective. python was and still is a good choice - twisted was used to create async services before ajax was a word. you can also take a guess from where the promise/deferred pattern took at least some of its inspiration.
I fully blame the virtually non-existant standard build- and module system in C/C++/JS for a lot of the current problems.
This is one of the reason I really want to learn Rust. Compared to make/npm/gulp its infrastructure looks heavenly.
Async was not part of the core language when Node.js was first released. Even today the library ecosystem of Python is fragmented, not everything works asynchronously.
Python built linting into the language itself and it's super annoying.
JS fans said the same thing years ago, claimed that it didn't need classes, more extensive core library, or better syntax. Then came ES6, almost a different language, and they magically changed their opinions to match. Apparently all those features they dissed were needed and good. After seeing this kind of switch-a-roo several times I realized that most of JS community have no fucking clue. They will gladly consume and defend absolutely anything they currently consider "theirs" and "modern". It's a matter of fashion and identity rather than language and tooling quality.
JS was and is a horribly designed programming language. The Web would be lightyears ahead of its current sorry state if the core language was a dialect of List of Smalltalk.
Well, I didn't make that argument.
ES6 is not almost a different language. It provided many good features, though.
>JS was and is a horribly designed programming language.
Nope.
I'd suggest that inexperience/ignorance isn't a great place to analyze anything from. Some of the "major" issues that dominate these discussions are not problems in practice.
Other people simply accept different trade-offs than you.
But a whole bunch of 'serious' applications have obviously been written using JS, and it's a totally stupid view to think otherwise. Frankly the people who are the most concerned with 'my language is better than yours' litigation are by far the least productive developers I've encountered.
If you want to use constexpr in C++ you're going to have to upgrade your compiler as well, right (and, if you're unlucky, "migrate your project files" and all that mess)?
You couldn't be more wrong. The toolset that you need to develop decent C/C++ programs is massive and took decades to develop.
They all have really ugly parts at least in JS they don't slow you down.
I agree that they are problems, but their impact on day to day use of the language is zero.
If you want examples of real problems that give good front end devs hell day in and day out, start looking at some of the libraries, tooling and abhorrent "best practices" that get thrown out and cargo culted to death by the community.
The language itself is the last problem with JS
I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard.
I guess worse really is better.
How exactly? I'm really curious. AFAIK it's pretty hard for a JS string to be casted into anything (pretty easy the other way around though).
I guess maybe parseInt can do that, but that's neither casting not implicit.
I could easily reproduce the bug but it took me forever to work out why JS was choking. I think I added in some ridiculous string padding to prevent the auto casting.
https://stackoverflow.com/questions/2547836/why-doesnt-an-oc...
That was published 9 years ago.
While I understand that a problem like this is unnerving, it isn't the rule.
People throwing around strawmen in here like nobodies business.
We can do this with all languages and tell ourselve we're using the "superior" language.
I do agree with you that the JavaScript community's issues you mentioned are hell to deal with; however, in my opinion, JavaScript's internal weaknesses are one of the driving factors behind this churn.
> re: it doesn't have multiple ways of declaring a function...
Python does have multiple ways of declaring a function, the usual `def` syntax and via `lambda`. Lambdas are restricted to one line (due to Python's whitespace sensitivity), which can be inconvenient (but hey at least no one can abuse it right?).
Python functions also have a scoping gotcha: you can read the variables in the outer scope, but if you write to it (without declaring it as nonlocal) it actually treats that as a separate variable declaration (this is due to its assignment syntax).
> re: Python's datatypes are straight forward...
While Python's type system is nowhere as lenient as JavaScript's, there is at least one unexpected case which works: `True + 1` produces as valid result (2). Also, having to explicitly cast non-strings is rather inconvenient when concatenating stuff to produce a string (even Java doesn't require this). Thankfully, Python has a decent string formatting function built-in.
> re: 9999999999999999 is precisely 9999999999999999
It'll still fail if those are floating points. Yes, I am aware that Python has decimal and rational types in its standard library. My point is, no matter what language it is, programmers need to be aware of the data types and data structures they are dealing with.
FWIW, I don't think JS is better (or worse) than Python (as long as we're talking about "modern" JS with modules). Python also has its fair share of major issues, notably v2 vs v3, which is slowly becoming a non-issue as everyone (finally!) migrates to 3.
JavaScript is more dynamic than most languages and yes this may be hard to grasp for the average developer, especially when they come from languages that are considered "more mature".
True, and we could go one step further: it's unambiguously defined, with invariant rules that can be used to prove a conformant implementation.
XMPP had been defined as formally: where have we ended up with it now?
Python's type handling is much better, but that can be mostly avoided in JS by understanding and avoiding the cases where js typing sucks.
Other than Python's superior type handling and standard library they seem like very similar languages to me.
JavaScript numbers are IEEE754 double precision floating point format.
But I'd wager that the "no integers over 2^53" is seldomly a problem, and in most other languages there's a similar problem at 2^64. If you reasonably expect to get integers above 2^53, you probably want to think about how to deal with integers above 2^64 as well. So really it's the exact same thing except JavaScript's numbers are easier to complain about on the internet.
I did some Ethereum front- and backend development in both Python and in JS, and this made a lot of difference in the readability of the code. In Python, the only problems we encountered was when writing into ndb, which has 64 ints by default, whereas in JS, we had to use BigNumbers everywhere.
Pretty cool! Learn something new each day :-)
Let's take a step back here: the web is designed, from the ground up, for hypertext, interlinked documents comprising text and images, some of which are clickable and lead to other hyper-documents. HTTP - hypertext transfer protocol. "Web dev" should be referring 100% to things that happen on the server, which can be in any language you like, generating documents that are rendered as the end user would like. Forcing a thing designed for documents to run entire applications is what has gone wrong, it is, on the most fundamental level, an incredibly stupid thing to even try, but the entire industry did, and here we are today. It would be like MS declaring all Windows development henceforth will be in VBA macros for Word.
This is why the real engineering disciplines don't take software engineers seriously. You would never see a civil engineer try and construct a bridge out of some completely inappropriate material...
I think the main problem is everyone insists on over engineering a fucking website.
Moving apps into browsers is a step backwards for most apps and most users. I was using Jupyter the other day; it’s clunky as hell compared to MathCAD from 20 years ago. We use 1000x the computing power, literally, to deliver 10% of the experience. Keeps a lot of devs employed I guess...
You're pre-emptively trying to define what's useful for everybody else. That's the only way your premise works.
In my equally subjective view, XMLHttpRequest radically altered and improved the useful things you can do with the Web.
You can't use a 90s browser for Google Maps, Gmail, YouTube, nearly any online productivity software, and dozens of other common activities on the Web today. You would have to strip the services down to make them work, ie turn them into completely different products.
Simply put, most of the things most people do online today, can't function in a 90s browser. Just try using IE 5 or Netscape 4 with nearly any of the major Web services today. You can't. IE 5 with Facebook's non-mobile site? You have to build an entirely different product to make that work, basic interactivity drops to near zero.
1990s MapQuest sucked, big time. Google Maps is a radical improvement. How about simple things, such as smooth, fast, highly interactive stock charts, or real-time updating stock quotes, without having to reload the page constantly? 1998 browser? Nope.
Would the user experience be better if everything on the Web adhered to strict 1998 standards? That's an obviously subjective opinion. I don't think so. Do people like to see instant previews of the content they're about to post to Facebook or Twitter? When they click the little upvote arrow, do they like to see an appropriate reaction? When posting basic content or interacting with simple site features, do they like having to reload the entire page?
Let me guess... you’re a JS dev and you think “little upvote arrows” are where the real value is?
Clearly the users are wrong, I guess? Perhaps you should explain to them why your delicate design sensibilities dictate that they should download native clients because you think HTTP has gone off spec.
Let me guess... you're a COBOL dev and think computers should have never developer GUIs.
Not quite that old, but I was doing web and Java professionally in 1995, so I’ve seen it all.
The users are not wrong; they’ve simply been trapped in a local minima by inexperienced developers who would rather reinvent the wheel than make progress. Except every time the wheel gets squarer.
Other than that Email is a good example.
npm install -g typescript
then put this in a tsconfig.json file:
{ "compilerOptions": { "emitDecoratorMetadata": true, "module": "commonjs", "target": "ES5", "outDir": "ts-built", "rootDir": "src" } }
then run tsc -w
you can tweak the compiler for prod or debugging output etc. with these flags for the cli or the json config: https://www.typescriptlang.org/docs/handbook/compiler-option...
Then you could add a single css file in which you prefix class names using something like: myprojectuniquename__someelement.
Then if you use async/await instead of callbacks, flexbox in your css, check supported browser features by googling 'caniuse feature', and use fetch for network access, you could have a pretty simple system that works for you in under an hour.
You say that like it's always a good thing. I remember I spent 4 hours trying to import a function from a file that was in a sibling directory before I finally gave up and copy pasted the function.
There's also other things that really rub me the wrong way in Python. Once you get used to writing computations as a map/reduce/filter pipeline with fat-arrow functions in ES7, Python lambdas and list comprehensions feel so crippled and lacking in comparison.
There's a lot of other things that ES7 does really well such as imports, asynchronous code with promises/async-await, array/object destructuring, the spread operator, etc.
Don't get me wrong; I love Python and use it heavily in my day job, but it's not the end all and be all. There are fantastic libraries written for Python that make life really good (think Reportlab), but for applications that are highly asynchronous and I/O heavy, I'd take ES6 running on Node any day over Python.
It seems like you give JavaScript as an example, but what really worries you is the complexity of the front end ecosystem.
Here are a few ideas to reduce that complexity:
Don't use a package manager, you can copy dependencies into folders.
Remove steps from your build pipeline unless you really need them. Use ES16 to get native promises and imports. Or don't use ES16, so you can remove that step from your build pipeline.
Use as few dependencies as possible. Whenever you can, make use of native browser behavior and CSS.
The reality is, if you don't currently serve a website 1,000,000 people want to use, just pick some terrible server side piece of crap and call it good.
If you want 1,000,000+ people to use your website, you better learn that a dynamic user experience is expected, and delivered with eloquent javascript and design.
Largely agree with your assessment except for this. Which package managers are you referring to? 99% of the js world uses npm, and the other 1% uses yarn. I’m not aware of a single other package manager in the web ecosystem. In fact this is probably one thing where they got it right.
I find it kinda funny that you compare to Python as the way you want webdev to be, since Python and JS are very similar in my mind, aside from minor syntax differences and JS keeping more warts from it's early days, they are very similar environments.
I like Python and have been doing some Tensorflow recently, and one thing I've definitely noticed is that Python docs really suck compared to mdn JS docs.
The biggest problem with JS on the other hand, is it's lack of a decent standard library so you have to use a lot more 3rd party libs, and setting up a modern babel/webpack/linter/test tool chain is a pain in the ass with so many different options to choose from.
I think complications of today came from the problems of its past where it was taken for granted that you needed a framework to get around browser differences.
My personal and professional view has been use plain vanilla modern JS. Make an informed decision on whether using a framework makes sense for your particular project.
If you're making a mess of JS, its more likley you need to re-evaluate your approach to the problem rather than the easy thing to do which is to blame the language.
Low-code tools are worth a look, depending on your task. Due to some reason, they are rarely mentioned at HN, But they already work very well for business apps, with some tools even claiming "pixel-perfect" ui creation, so maybe it can work well for consumer apps too.
And Amazon/Microsoft and Maybe Google are all working/having on such tools, so it may indicate these tools are becoming popular.
At some point 10x less LOC has to be factored in as a significant benefit
For SPA go with create-react-app with react router with TypeScript and MobX and you will be satisfied. If you don't need/want to configure things swap webpack for parceljs.
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.
The root of the "problem" is that the web is an unusual platform. It actually punishes bloat, in a way other platforms don't. A native app can use a hundred libraries and a gigabyte of download size to do something trivial, but on the web that won't fly. That means web developers must learn that code reuse is a tradeoff instead of seeing it as a pure positive. That's a good thing in my book. Either take the heat and replace your 10 dependencies with 1000 custom-written lines, which is usually easy in JS, or get out of the kitchen.
Except that native apps, in practice, don't do that, and websites routinely load 10Mb of JS when the user only wants to read a 5Kb article.
1. Our reliance on typed languages, compile-time errors, and IDEs
2. Too many choices for frameworks and libraries.
I wouldn't agree that JS is a poorly designed language. I will come back to that soon.
I would argue, like some others here that we are just too lazy. We enjoy the safety provided by typed languages and compile-time errors. That is one reason to love our IDEs.
Back to the problem. There are a lot of things that you are saying. I will try and address them one at a time.
> web dev has been badly engineered. * Yes, no, and it depends. Web Dev is a very board, it encompasses many technologies, like HTTP, HTML, CSS, JS, Application servers, etc. So you are saying HTTP id bad? or HTML is bad? I know I'm reading it out of context, but bear with me. I believe you meant JS is bad. That brings us to your next opinion.
> JavaScript is a very badly designed programming language. * When you say badly designed language, what is it that you exactly mean? Is it the syntax? Is it the grammar? Or is it the fact that it is loosely typed dynamic interpreted language? And what are the problems you talk of, any examples?
> Is JS a recognized terribly designed language?
* Who recognized it, any sources? Like the U.S.A. recognizes ISIS as a terrorist organization. I'm pretty sure the developers of node.js do not recognize that JS is a terribly designed language.
> There are many frameworks for the same tasks, that try to do everything.
* Yeah, I agree. I really hate having so many choices. I have to spend too much time investigating which is the best one for my use-case. I'm just too lazy. (sarcasm was intended) That said, I still agree, and it does make life hard. But too many choices is not a bad thing necessarily.
> There "appears" to be an excessive number of package managers.
* There is only NPM, everything else is either deprecated or based on NPM. Please inform yourself better.
> ... range of solid and well-designed languages and technologies, but at the front end ... choose the least poor of a bunch of crazy options.
* WHAT? There is only 1 option on the web today; JavaScript. Period. Unlike backend. What you are talking about are framework and libraries. Check the "too many choices" point above. If you believe that backend development has fewer choices involved, then I assume that you sir have limited experience.
Anyway only recently has the community invested in improving this. Give it time, unless you believe something else can replace it before that.
I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered.
JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods.
If you recognise JS as a terribly designed language, then the last thing you would imagine doing is widening its use. But that is exactly what node.js does. You should instead isolate JS and minimise its use. So red flag - something has gone wrong here.
It also feels that many web ecosystems have an over-inflated sense of self-importance. This has led to many competing frameworks for the same tasks, that try to do everything. Things are not pythonic. There appear to be an excessive number of package managers involved. There were already plenty of package managers out there - inventing new versions of existing tech makes it harder for everyone and is usually a red flag that someone somewhere is making bad decisions.
I need to build a website soon and I’m dreading the front end. At the back end I can use range of solid and well designed languages and technologies, but at the front end I feel like I’ve got to choose the least poor of a bunch of crazy options. If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful. “Sane web dev to minimise the impact of the Web Dev CSS/JS disaster on your life” would be my favourite O’Reilly of all time.