I didn't realize Mozilla was doing this. It breaks my heart. I don't really know what to think when even browser developers aren't safe from integrating the JS libs-of-the-moment into their debuggers.
At this point, I guess there's nothing left to do but accept our new JavaScript overlords. I was already forcing myself to accept Node.js and now it'll have to be that list of 7 other trendy things ("React, Redux, Immutable, Mocha, Enzyme, Webpack, Yarn").
This is definitely not the computing future I hoped for, but it's the one we have.
React has been around for 4 years, and - along with Angular - has been a well known "obvious" choice for building JS UIs for a reasonable period of time. At least in the "mainstream".
Love for Angular seems to be dwindling slightly, and VueJS is something of a rising "new kid” on the block here, though both are happening very very slowly (if at all) and React remains a strong choice.
My point here is, while I definitely bemoan the "JS lib-of-the-moment" fatigue, I think this largely applies to the millions of ancillary libraries. The range of major mainstream choices for base frameworks/&c. it's pretty small, well established, and very comparable to other language communities.
If the objection is to JS the language, that's maybe fair game for the likes of Electron or Cordova but for an inbuilt integrated tool for debugging JS in an app with an existing JS runtime it seems the obvious choice, no?
I think that's kind of the point. Angular was not only the choice just a few years ago, it is still a relatively new technology. It was just as obvious a few years ago as react is today.
I don't know if Angular is really dwindling that much; if so, it's at least doing so slowly.
Even so, in terms of solid base frameworks, I think the rate of change is both reasonable, and comparable to other language ecosystems. The first major generation in the JS world was Mootools/Prototype/jQuery which started with a lot of churn, settled, and jQuery emerged as somewhat defacto. In between, we've had a minor mini-generation with a bit of Backbone, Ember and Meteor stuff happening, before this world of Angular/React/Vue. These are all changes that I think have taken significant time to come about - they're really not too difficult to follow. The massive daily churn of smaller add-on libs is more painful but easily avoided tbh.
Similar things have happened elsewhere - PHP's ZF, Symfony, Laravel, ?, Ruby's Rails, Sinatra, Java's many many complex evolutions, &c. &c.
Building software in an excessively timeless way is not always a good idea. You build a major bridge once a century or more. You release software every couple of months, if not more often. You need speed and ease of change more.
As much as it pains me to say so, we brought it on ourselves. Noone made any GUI toolkit that works as painlessly as React. I despise Electron and my hatred for JS can be seen throughout my comments. Yet I am forced to admit that there is no other UI library that is as good and cross-platform. What alternatives do you have?
Dear imgui ? I want something that looks good and is themeable in a reasonable way. Out of the list, it's probably the best.
Qt ? If I could build a project without bringing along all of Qmake and the shitty signal hack it's based on, maybe.
Qt-QML ? Hey, it's actually pretty close to React... If not for the crippling limitations of it.
GTK ? Yeah, I love passing GObjects around and looking like crap on every platform.
XAML ? Windows only.
Win32? Windows mostly.
wxWidgets ? Tkinter? Swing ? JavaFX ? Tcl/Tk ? They all have their massive problems.
What matters to users is that their software looks good. I'm guilty of that too, even as a developer, I'm willing to use an app that takes a small performance hit provided it looks good.
Yes, the DOM sucks. Yes, React + Redux is reimplementing the Windows message passing loop, something that is 30 years old, reinventing the wheel, but now on the web. Yes, the entire stack is a terrible hack, and we're reinventing CSS through things such as styled-components. Yes, React needs to implement a shadow DOM and diff-rendering to have something that performs well enough. But it benefits from the amazing theming abilities of the browser. Layout with flex is no longer completely batshit insane (only slightly mad). And, eventually, software like Servo will make rendering faster, leaving only the issue of the DOM being slow to update.
Maybe if we native developers stopped, took a good look at what developers wanted and needed, maybe this wouldn't be our situation.
Very true. The state of native UI kits is pretty dire. Especially for cross-platfom there is really no good choice out there and it seems not much development is happening.
On reading the title earlier this morning I thought "great, a few features I use probably removed but a few cool features I'll grow fond of will get added", didn't expect to feel so negative after reading the article.
From the list of JS libraries they're using alone, I'm guessing it's going to get even fatter and laggier than it already was :(
Can anyone give us an overview of lagginess vs the current generation network tab? I really don't care what's behind the UI (and really, React for this? Grmbl) or structured search, I just want a listview of requests that appears in under a second
The libraries list is a little misleading. For clarity:
React - the base JS framework
Redux - store/state management
Immutable - a library for making data immutable in JS
Mocha - a testing framework - dev only, not used at runtime
Enzyme - a testing tool complimenting mocha - dev only, not used at runtime
Webpack - a build tool for assembling/minifying the code - dev/build step only, not used at runtime (though will affect performance as it determines the structure & loading of the code files)
Yarn - a package manager! Not sure why this is even listed at all really, not very relevant in the article. Possibly the author is just a Yarn fan and wanted to include a plug - obviously dev only.
Summary: 3 are used, the rest are dev tools, not really "seen" by the end user.
> From the list of JS libraries they're using alone, I'm guessing it's going to get even fatter and laggier than it already was :(
Why? Only 3 of the 'JS libraries' listed are actual run-time code (React, Redux, Immutable). And React + Immutable are typically paired together specifically for speed optimisation reasons.
> I just want a listview of requests that appears in under a second
I think calling it a listview is a little unfair, and clearly there has to be tool/library cohesion with the rest of the Firefox devtools too, which are also much more than the odd listview.
Unhappy to say I had almost the same reaction. I was sad when they did the same with the debugger - suddenly searching through files was unusably slow.
If you think having more lines of code makes something slower then you should disabled the JIT in your browser and see the amazing performance wins of javascript being interpreted with less lines of code!
I'm still missing the insight into websockets that Chrome offers. The network monitor can see websockets being made, but there is no way to see the data inside the data frames.
There are of course extensions that fix this but in my experience they are heavy and slow down the debugger.
I really hope this feature will be added soon (or has been added without me noticing it)
Chrome still isn't perfect for web sockets. They don't even allow you to see the raw content for binary web sockets and considering how prevalent they are becoming, this really puts me off using them.
Seems like the best thing to do would be to add a debugger interface that can pipe the data into Wireshark, which already has reasonable binary protocol parsing and display.
(Also, will throw out a pointer to my React/Redux links list at https://github.com/markerikson/react-redux-links if anyone wants tutorials or info on best practices for using them.)