Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Well that makes sense (Score 0) 181

Cherrypicking applies in contexts where the momentum is against the data being cited. Nobody can deny the momentum is JS' side being the most popular programming language. Citing data that implies that it is not yet the case is an example of cherrypicking. Citing data that implies that it is, not so much.

Comment Re:Well that makes sense (Score 1) 181

Dunno man, this feels kinda like the climate change "debate" to me. Sure you can cherrypick data sets that show JS isn't quite there yet, but there seems to be a growing consensus that JS has already hit that tipping point. And if miraculously everyone is wrong about that, it won't be long before even the most stubborn surveys have to admit JS hit that tipping point. The momentum is rather obvious.

Comment Re: Well that makes sense (Score 1) 181

That seems unlikely. I'm not aware of any efforts to get something other than JS writing directly to the DOM via wasm. That would be a loooooot of DOM APIs that would have to be replicated in Java or whatever.

Besides, by the time something other than JS has full DOM access, ES7, ES8, ESwhatever will be out and JS will have slowly evolved into a usable language, eroding the appeal of switching to something less popular because the aesthetic differences won't be so vast anymore.

Comment Re: Well that makes sense (Score 1) 181

The official WebAssembly FAQ throws shade at that attitude.

Is WebAssembly trying to replace JavaScript?


It goes on to say that WebAssembly is meant to encourage hybrid stacks.

It's much more likely the end result will be an ecosystem similar to Node.js, where some stuff is in JS, and other stuff is in native node modules.

Comment Re:Well that makes sense (Score 2) 181

It's a lot of unnecessary process and meetings. Daily standups, biweekly planning meetings, retrospectives, endless backlog grooming sessions etc. I've been at companies that burn 10-20% of the team's time each "sprint" in unnecessary meetings to discuss work rather than actually doing work.

The meetings impose heavy burdens on anyone who doesn't want to be interrupted at that time. A typical 10am standup meeting is too early for night owls and too late for parents who drop their kids off to school at 7am, as there's a useless 3 hours between school and standup where you can't get anything done because there's a meeting soon. Scrum amps up context switching which prevents people from getting into the zone. Having lots of meetings and interruptions shreds your day to bits.

Then there are the Scrum-specific tools. Rather than using modern project management tools that get out of your way like GitHub or GitLab, you've got regressive, redundant nonsense like Rally or Pivotal Tracker being thrown around. All so you can play planning poker in the cloud. Shoot me now.

Defenders of Scrum tend to use no true Scotsman arguments. "Oh that wasn't Scrum." Or "that was Scrum being done badly." And so forth. Meanwhile the number of companies and teams doing it "correctly" seems to be few and far between. Perhaps because "correctly" is such a fuzzy thing to define. Means different things to different people. Seems to me where it "works," teams are successful in spite of Scrum, not because of it.

Basically it's popularly understood that Scrum basically exists to micromanage the shit out of dev teams. The managers who like it are the shoulder tap types whose management style is straight out of 1950. Marshall McLuhan is rolling in his grave.

Comment Re:Well that makes sense (Score 1) 181

Hardly a lingua franca

It's the world's most popular programming language, so yeah, it's a lingua franca.

If a decent alternative to JS were suddenly to be supported by all the major browsers, the rush to get away from it would be immense.

No doubt. But I'm not gonna wait around for that. Gonna use the lingua franca in the mean time.

Comment Well that makes sense (Score 5, Insightful) 181

Because of course one of the people involved in creating one of the worst management fads ever would also join the JavaScript hate train.

"The Pragmatic Programmer." Hardly. Real pragmatism is recognizing that popular languages are often the best tool for the job, no mater how aesthetically distasteful they are.

Ever notice how prolific JS users rarely defend the language? Of course it's badly designed. We use it because it's pragmatic to use the lingua franca of programming.

What isn't pragmatic is using languages with declining market share because they feel aesthetically "better," or imposing horrible management fads like Agile/Scrum on your team against their will.

So I'll pass on joining this guy's fan club.

Comment Re:Wat? (Score 1) 326

Boomers are the current generation who won't shut up about kids these days being lazy.

They seem oblivious to the fact that their parents said the same thing about them.

They also seem oblivious to the fact that their kids would be doing a lot better right now if they hadn't joined the cult of supply-side economics and shredded the safety net.

Comment Re:Thick client JS frameworks are the new Flash (Score 1) 121

The argument that "my app is too complex for PE" is intuitive and popular, but the trouble here is people tend to project far more complexity on to their projects than is actually there. The vast majority of web applications are simple CRUD with some UI polish, but the authors of many such apps think they're building some crazy complex thing that's incompatible with PE. Rarely is that ever the case. I worked on some of the most complex web applications ever written in Silicon Valley and I can say from personal experience the majority of them didn't need a thick client JS framework. The ones that were using them would've been better codebases if they were vanilla JS + a collection of small single purpose modules. Almost all single page apps can and should be built with PE and very few wouldn't benefit from it. There are exceptions, but they're very, very rare.

Comment Thick client JS frameworks are the new Flash (Score 1) 121

I've been aghast at the broad adoption of thick client JS frameworks on the open web and a growing open hostility towards progressive enhancement, as if it's somehow not possible to build a single page app without totally breaking everything that makes the web a great platform.

There is a reasonable argument to be made that the vast majority of websites should not be using one of these, as the majority of these frameworks are incompatible with progressive enhancement and progressive enhancement is still the best way to build most sites. I firmly believe vanilla JS should be everyone's default. There are exceptions, but those exceptions are very narrowly tailored. I think this article which outlines those exceptions should be required reading for every web developer.

It seems like a lot of people these days don't realize you can build single page apps using progressive enhancement. And when you do, they perform better and are more fault tolerant while avoiding an unnecessary hard JS dependency. This whole stereotype you hear from people about single page apps being the future and progressive enhancement being the past is the most annoying false dichotomy ever. You can do both so long as you consider choices other than big, largely badly designed frameworks. It seems like most people who use Angular just want to make websites that don't reload the page when you click links. Maybe consider using a client-side router library instead of a giant monoframework. Way less code that has to be dumped on the user.

I'm not saying it isn't possible to use the big monoframeworks responsibly. The article above outlines good use cases for them. If you're building a client-only Electron app for instance, then go nuts with React or whatever if you like it. But seeing people design regular websites on the open web that are mostly just text, forms, and images using things like Angular and React is the biggest, most depressingly popular cargo cult antipattern we've seen since the days of Flash sites.

Slashdot Top Deals

If you think the system is working, ask someone who's waiting for a prompt.