Ask HN: Why is everything in JavaScript changing so fast?
Change and variety of options is a good thing, but in js the rate of change in methodologies, frameworks, libraries is so much high. For example angular 2 is not compatible with angular 1, so before you even learn a framework its API is different and when you finally learn it, probably is considered outdated.
Why is this happening especially in js?
302 comments
[ 0.21 ms ] story [ 1039 ms ] threadIf you want your code to work in the future, you are ultimately responsible for your code and all of its dependencies. The less code, the better. (Although some libraries have earned a track record of dependability, projects and companies may be abandoned and you may need to pick up the slack)
Every framework has a "sponsor". Every strong "sponsor" either has a vested interest in the web, or, a vested interest in some other platform with which the web competes.
The importance and power of the web are obvious. So, it is a dance. "Embrace, extend and extinguish". And, hop, here we go again.
With HTML5, CSS3 and ES6 being released, and seeing wide adoption, the web-application layer and APIs suddenly have access to a magnitude more functionality, and we're essentially in the early romantic period where we're pushing these new features to the max, and figuring out what sticks.
Over the next year, we'll settle at the maxima of efficiency and usefulness with the web framework. Despite some negative voices, IMO these are very exciting times for the web :)
However, moving fast does percolate down from the top. Look at Node.js and how often they release new versions.
Performance? That is a good reason, but again if you actually pay attention to defining (and testing) your APIs that is in most cases a solved problem - use a fast language for performance sensitive endpoints.
Team's lack of knowledge? That's the only real argument. But that works both ways. If you have a team of experienced Node/JS developers then it would be foolish to implement your backend in Java (given no other constraints).
Regarding performance, your solution means that in order to understand your site, you need to understand another language and javascript now. At which point, why swap between languages and mindsets when the other language can already do everything javascript does, plus gives you a performance edge?
With the knowledge pool, it really does depend on the sort of application you're making, and how much code is reused and where. If your application has a web-based, and desktop/mobile app, you may very well be better off coding the entire thing in a language more amenable to native compilation.
Knowledge-wise, and long-term developer comfort-wise, Javascript's fast churn is problematic. When big packages' idea of long-term support is three years or less, you're going to be spending a lot of engineering time rewriting your code just to keep things from collapsing into a bug-ridden insecure heap. Examples like Angular.JS show just how brittle the javascript environment is, and how difficult it's going to be to keep a site maintained.
Regarding performance, why don't we write our web applications in C++, Rust or Go?
There is a lot of churn in front-end frameworks, but for back-end frameworks the ecosystem is more stable (I like ExpressJS, which is like the Rails for NodeJS).
If you factor your architecture correctly (e.g. separate your domain model from your views), you can also switch a bit easier between front-end frameworks.
A) Types are low level
B) C++ and C are the only competition to JavaScript
C) Not having to worry about types makes you faster or in any way better
A) is simply refuted by looking at java or SQL. SQL is a very high-level language compared to other stuff, yet it's heavily typed simply to ensure that data is either valid or the query fails (SQL Injection is still valid data in this case)
B) Take a look at Go. It's blazing fast. It beats Node.js in all benchmarks but Regex matching -> https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
Furthermore, Go is statically linked which means deploying to production is a simple scp operation to drop the binary.
Lastly, Go is opinionated on how you write programs, you will write programs that are scalable simply because of how simple goroutines are, using channels you can utilize asynchronous execution as you would in node.js but also utilize all available cores without having to think about threads or synchronization. Just pipe data through the channel!
C) Is a red herring, depending on who you ask it's either opinion or static typing being "better". http://danluu.com/empirical-pl/
Some studies indicate that it does not matter, some indicate faster development but more bugs for no types and others indicate less bugs and slightly longer development for types.
IMO Types are good. I want to worry about the types because when I receive user input I can be sure that once parsed it's 100% an int or a float or it fits in a certain struct. For the same reason I think relational databases are better than document stores, they ensure that my data is valid.
I don't have to write as much validation logic. It is sufficient to know that my function has been passed an int-type, I don't have to check if it's nil or a string.
I mostly agree with what you're saying, but note having a channel doesn't mean one stops worrying about synchronization. If two goroutines both started waiting for data from a channel they'd be deadlocked.
Which means well-designed services will remain available even if only with degraded performance.
If all go routines are deadlocked, the runtime will terminate the service.
It's a kind of graceful and somewhat safe degradation.
My problem with Go and other languages is that you have to be verbose like str = string = "string"; Where the compiler could probably figure out it's a string because of the quotes. And use a default numeric type when dealing with numbers. A compiled language also has the advantage that the compiler can thoroughly analyze the program, optimize and chose the optimal types if they are not explicitly set. My biggest issue though is the inferior module system compared to NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals.
I'm aware that an imperative low level language that can talk directly to the hardware will beat NodeJS and JavaScript in performance. But for the most part I'm willing to sacrifice that for increased productivity and simplicity. What do you think about languages that compile to JavaScript ? And do you think adding types to JavaScript would make it more simple ?
Which completely misses the point, this is called a file system btw, but a SQL Databases is designed from the ground up to have a validation schema.
You simply cannot put data in a SQL database that is not conform to the schema on which the table is defined. You can't simply put a string into an int column but this also means that any data you may read from this column will always be an int no matter what.
It means that if your transaction completes, including large scale database upgrades, at no point where types violated and you can be sure that all data is valid (or deleted because you forgot the WHERE clause)
>In ES6 you can now go very low level and deal with raw bit buffers.
I doubt you can write to registers and manipulate memory allocation, that is actually low level.
Manipulating bits is something every turing machine emulator can do.
>My problem with Go and other languages is that you have to be verbose like str = string = "string";
Which shows me that you haven't bothered to actually look into any statically typed language because I know of no common language that uses this syntax.
Go actually infers the type if possible, you simply write `str := "string"` or `var str = "string"` and go will use the correct type.
You can do this even with complex objects no problem. You only need to define the type if it's non-obvious, like you want to use an interface but the assignment uses the raw type, but this is something now compiler can do (it would be guess work)
Furthermore, there is no sacrifice in productivity, actually the opposite.
You don't have to wonder if the parameters you receive will have the correct type. If your function signature is `func (int) int` you can only ever receive an integer and you can only ever return an integer.
>NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals.
Go actually has a very neat module system. It's rather simple; all uppercase fields and funcs are exported, everything else is private.
The architecture of the standard library in Go and the language itself discourage globals and encourage default global states which can be exchanged for user defined states seamlessly.
Check out logrus or any of the popular logging frameworks in go. You can either use the default logger which is globally exposed or you use a custom one and pass the variable.
>I'm willing to sacrifice that for increased productivity and simplicity.
If simplicity and productivity is your goal you should use one of the LISP variants like ClojureScript. Nothing beats a language which you can program to be more efficient for you.
And you probably should check out some Go code too, it's easy to understand even without knowledge of the language as long as you know some basic CS101 stuff.
Types keep things (except for database column names or JSON import...) from blowing up the very first time you try to run it, rather than stopping the compile. That's useful, as far as it goes. (as long as it saves me more time not fixing a typo and rerunning than it does generating stupid cluttered code)
We have bigger problems (not that JS really addresses them, either).
Mutable data, cyclic update graphs and temporal coupling. (at least JS makes it easier to do FP type programming and to freeze objects to force immutability if you need to). This is a paradigm change we probably won't see until after most of us raised in the C/Algol era are dead, sadly.
Pet peeve: infix operators, and precedence rules. I have seen this bite badly in subtle ways, but it's a sacred cow of computing that you MUST have algebraic expressions. Lisp had it right - parens first, now you are trained.
Now that we have effective garbage collection, can we please STOP writing (thinking) in Algol/Simula 67 dressed up with curly braces??? (which really isn't that much higher level than COBOL/CICS, especially when you look at most Java dreck)
If the compiler can safely infer a type, it should do it, that's a no-brainer, modern compilers are very capable of doing just that. This is why I like languages like Rust or Go.
For FP to some extend, I imagine Rust would be nice since mutability is opt-in rather than opt-out.
Cyclic Graphs are always complicated, they're hard, some languages just do the hard part easier while others just gnaw their teeth out.
Also agreed on LISP, LISP is probably the only good language ever, it becomes what you need it to be, if you want it's purely functional and in the next line it's object oriented.
Modern Compilers will probably coerce languages into a superposition of types, tho there will still be two sides to it, some people will always prefer explicit (as in: type is forced and checked) typing and some will prefer implicit (as in: type is fluid) typing.
If you can make type inference scale, then I would be all for it. If I'm restricted to a small LoC count, might as well use a dynamic language.
Static typing is a scalable tool. It lets me avoid an entire category of bugs and unit tests. It make refactors easier as I just have to change my thing and then fix all of the obvious compile errors once. It helps me define parts of API contracts in code vs documentation and unit testing. And when a project gets large, the automated nature of static typing helps a lot!
FWIW, I mentioned that I think even the built it infix operators are a bad idea, rather than functions, such as variadic add(...), multiply(...), or(...), and(...). (subtract() and divide() really should only have 2 arguments, and not() just one)
The code is pretty much identical between Ruby, Python, and Javascript once you have a yield/await abstraction in the latter.
I must have missed the memo that proved that Java / C# / C++ / Simula 67 are the one true path to productivity.
Async I/O is clumsy on the server side, though.
Then next, a hair-brained XML configuration scheme (with reflection) will be used to work around the inevitable deficiencies, which an IDE plug-in may or may not parse accurately.
Tragedy ensues. (Or hilarity, if I get to stand back while somebody else has to support the monster)
YMMV.
In Javascript you're not ensured to have an error, your program might continue working based on wrong data because some type has been randomly converted to a float.
In Go or C# you'd get an overflow error if the type is an int or you know it's a float and you get inaccuracy, if you need the accuracy you use a decimal type which will also ensure that any result is always of it's type.
Typed languages mean I cannot loose data accuracy without explicitly doing so. I have to tell Go that I want this uint64 as uint8 otherwise it's an error.
https://github.com/airbnb/hypernova
http://thenewstack.io/netflix-uses-node-js-power-user-interf...
JS used to be a horrible ecosystem where different browsers behaved differently, the language itself had various pitfalls and most code was written in classical script kiddie style. This has been changing for the better for a long time in small steps, but frankly something has always sucked, warranting the next evolution.
The second point is politics: JS is huge these days, and there's still a lot of room for improvement. Everyone wants to be the company behind the de facto standard library for web apps.
This is appropriate because websites and web apps are more complicated than ever before, and face the same challenges that traditional enterprise software faces: large codebases that stay around for a long time and need to be maintained and refactored, integration with various APIs, asynchronous communication, separation of concerns, separation of model and view, business logic, test coverage, development of different parts of the application by different parts of the engineering team, etc.
At some point, the benefits a framework provides outweigh the time it takes to adopt and learn the framework. A framework provides an overall way of doing things that gives structure to the project and makes a lot of the challenges I mentioned easier to deal with. Frameworks significantly reduce the number of "how do I implement this feature?" questions that are bound to arise, by providing a standardized way of doing things. They make it easier for teams to collaborate, because the codebase is relatively consistent and engineers aren't constantly dealing with other team members' idiosyncratic code. (Yes, that means there is less room for individual creativity and expression, and it makes programmers interchangeable to some extent. Welcome to the world of business.)
So, why are there so many more JavaScript frameworks than Java frameworks? I suspect it has to do with the low barrier to entry of programming in JavaScript as compared to Java. I also think that dissatisfaction with whatever frameworks are current is a major driver behind the creation of new frameworks. (I suspect that a lot of the dissatisfaction with the current frameworks is misdirected and is really due to the nature of JavaScript as a language, and TypeScript is an example of an explicit reaction to that).
Another reason for the proliferation of frameworks is that the playing field keeps changing. Most recently, it has been smartphones and social media that have revolutionized the way people use the web. Before that, it was streaming video and "Web 2.0." Whatever the next big thing is, I'm sure it will inspire a new flurry of new web development frameworks.
Relatively recently the standardisation, improvement of the language itself, real origin policy, common frameworks and finally npm released whatever was holding it back. It shot out from the rubber band and it's trying to catch up in months where other languages had years to find the way. You may notice that even though a lot is changing, not much is really new. Async existed before, so did dynamic languages, so did MVC, so did immediate mode UI, so did many other things. Js is now going through all of those ideas quickly because the path is known and clear. It will slow down though. There's only so many paradigms that we know. At some point people will run out of easy ideas and will have to start slow experimentation just like all the others.
https://octoverse.github.com/
Open source JavaScript activity as measured by pull requests has doubled (!!) in the past year. It's more than the next two languages (Java and Python) combined.
Most of the top repositories on GitHub are JavaScript too: https://github.com/search?q=stars:%3E1&s=stars&type=Reposito...
Demand for JS developers is growing too, as websites become more complex, Node.js becomes more popular on the backend, and frameworks like React Native (more popular than any other iOS or Android library on github) start to pick up mobile developers.
JavaScript performance is also starting to be significantly better than the other scripting languages, e.g. https://www.quora.com/Is-JavaScript-v8-faster-than-Python . Not because of anything inherent about JavaScript, more that it's worth a lot of investment from big companies in JS performance.
Basically, it's not just the number of frameworks. Everything about JavaScript is taking off right now, and leading to a network effect where all the other aspects get boosted too. Sort of funny to have this happen twenty years after its invention.
Activity does not equate quality.
That seems like a bit of a reach.
* Do you really want to write CSS without a pre-processor?
* Do you really want to control a webpage's state without JS models in the browser?
* Do you really want to update html with individual jquery calls?
* Do you really want to write websites _without_ using jquery? Keep in mind that jquery is only 10 years old.
I'm glad that we have an open market to exchange people's ideas. Yes, a lot of it is crap, and even among the highly adopted packages there will be problems. But that's the beauty of the market-- people can vote with their feet.
This article sums up how I feel: http://mrmrs.io/writing/2015/07/27/too-many-tools/
> "Four–fifths of everybody's work must be bad. But the remnant is worth the trouble for its own sake." - Rudyard Kipling in 1890
Not him, but yes, I absolutely do. Pre-processors mainly have the effect of forcing you to have a build tool workflow, and the nice thing about web design is that you don't need stuff like that.
Well, it does, if you don't emulate the same effect with other means. But imho, needing modularity in CSS means (for most projects that are not gigantesque) that the CSS is too big anyway. It depends on what one does, specific web apps might need it. But normal web pages never.
It's reasonably "thin", but I can use variables to hold repeated style elements that get mixed in various selectors.
Why?
What I really want is the whole browser to go away.
The obvious question is: what would you replace it with? Do you want to replace it all with native apps? Or do you think that this whole internet thing is overrated?
In pretty much every respect, native apps are better for the user than web apps. The person that benefits the most from web apps is the developer.
For example, web apps are often easier to discover, easier to update, easier to manage (since you only have one version in the wild you have to handle), easier to launch (especially for first-time users), easier to use from different platforms, more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true), ...
There's pros and cons to both sides. Just framing the situation as "my side has these benefits, therefore there is no reason to consider your side" is not an honest discussion.
How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store.
> easier to update,
because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?
> easier to manage (since you only have one version in the wild you have to handle), Except when there are cache issues. Or when you have multiple servers and need to upgrade them without downtime. Not to mention all the stuff required to host your app needs to handle enough scale to load not just any potential server side data but also the entire ui, possibly every time someone loads it (opposite of the cache problem above). Must be easier though, I've never heard of any web apps being unavailable because the servers were overloaded.
> easier to launch (especially for first-time users), How is typing a or clicking a link easier than tapping/clicking an icon?
> easier to use from different platforms,
If your browser on your platform is supported. And you have the right version.
> more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true)
This is a joke, right? Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps? Pretty much no web apps use local storage exclusively. So your attack surface is not "the browser", it's the browser, the network stack, the network itself (see: ddos on Dyn, Comodo/WoSign bullshittery to name a couple from the last month alone), your server host(s), your server os/stack, your server side app logic, your server side db/storage stack.. Do I need to go on?
Because when I come across a web app in a search engine, I can click it, use it instantly, evaluate it, and decide to stay or leave, all within seconds. No checking if the app I found supports my platform, no click-through to my native app store, no download and installation process, no delay, instant feedback.
> because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?
Not sure I follow. Are you asserting that native apps are easier to update than web apps?
> If your browser on your platform is supported. And you have the right version.
The combinations are smaller than the combinations of operating systems and phones one would have to worry about.
> This is a joke, right?
Is this a good way to have a productive conversation?
> Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps?
Do you think only web apps communicate with servers?
I'm saying the processes are more robust. You either have the old app or the new one. You're never left with half of each, and you aren't beholden to random caches about whether or not you get the update.
> The combinations are smaller than the combinations of operating systems and phones one would have to worry about.
That can't possibly be true. Most platforms have more than one browser available, and with the exception of Microsoft, browsers don't have a "use x.y.z version rendering" like platform sdks.
Edit: unless you're taking the approach of: it works with this specific platform device running browser X, so it must work with all others running X. In which case, why not take the same approach to native apps?
> Do you think only web apps communicate with servers?
Where did I say that? Nowhere.
Web apps must contact servers and any remotely useful app will have all its storage server side.
In addition, web apps rely on servers to deliver the very thing the user sees and interacts with. UI spoofing has become such an issue browser vendors are reverting back to make it harder for web pages to present native looking dialogs etc.
Native apps can operate in a client server model, but a great deal of them don't need to because their use case is for local work, and even those that do, are merely transferring data over that channel. They aren't dependent on the same channel for the very interface the user sees.
Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.
I disagree. I think updating a web app is vastly more robust. You update the source, and the only possible issue you have is caching and platform compatibility (the former is a real issue, the latter is mostly alleviated by decent testing).
Updating native apps (due to the next point) is much more problematic because the number of platforms is much higher.
> Most platforms have more than one browser available
Yeah but you can't multiply the number of browsers times the number of operating systems, because Firefox on Linux and Firefox on Windows and Firefox on Android and Firefox on MacOS are (for 99% of the apps) the same target.
> Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.
Are you interested in a real discussion? Or just posturing?
I've also gotten a pretty bad taste in my mouth about some companies pushing a native app down my throat. TripAdvisor would only show me the first three reviews on a place if I was browsing via mobile, as a way to push me to download the app. And now that they're on my android they sent me a couple of spammy notifications before I disabled them. I wanted to treat TripAdvisor like a website, not like an app that has access to all phone.
Because you really don't need a native application to look up the time the local Thai place is open or if the local independent movie theater has a showing tonight. Installing two native apps to do that is burdensome on consumers and producers
It will, as a side effect, save 1G in RAM.
If a bank/credit union/etc doesn't have a native app in 2016, I doubt they have a web app that's usable on a phone either.
> A native app for each news site I read
Right, because RSS readers and aggregators aren't totally a thing.
> A native app for every social media site
Those literally exist today.
> A native app for all the map searches, directions, etc. we all use
You realise you don't need a new app for each search you want to do? I don't even understand this premise.
> Security updates? Nightmare
Right, because having half-baked web-apps with millions of user's personal data all stuck in a big fat juicy database in one spot, just waiting to be breached and spread like herpes in a brothel has worked out so fucking well.
Every major mobile platform and the two leading commercial desktop platforms have app store infrastructure which provide automatic updates of client-installed apps.
> Multi-OS support? forget about it.
Right, because no app ever has been developed cross platform, and every web app ever created works perfectly in every browser with zero effort from the developer.
> We'd all be back to a Windows monopoly.
Wat.
Edit: additionally, a number of the things you describe, i.e. news sites, aren't web-apps in the way most people think. They offer very limited if any interaction or functionality for the user except navigating to find/read other news content, and possibly leave feedback. Those sorts of things are what the web excels at, because they're essentially used for one-way content viewing.
Users also benefit. For instance, linux users can use the same web apps as windows users.
Yes. It has evolved to counter-balance those advances in hardware power, in order to provide a sub-par 2000 native desktop application experience in a 2016 browser sandbox.
>Maybe we're re-writing computer history
Maybe?
>but if that's the case then it's because we have to migrate everything to javascript and the wiser old timers want nothing to do with it.
Err, why do we "have to"?
And what's with the "old timers" / hot young JS developers dichotomy?
I wrote the phrase "wise old timers" with respect-- y'all truly have things to teach us. But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping. I suspect that "old timers" is correct maybe 80% of the time, since the complainers are probably people who have years of non-JS experience and are disappointed that the new bootcampers haven't gone through their coming-of-age programming rituals. But I have a friend who is a member of the C++ master-race, so trust me, I know that gripes about browsers & JS can come from many kinds of people.
Not much of an argument. We already have 24/7 internet connected laptops, tablets and smartphones, which is were those browsers run in the first place anyway.
Perhaps we could, and I'm going on a limp here, just cut the middleman and run on the metal?
If the problem is discoverability/installation/security etc we could focus on app stores and sandboxes (which modern OSes also have both), instead of rewriting everything on the web.
>* But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping.*
Well, you first stop someone from drowning and then you show them how to swim...
To this day, I maintain that if Microsoft hadn't neglected that essential aspect of the Windows ecosystem for decades, they would probably still dominate the personal computing industry.
Oh, you mean 'personal computing' in it's original sense, which encompasses mobile platforms as well, not just desktop computers.
Show me another way to write end-user applications that are cross platform, and then (if it existed prior to 1995, or even 2005) explain to me why your particular alternative didn't take over the world.
Heck, even standalone desktop and mobile apps are now being built with web technologies (react-native, Electron, etc.) rather than GUI frameworks like wxWidgets.
Now more and more JS abstractions are heaped upon the pile and we call it the best thing since sliced bread. No.
Yes. The only things that are worth having one for are variables and that’s not enough to add the development overhead.
> Do you really want to control a webpage's state without JS models in the browser?
I prefer to avoid controlling a webpage’s state in the browser as much as possible.
> Do you really want to update html with individual jquery calls?
No, I want to update the DOM…
> Do you really want to write websites _without_ using jquery? Keep in mind that jquery is only 10 years old.
… without jQuery, yes, because it’s designed horribly.
These practices also happen to result in a website that is actually possible to develop and view on my computer with reasonable performance, because I’m one of those users nobody cares about who can’t afford the latest MacBook.
The JS community at large isn't reinventing the wheel, just iterating on a wheel as it moves, if that makes sense.
Everyone is just trying to do the best they can with the incredibly complex stack of technologies in play today.
Really? Is it Web 4.0 now?
People are changing the stack because they don't know any better and trying to justify their salary. That's the bottom line. The rush to stay current is just bandwagon-hype.
But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum for delivering features / products / tools to users.
It's always fair to criticize so that we ask ourselves the hard questions. So, it's also worth asking ourselves if we are staring too close to the wall when we try to paint other languages as backwards and therefore bad (or at least a bad choice). Just maybe, the language feature bullet list in your head (and corresponding subtleties of implementation) isn't the thing that matters most. Maybe the thing that really matters is something not as easy to codify as a language tool chain, like human consensus.
Also, it is false association to suggest that quantity != quality is somehow particular to JavaScript. Infinite monkeys will produce infinite crap no matter what brand typewriter you give them.
(I don't really do PHP, but I have a feeling that I would find the experience closer to JavaScript from talking to colleagues and reading about it).
This is a problem we should be HAPPY to have. Having libraries doing EXACTLY what we want, that's just missing docs, is better than the alternative I've found in many other languages : no libraries, so we have to do everything ourselves.
That said, the docs on (most of) the libraries I have used are generally pretty good.
* Prototype - excellent docs (but library since overshadowed by jQuery)
* jQuery - initially the docs were hard to follow, but they seem to have gotten better
* Angular - good enough docs, and plenty of books on the larger concepts of how things fit together
* moment.js - excellent docs
* validatejs - excellent docs
* Ramdajs - generally excellent docs, but I am less familiar with some of the FP concepts used in a few cases.
The quality on some of the jQuery and Angular plugins varies a bit, admittedly.
You're implying this happened to JS because of some merit. But it didn't, it was just sheer coincidence and bad luck (for most of us at least, including users).
I believe JS came here because it actually is the best language we have had in the web. It's so easy to throw shit arround, but let's be honest with ourselves, this isn't purely out of luck.
Today, Javascript is sooo interwoven with the DOM in browsers that it is near impossible to separate them. Google planned to do this for Dart, but gave up. If they had done this and other browser vendors had followed, adding a third and forth and more languages would have been (relatively) easy, because the abstraction were in place. Then we would have seen a healthy competition.
There is asm.js. Maybe we will get a "web bytecode" at some point, but that will easily take a decade and more. The pressure is increasing, because our CPUs don't get exponentially more powerful anymore. And delivering apps via the web is still going strong.
Unfortunately there wasn't a good way for the other browsers to implement it. Or perhaps fortunately, depending on your point of view…
Dart was never going to make it, and adding 3 or 4 VMs with their own GCs is even less plausible.
2. See https://github.com/WebAssembly for progress on what asm.js showed was possible: a 2nd, initially co-expressive with asm.js, eventually more expressive, binary syntax for the Web. It's happening now, this year and probably shipping experimentally in 1Q2017.
Writing "easily take a decade" out of ignorance just says to me you didn't even bother to use google!
It's pretty much the textbook instance of a compromise between vendors of competing interests to further the common web. Despite this, it took a really, really long time -- almost ten years -- for JS to receive additional browser-implemented APIs that brought that platform's capability to what we know today and comparable to that of what we had with plugins -- and still, not every vendor supports every spec yet, making this "open web" no less subject to vendor pressures, despite being 'open' and 'neutral' [1].
[1] https://news.ycombinator.com/item?id=12259827#12259940
It is the only language we have had in the web (modulo some minor experiments). The only reason it's popular in the browser is because it's the only choice at all. The only reason it is used on the server is because some folks are familiar with it from using (overusing IMHO, but that's a different rant) it in the browser and are not familiar with the advantages of using any other language.
I've written this before, but sometimes in my most morose moment I like to imagine what the world might have been like had Brendan Eich been permitted to implement a Scheme instead. And I don't even like Scheme!
Also, I disagree that users are suffering as a result, but that is a different discussion altogether.
I'm not suggesting that the Javascript ecosystem is filled with awesome stuff, but sometimes quantity leads to quality.
https://www.amazon.com/Art-Fear-Observations-Rewards-Artmaki...
There is a parallel though: bad art is weeded out over time, the good stuff remains. In software it is quite similar, the good stuff has staying power, the bad stuff will be forgotten soon enough. The average half-life of a typical javascript framework is quite telling in this respect.
Because JavaScript was, and basically still is, the only option for client-side web development - that is to say, it was, and basically is, the only option for distributing sandboxed, instantly-updating executable code to users at any scale. Any other language requires me to convince users to download an application that runs with full privileges on their account. (For a while we also had Flash and Java, but then we realized that Flash and Java basically also imply full privileges, in practice, because their sandboxes don't work well.)
Therefore, JS got popular; therefore, people used it. This has very little to do with the quality of the language or its libraries. Note that I am not criticizing the quality any more than I'm praising it, just saying that it's irrelevant as long as it's good enough.
Basically the same thing happened with UNIX and C at a much smaller scale several decades ago, except it wasn't about client-side app development, it was about getting things to run on servers at all. UNIX isn't a fantastic OS. C isn't a fantastic language. But, in the words of Richard Gabriel's "The Rise of Worse is Better", "UNIX and C are the ultimate computer viruses."
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
JavaScript and the dynamic web the new ultimate computer viruses. But they grew much, much more quickly, and haven't had the benefit of the last forty-ish years to get decently good. UNIX and C in the middle of the UNIX wars were at least as much of a disaster.
People trying to use Javascript as a surrogate C++^H^H^H Java will be sorely disappointed.
People trying to use Javascript as something that blends Scheme and Smalltalk will be using it as its creator intended. While this won't make the extreme purists happy, for many of us, Javascript is an acceptable Lisp.
I have come to prefer Javascript to Java (or C#), but most of my coworkers still think in Java, so that's another issue :-)
And the story of JS interpreters, JITs, etc. in browsers (and not in browsers) matches the story of C compilers in the essay, just with changes in timing:
C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%-80% of what you want from an operating system and programming language. [...]
Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.
(with apologies to the Dumb and Dumber movies)
I believe that part of the reason is the ease of access to JS development. It allowed an inordinate amount of poorly trained devs to enter into the job market. Because you can quickly whip up fancy UIs and show them to unsuspecting non-techie types, you can quickly earn a reputation as a "computer whiz".
I think there were many de facto ways of doing things before this, none of which were perfect, but some of which followed better design principles.
If you look at software industries where security and stability is of utmost importance, you will not find these newer frameworks in use - nor the languages they use. I'm thinking life critical systems here.
Consider this: just because a language is easy to pick up doesn't mean it attracts "poorly trained devs". It just means it attracts more devs, because it is easier to get into it. Putting aside any value judgement of mass appeal, my experience suggests that the most important differences between a poorly-/un- trained dev and any other kind are time and practice. So, being easy to use is a much more powerful feature for a language / framework / platform than most.
Also, we should all be aspiring to use tools that enable us to quickly spin up a prototype UI that looks convincingly useful. I'm not sure why that's a knock against JS.
Also consider this: the languages / frameworks / platforms before the web, and before JS, were harder to use and relatively very discouraging to new users (this also sometimes goes for the communities associated with those languages / frameworks / platforms).
We all started from a place of ignorance as software developers, and many of us never would have left that place if it weren't for someone looking at us and seeing a computer whiz in the making.
I never said that JS was easy to use. I said it was easy to access. With JS, you don't really need an IDE, compiler, runtime etc. You need a browser, and a text editor and you can get started. It's unlike a lot of other languages in that way.
In some ways, I'd argue that languages like JavaScript are harder to use, or at least harder to use well. There is a reason that languages like Ada exist with very strong type systems. Granted, Ada is not a web development language, but I think my point still holds true since languages like TypeScript are making inroads in this arena.
I think spinning up "convincingly useful" UIs is part of the problem. First, in a lot of ways it's the wrong place to start for software design. It raises expectations and can create a contract in the minds of the client, customer, or user that this is what the software will do, and it will do it perfectly.
I'm not claiming that I (or any other programmer) started out knowing everything. But taking the time to learn, apprentice, and hone the craft of software development (the full cycle, not just writing code) is part of the game.
I think the attraction of a lot of the current web frameworks is the "whiz-bang" results you get, and it's my humble opinion that you should no more build software that way than you should a smartphone, bridge, or building. I think people need to have more respect for the software engineering field, follow best practices, and not throw out everything we've learned as each new Next Big Thing (TM) comes out.
I agree with this sentiment, with a few (rather large) caveats:
∙ Best practices yesterday may be legacy practices tomorrow.
∙ The Next Big Thing™ is usually hidden lower in the stack (in the above example it was cheaper commodity hardware and free-as-in-beer operating systems), and while it may not force throwing away everything, it can still prompt throwing away a heck of a lot.
So, yeah, there is a lot of churn in the JS ecosystem right now. It's inevitable that there will be some sort of shakeout and some projects will emerge as de-facto standards around things like declaring dependencies, build tools, etc. The same thing happens in every successful software ecosystem exploiting a new niche.
On the other hand, I loathe the spam code that checked exceptions causes (alas MS/Anders/C# gets this right, and Java got it wrong)
It's definitely frustrating to see. And it's also frustrating to see the vitriolic reactions to anyone who criticizes the current culture of the JavaScript community.
I use React and all of its associated tools and ecosystem, and while I find them productive and useful, the whole situation is a bigger mess than it needs to be. I don't think it's necessarily anyone's fault; I don't see a willful desire to ignore the hard-won computing knowledge we'e accumulated. It just seems as though the JS community's enthusiasm has, at least recently, has exceeded the rate at which good tooling can be developed.
I think that's changing, though. From what I've seen, in the past year there has been more of a push toward building mature, reliable, maintainable JS applications. I've also seen more interest in optimization. The Closure Compiler has been around for a long time, and at least in the Angular 2 community I've noticed jump in the number of people looking to use Closure and other tools like Rollup to optimize everything and deliver the smallest possible code bundle to the browser. And ES2015's statically analyzable modules go a long way toward making more optimization possible.
So I agree, things are a bit crazy. And I agree that activity does not equal quality. But there's a lot of activity, and some of it is of high quality. I can't guarantee that the high quality work that brings more of those lessons learned to the JS world will become popular, but I'm at least seeing a positive trend in that direction.
These stats prove the hype, not that it is good quality code, with good quality documentation, with a friendly and safe community, and a reliable archiving system for it's dependencies.
I have nothing against JS in particular, but there is a bit too much hype about it.
These libraries were checked into Git because it was more convenient at the time and I hadn't set up a good build system, as they were non-critical side projects.
I know I'm not the only one who has done this in the past. I'd be curious to see GitHub stats that tried to account for this.
Brendan Eich initially designed JavaScript in an infamously short time--he coded and designed the first prototype of JS in just 10 days.
It quickly became the only programming language you can use in a web browser, with multiple vendors, including Microsoft, owning mostly compatible implementations. Due to trademark disputes they couldn't even call the language standard "JavaScript," so the language standard is called "ECMAScript."
Microsoft didn't want/need JavaScript to change or grow at all. Once Internet Explorer 6 became the dominant browser on Windows, (which was and still is the dominant PC operating system,) they stopped releasing new major versions of IE for five years (2001-2006), and IE7 wasn't a very big upgrade, especially in terms of JS language features.
Mozilla unilaterally released new language features that only worked on Firefox, so nobody could use those language features in practice on the web; in many cases, new language features wouldn't even parse in IE.
In 2007, there was an attempt to build a major new JavaScript version (ECMAScript 4) with a ton of new features, (classes, a module system, optional static typing, algebraic data types) but it was scrapped due to disagreements between Mozilla and Microsoft. They wound up implementing a much more modest upgrade (ECMAScript 5) which shipped in IE9.
In all this time, there was essentially no interest in running JavaScript in command-line tools or on the server side. That changed in a big way in 2009 with Node.js. It used V8, Google's JIT engine for JS, and it was surprisingly fast.
This is when the language really started to unthaw. IE declined in dominance as Chrome rose, and the demands of server-side development started to be felt more strongly in the JS community.
ECMAScript 6 started to add back in a number of cool features, and by this time, JS developers were desperate to use them. This lead to the development of "6to5," (now called "Babel") which allowed you to write code in ES6 and "transpile" it into older JavaScript versions, so developers could experiment with new language ideas without pushing them through the standardization process.
Languange evolution kicked into high gear at that point. There are a bunch of interesting pluggable transpilers out there, including TypeScript, JSX, and Flow, and countless non-standard plugins for Babel.
And that's just the language itself! The "standard library" for JavaScript for years was just "whatever IE6 could do" and that wasn't very much. IE6 was pretty buggy as well. jQuery became popular as a library to smoothe over differences between browsers, but mostly to work around bugs in IE.
Client-side frameworks were tough to implement on IE6, not least because IE6 was just so darn slow. As newer, faster browsers came out, it became possible to trade off some performance to improve developer productivity.
And everybody has their own ideas about what those trade-offs might be like!
At the same time as IE6 started to decline in popularity, the mobile web on iPhone and Android rose in importance. Smartphones include a bunch of new sensors (GPS, orientation, camera) and new limitations (RAM, slow/unreliable network). This spurred on browser vendors to "compete with native apps," adding features to the browser platform, inviting developers to respond to these with new frameworks.
As for the JS server-side, Node.js is still a relatively young platform as these things go, and so it's not surprising to see a lot of churn in server-side libraries/frameworks, especially given how much churn the language itself is undergoing.
Node.js is also the first major platform to be born in github, which IMO encourages experimentation (and flame wars) via forking.
Node.js's standard library is designed to be small, (they call it the &quo...
Being the creator or top two contributor of a library is now worth so much more than being a small time contributor that the incentives are skewed towards everyone just making a new thing, always.
It's their way to stand out.
So why is this more prevalent in JavaScript? Front end inherently has more new comers. Long time hackers or cs grads feel less of a need to prove themselves making free software?
I think it's natural that the web programmers would understand web self promotion better than other languages. Guess who's better at Twitter? The js people! Why? They were writing the web to begin with!
I wish it would stop. Our qa engineer is writing web driver tests in JavaScript and I don't understand why! There's nothing about testing that NEEDS to be async! The python API would likely be no slower and much easier to write and debug.
Sane defaults are an important part of tech, and default async is a terrible setting. Python sync is easier, and Go routine concurrency is easier. Always on async just seems like a terrible default. For speed I'd do Go, and for all else Python.
But probably not for your qa engineer who most likely already (and possibly only) knows javascript.
One language is all we need? Who needs Assembler or C or LISP or HTML or CSS or Bash Script or Python or Perl??? WHO NEEDS THAT?
SINGLE STACK!! /s
[End] Sarcasm :-)
For example, I'm working (part time) on a relatively simple backend server for a nonprofit with a tiny budget and short deadlines. I know I can do it cheap and fast in Python, and it will work "ok". Go would be better, and I'd like to learn it, but I'm uncertain I could pull it off in time.
EDIT: Then again, it looks like I could realistically learn enough Go for this project in a weekend. Only problem is there could be data analysis, I know good libs in Python, don't know how hard that would be in Go.
It depends really, there is no single true language (except LISP) to solve all problems in the entire stack.
My main problem with LISP is that I stopped liking Python after learning it.
I'll admit im not sure.
As far as I'm concerned, jQuery & lodash are part of the "standard library". Certainly there are cases where one or the other isn't needed for a particularly application. But if you're doing anything with the DOM, or doing anything more complex than simple if/then callbacks, you're either using them or you're reimplementing them bit by bit.
Certainly jquery has some... warts... but I haven't seen any project emerge that's succeeded at being a cleaned up replacement. And jquery 3.0 looks like it's trying to forge ahead in that direction itself.
(Still hate jquery's inconsistent ajax callback signatures. sigh.)
Lodash looks nice, though, in that its partial function application mechanisms seem a bit more flexible than curry (only) - e.g. - I want to make a function with 0-arity, and bind it to an event handler, which Ramda won't do.
https://github.com/lodash/lodash/wiki/FP-Guide
If the app you're testing is messy, some of the test code will have to be injected into the browser by webdriver (so obligatory Javascript, and oblygatory async for getting the results back...) and some (hopefully most!) will run outside, in the test-runner, so JS ends to be the only sane option if you don't want to write "Python with strings of JS sprinkled around".
Also, webdriver itself is a mess with a horrible API forcefully riding another bigger mess (the browser adapters and browser itself), riding a top another mess (your app, however non-messy you imagine it to be, it's still a soup of crap running though the bowels of the browser)... so no "clean" solution here even if you're using Python.
Probably the way out of "webdriver testing hell" is to use a frontend framework with good testing support and write good front-end unit-tests: but they will obviously be Javascript :)
It's not fully polished yet, especially error reporting is a bit ugly, but it works and supports most of the WebDriver API.
https://github.com/mbrock/wd
I'm using it more for automation than testing but it could definitely be used for QA.
Haskell's version of "everything is async" works wonderfully. It's JavaScript that is bad, not the concept.
And we have async/await too now, which means async code can also look almost the same as sync code. So I would still choose JS over both Python and Go (at least for that particular use case). mypy still has long ways to go before its anywhere near TS or Flow.
In theory, python is better (mypy, pypy, async/await). In practice most libs don't use asyncio (in node everything does and can be auto-promisified), can't run on pypy (in node everything runs with the fast JIT optimizing things) and the typechecker is not mature enough to express most things (unlike TS/Flow).
Python (and its type system) + Go routines
Where can I find that!?
Perl has Larry Wall. Python has Guido van Rossum. PHP had Rasmus Lerdorf and later Andi Gutmans and Zeev Suraski (Zend). Ruby has Yukihiro Matsumoto, and Rails has David Heinemeier Hansson. JavaScript came from Brendan Eich, but it was like a work for hire, wasn't it? Microsoft and Netscape just kind of ran with it.
Then I guess it did have a shepherd, the W3, and all the browsers followed its standard, except the one that had 90% of the market. At long last, in the past few years, market share has passed to companies that are much more willing to follow open standards.
But at the same time, the user base is huge, a churning mass of millions of programmers of every level of ability, and each one of them can now publish their framework on Github. Plus there are several large web companies that are competing with each other.
Thankfully at least the language itself has a single standards track. Cross-browser agreement isn't perfect, but it's much better than it used to be. It's just that we don't have a standard library, like Perl's CPAN. Instead we have NPM.
I wasn't paying enough attention when Perl and these other languages developed, so I don't know for sure why they're different, or even if they were that different at this stage. Even they have their different web frameworks to this day.
https://developer.mozilla.org/en-US/docs/Web/API
The IE stagnation came later, after IE4 which was innovative (because Microsoft wanted to embrace/extend/extinguish Netscape and the Web).
Almost everything we added to JS at Mozilla made its way into standards. Examples range from __proto__ to generators in ES6.
Compare it to say, creating a new operating system. Sure the world could benefit from a better OS, so why not make one? The perceived benefit is small (why do this when Linux exists) and the cost is large (it's hard and you need a lot of knowledge).
Also a lot of half baked ideas. The number of js writers is huge but on average very inexperienced compared to other languages.
That's unusual. These frameworks extend the language. Angular's developers reasoned that anyone smart enough to figure out Angular 1 will be able to migrate their code to Angular 2. It's looking more like C++ and less like CSS. :)
Take a look at Meteor's code sometime. It does things I never expected possible with JavaScript.
There's nothing quite like this anywhere else in tech, as most platforms are dominated by a single vendor. Imagine what Windows development would be like if, in addition to the need for backwards compatibility, there were three or four competing vendors of Windows, each with different feature sets and bugs.
Second, tools and libraries can overcome many of these problems, but these fixes come with costs, including library maintenance, cognitive overhead, security risks, complex build and deployment processes, and retraining and hiring issues. Because JavaScript is used across many industries and teams of all sizes, what is perfect for one may be completely inappropriate for another. Many projects, like GWT, meet the needs of the environments in which they were designed, while being so much a product of those environments that they become anti-productive elsewhere. So we have a very diverse set of tools on top of a very messy and relatively old set of underlying technologies.
Finally, many new programmers come into this incredibly diverse, sometimes frustrating, environment every year. It is an environment that encourages open-source contribution. It's no surprise that many new tools and libraries are released every year, and some of them gain adoption.
In comparison, java, PHP have undergone some more than welcome mutations in terms of syntax clarity. Evolution in JS is made by adding features in frameworks, not in the core definition of the language.
You could see JS as the assembly language of the browser and all the frameworks as some C/fortran/C# that translates into JS.
The problem is the web would look definitively balkanized/ghettoed between old and new computers if you made a non backward compatible change of JS ...
JS is the most ducked taped language of the landscape of computers. And it is leaking memory, performance, abstraction from everywhere.
That's not the problem, angular 1 and angular 2 are 2 completely different frameworks that share the name and the team only. The team wanted to piggyback on the fame of the first version, but they share absolutely nothing conceptually. and contrary to what the Angular team says there is no "upgrade path", you need to learn the stuff from scratch once again.
The problem is, and the Angular team will find out very soon, "second systems" unless they provide huge advantages over the first version, are always a failure.
In my opinion, we need to realize that webapps are not documents, and document-oriented HTML is the wrong tool. I don't think things will get better until we start looking at webapps as essentially drawing on the screen, like native UI APIs. I think we need a standardized virtual machine, like a lightweight JVM (or, better, a heavyweight Lua), which would allow people to use whatever language they prefer, as long as it can compile onto the instruction set. Static-type people can use a statically-typed language, and dynamic types can use dynamically-typed languages. Make an instruction set that maps well onto native CPU instructions, and provide well-thought out input and drawing primitives. We essentially need a PostScript for apps.
To be fair, a lot of languages compile to Javascript. Do we really need a second standard?
This sounds like a cool idea! What primitives would you suggest?
Security is doable because BrowserVM does not need to do everything. It isn't generable purpose like the JVM, it is an embedded VM like Lua. Lua has great security, as far as I am aware. I expect that having a secure VM is no more difficult than having a secure ECMAScript implementation.
I think we want low-level execution primitives (i.e. assembly), which pretty much forces a VM, because it gives people flexibility to use whatever language they want. However, even the minimum of keeping JavaScript and having the page be a large canvas with (fast) drawing primitives would sufficient. Writing windowing systems and UI toolkits is a solved problem. I think the browser should, at minimum, provide primitives for drawing widgets, so that webapps can take advantage of OS-native widgets. A well-designed toolkit, though, would be handy. And here we have a number of examples. Qt is very well-designed and a pleasure to use. Cocoa is a little clunky, but effective. Even Java/Swing was fine (aside from horrid aesthetics). We know that Microsoft-style MFC is a bad idea, the Win32 callback idea is clunky, and Android is a mess. In particular, a constraints-style system seems to be clunky. It was clunky in Motif, clunky in Android, and even Apple's version doesn't seem all that great. Constraints seems to suffer from the same problem of HTML: describing the system is clunkier than just telling the system what to do. Hence, Qt and Swing's layouts are a lot easier to reason about.
Against this point: Few languages are used for what they were designed for. Java was designed as a control language for "smart" TVs. PHP was designed for making personal homepages a little bit reactive. JS was designed for making client side pages dynamic.
And now all three are being used as server software.
I think it based on two factors:
1. the size of the community, JavaScript popularity is huge, it's probably the biggest programming community in the world, even the not so popular frameworks have a bigger community then the biggest frameworks in other popular languages (as a not at all accurate measurement, see vue.js and Python's django github stars/followers).
If you look at js frameworks/methodologies/libraries compared to the sum of the other languages' frameworks then the pace of change in Javascript compared to how many people use it is not as bad.
I had a similar experience with Java when it was the king of the web frameworks - JSP, JSX, JSF, Spring MVC, Struts, Stripe, Wicket and a dozen others.
Java was big enough to contain all of these frameworks, and it was big enough for people to support new ideas rather then iterate on existing ones.
I'm not familiar with C/C++ enough, but I think it has a similar amount of change to Java (which is somewhat less the JS)
2. the other big factor is how decentralized it is - JS is extremely decentralized, there are tons of big organizations contributing to it's advancement, to frameworks even building their own compilers (all the browsers).
Java is very similar in this regard, even in their governing model (a collection of companies that decide on standards together, though Java has drifted from that model with Oracle's lead lately).
C# is the opposite, it's one of the biggest languages but doesn't have a lot of change in it - everything is dictated by the central authority (Microsoft) and competing frameworks that don't get popular enough.
There are other factors of course, but I think most of those can be seen in other languages with less change, and are less relevant overall.
It's always on. Anyone from anywhere can interact with what you create instantly. What else is like that ?