To a large extent this is true because the javascript community is busy with the re-invention of all of computer history, only without applying all of the lessons learned.
Activity does not equate quality.
Activity does not equate quality.
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].
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.
* 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.
- Build systems
- Dependency management
- Some form of code modularity and references between modules
- Preprocessing/macros/templating
- Source to source
- DSL embedding
- Compartmentalization of state (globals bad)
- More advanced type systems
- OO-ish systems
- Forms of data flow
- Message passing
- Functional style (including limiting mutability)
- Forms of control flow
- Frameworks providing more magic
- Calls for less magic and more explicit control flow
- Exception handling good
- Explicit errors better
- Event loops
...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.
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.
That seems like a bit of a reach.
The JS community at large isn't reinventing the wheel, just iterating on a wheel as it moves, if that makes sense.