5 ms·
We are simply going through a Cambrian explosion in the JavaScript ecosystem. Today there is huge demand for the ability to develop desktop standard applicatio
by PhilWright 11y ago
We are simply going through a Cambrian explosion in the JavaScript ecosystem.
Today there is huge demand for the ability to develop desktop standard applications inside the browser. At some point in the last few years we hit a tipping point where the potential to do this was unleashed. I am not sure exactly what the technology was that tipped us over, maybe a combination of several. Was it fast JavaScript performance, AJAX, client side frameworks or NodeJS? Whatever the cause the dam has broken.
In a few years the winners will emerge. But it is impossible to know if the current leaders are going to win or if another champion will appear tomorrow.
I intend to enjoy the ride and look forward to the improved productivity and capability of web apps that results from the chaos.
- prewett 11y agoJavaScript is the only UI environment that has gone through 10 years of solid churn. Pick any other UI environment besides HTML/CSS/Javscript and it is pretty stable. So why is the web so churny? It makes me think there is something rotten underneath.
- manyxcxi 11y agoIt also may be the people that are drawn to it. There are backend/frontend dev stereotypes for a reason. In my experience, the frontend dev teams have tended to be earlier in their careers and more likely to come from a 'non-traditional' background into tech. You're not seeing code boot camps popping up for Java and .NET developers like you are HTML/JS and Rails. It's not a knock, the younger people usually bring the enthusiasm and fresh ideas to the table- but that enthusiasm and zest hasn't been sobered with a decade of real world experience and a more analytical/engineering background and schooling.
- samcodes 11y agoThis is a really interesting point. I think another factor is that if you have a huge amount of users, you need robust server code. But front end code only has one user at a time. And it's much more tied to design, so it gets "stale" faster, so there are just very different pressures on it that make it less amenable to a traditional engineering approach. In that it might be worth trading some robustness for speed of updates.
- manyxcxi 11y agoYou bring up a good point that I missed in my first comment. The design. God damned designers! I kid- I worked at an agency for years and the hardest part was always getting the build to match the design when they were still laying out the design pixel perfect in Photoshop and Illustrator as if we were doing print work or doing fixed width pages. I've seen some designs that were, frankly, beautiful but it took no more than 5 seconds to highlight the 30 areas that were going to cause massive budget overruns trying to make look exactly right, have decent performance, and work in eleventybillion browsers. I've certainly appreciated what interesting designers can bring to the table, but we're still a ways away from a lot of traditional designers having a good handle of what their design really means when we're building it. Kind of like the contractor who bitches about the architect for designing an angle that is impossible to hammer into. Sometimes there is a disconnect.
- mattmanser 11y agoI would have agreed with this, but I've just been exposed to what's happening in the new .Net core and asp.net 5. It's a clusterfuck of the sublime and the downright stupid. Any new trendy idea has been rammed in to the new ASP.Net with startlingly high churn for a MS product and bizarre choices like forcing you to program in particular (often undesirable overkill) ways. So the JS churn model has begun to infect another language as a model to be emulated rather than reviled.
- manyxcxi 11y agoYeah, that's a good point. In fairness to MSFT, with Roslyn and really trying to make the .NET stack able to run on non-Windows boxes you would think there would have to be a few hiccups along the way. I feel like the JS scene is facing this level of upheaval every 9-12 months right now.
- mattmanser 11y agoThat doesn't mean they have to re-architecture their MVC to force you to use DI all over the place whether you want to or not. Or to start running command windows when you used to have a working IDE. Hell, even the new config loading is an utter pain in the ass compared to simply just accessing a static object available from everywhere. There are great bits, don't get me wrong, but I do wonder how much of their larger audience are actually going to enjoy this. It presently feels like a massive step back for very little gain. It just feels, looks and smells like the old JavaFactoryHammerWidgetFactoryFactory of the days of old, i.e. over-engineering which means you can't get any actual functionality done as there's more scaffolding than functional code. You end up drowning in utterly useless code that doesn't really do anything.
- nissimk 11y agoI think it is a combination of what you are saying. The reason there is so much variation is because the userbase is extremely wide in the javascript world. If you want to deliver your application to the web, you are going to have javascript in there somewhere, and pretty much everybody needs to have their applications on the web these days. So you have developers from a native mindset, an embedded mindset, a backend / data oriented mindset. Nodejs is great for rapid development of http based api's, so you get a lot of backend api perspectives, and of course, as you mentioned, there is the whole html5 / javascript frontend crowd. Then you have the situation where javascript is both functional and object oriented, so you get toolmakers who focus on one of those or the other more. Now with compile to javascript being more widely accepted, you get a lot of developers from static typed languages insisting that this missing feature is the panacea which will solve all of the problems. The wide variety of perspectives within the javascript developer community is what sparks the wide variety of new tools and techniques. And popularity of these tools and techniques is definitely based on trends and fads.
- cm2187 11y agoWhat's rotten is probably raw javascript. The fact that pretty much no one uses raw javascript and have to rely on all these libraries to abstract the uglyness and inconsistencies isn't a vote of confidence. Javascript is popular by necessity not by its own merits. All new and growing platforms (iOS, Android) have been locked down into proprietary languages / libraries, and javascript is the only language neither Apple or Google could block, just because they were forced to preserve compatibility with the web, not because it was a terrific language. We pretend to like it just because it's the only meal we get to eat if we don't want to starve.
- Yaggo 11y agoOh, language is rotten if developers use libraries and abstractions? When was last time you wrote an application in "raw" Python/C/Swift/Erlang? (Whatever "raw" is supposed to refer to, is standard lib allowed?) No language is perfect, and javascript is actually pretty nice one, also considering that there are multiple independent runtime implementations for almost every platform, I would say javascript as an ecosystem works surprisingly well. Javascript only has problem if you think diversity is problem. It's totally expected outcome that people (wildly) try things when the language is well designed, i.e. relatively small but flexible core.
- cableshaft 11y agoI write applications in raw Python all the time. True, they're text-only (or text as graphics) terminal applications, but it's surprisingly versatile and very pleasant to code in, so much so that I've been trying to make more and more of my ideas console friendly.
- Udik 11y agoSo raw C# is rotten too: Visual Studio, Resharper, MVC, nHibernate, IoC containers, nuget, mocking and testing frameworks, etc. Not to mention the myriad inconsistencies of the language: static typed, with anonymous objects, dynamic objects, expando objects, extension methods, various different ways of creating delegates, keywords that mean completely different things depending on the context... give me the simplicity and logic of JavaScript any time.
- mkozlows 11y agoThat's not even true, it's just that nobody pays attention to other things. Look at Windows desktop apps. If you wanted to make a native Windows desktop line of business app in 2000, you would use Win32 APIs. In 2002 or so, you were supposed to use WinForms. And then it was supposed to be WPF. And then Silverlight. And then WinRT.
- klibertp 11y agoDon't forget about MFC somewhere between WinAPI and WinForms :) And it's worth noting that in this case we're talking about a single entity - Microsoft - pushing these changes. In the JS-land, there are many more actors, and every one of them tries to be innovative: this has to result in a lot of changes over relatively short time. Nothing wrong with it, too. I think that, over time, the ecosystem will converge on a couple of best solutions and that it will be of higher quality exactly because of a "chaos" we're seeing right now.
- lisivka 11y agoSomeone need to cherry pick versions of popular libraries and make stable and maintainable LTS bundle, let call it JASMIN, which should be used in places where long term support is necessary, like CentOS. Then application developers will refer to "jasmin-1.0/jquery" instead of random version jquery. Developer will know, than this version will be supported at 3 years least, with bug fixes only, so he will not worry about incompatible changes in libraries and it dependencies for next X years.
- icedchai 11y agoThe churn is simple to explain: HTML/CSS/JS was never intended for building applications. We've been trying to turn a document delivery platform into an app platform. As a result, we need all this "tooling" to fit square pegs into round holes.
- rimantas 11y ago> Today there is huge demand for the ability to develop > desktop standard applications inside the browser. Is there? Or just devs wanting to do that, for reasons unknown? I as a user could not care less about "desktop standard applications inside the browser", desktop applications work just fine.
- untog 11y agoIt's a huge boon for administration - auto updates, no install procedure, cross platform...
- cableshaft 11y ago...and difficult to pirate, a major reason so much software moved to the web. On the negative side for the consumer, the software and whatever data you committed to it will disappear if the company ever decides to stop supporting it or shuts down. Also you are pretty much forced to be online in order to use it, so if your device isn't in a wifi friendly area and/or you're trying to limit your internet usage for whatever reason (i.e. more productive with less distractions), the software is useless.
- untog 11y agoThat's actually not true with cache manifests, IndexedDB and service workers. You can make an entirely fully-offline webapp that stores data locally. This is all relatively new stuff, of course.
- cableshaft 11y agoThat's true, although it tends to hide the data in some '/users/documents/appdata/local/roaming/cache' craziness rather than true i/o. I still can't load a preferences file off my ~/crazy_named_personal_folder, update it, and then save to the same location, at least as far as I know (I've only played around with local storage briefly). And that's a lot easier to lose and a lot less portable than all the stuff I care about in a single folder that I sync with an external hard drive, a usb drive, and dropbox, automatically. But it's still better than nothing, and I'm glad it's an option now.