The Fall Of Perl, The Web's Most Promising Language - <AUTHOR> http://www.fastcolabs.com/3026446/the-fall-of-perl-the-webs-most-promising-language <comment><USER3> _> I first heard of Perl when I was in middle school in the early 2000s._

Welp, now I officially feel old. Thanks!

In seriousness, though, this is not a very informative article. It essentially boils down to "I learned a little Perl after college, but didn't like the syntax. Then I went to grad school and found that everyone there was using Python, so I switched to that instead. Also, where's Perl 6 amirite lol."

Which is fine, as far as it goes, but it tells you more about the author's career path than it does about either language. And by doing so, it leaves out important elements of the story. Writing an article about "the fall of Perl" that only incidentally mentions PHP, for instance, is a _big_ omission. Insofar as Perl has fallen, what it fell from is the position of leading language for building Web applications. PHP is what pushed it out of that position, not Python or Ruby. If you want to write an article about the fall of Perl you have to explain how that happened and why, but this article attempts neither.

I think the root of the problem is that the author is incorrectly generalizing from his own experiences. He mentions working in scientific computing these days; if you work in that field, and entered the workforce within the last decade, I can totally understand how it might look like The Story Of Programming Languages goes "once there was Perl, now there is Python, The End." But step outside that niche or that time window, and things look very different.

<comment><USER4> I disagree. A long list of the things that replaced Perl in various applications obscures things rather than revealing the basic trend.

The overall trend is Perl died everywhere.

I personally think Perl's death was proper.

During Perl's upswing, it's various absurdities were all touted as virtues. The weird symbols and the ability to do amazing things with a single line were both proof that Perl was the language for the people who knew more than us. At the certain point, the emperor's cloth just faded and people wanted languages to accomplish things rather than to prove they were smart.

Perl has positives, Perl's weirdnesses have positives. But once it lost it's cachet, none of the _tradeoffs_ between obscurity and power look good. And yeah, other powerful interpreted languages arose. But which still doesn't matter which one won because once the "magic", the reality distortion field, was gone, every other good interpreted language looked better.

<comment><USER5> > The overall trend is Perl died everywhere.

Far from the truth, Perl is everywhere, what died is the hype.

<comment><USER6> If the life of a language can be measured in how many people are learning it for any reason other than to maintain an existing code base written in it (an arbitrary definition, but I think a common one), then Perl is roughly dead-as- a-doornail, in precisely the same sense as, say, COBOL is dead.

(Note that under this definition, FORTRAN _isn 't_ dead—people still write new code in it, every once in a while, due to its mathematics libraries. Perl is "more dead than FORTRAN.")

<comment><USER7> Are you talking about new people learning language, as you state, or people writing new code in a language, as your example implies?

Without revision to clarify your point, it looks somewhat like you had a statement you wanted to make (Perl is "more dead than FORTRAN.") and had to reach for some assertions to support it.

<comment><USER6> The intersection of the two sets: new people learning the language, who are learning the language _in order to_ write new code in the language.

New people learn COBOL still, but they only do that if-and-when someone with an existing COBOL codebase has a problem with it, for which they're willing to hire and train up new programmers in COBOL.

For example, banks who needed their batch-processing code updated for Y2K-compliance trained a good few people in COBOL. But they weren't learning COBOL wIth the intent of writing _new_ code in the language—just with the intent of maintaining _old_ code. Effectively, they were treating the COBOL codebase as a Ball of Mud ([http://laputan.org/mud/](http://laputan.org/mud/)), where old components could be patched, but any new component should be written for a _living_ platform, communicating with the Ball of Mud over an API instead of being sucked into it.

I'm asserting, here, that Perl is such a language—that the only reason new people learn Perl is to maintain a Ball of Mud written in Perl. From there, they may go on to become productive Perl programmers—but because they were only "born" into the Perl community because some company who _had_ Perl-ers lost them and needed new ones, the language's adoption rate is effectively "below replacement," like a birth rate below 2.0.

In _living_ languages, at least some people will learn the language on their own, because they think it will be useful for some task they'd like to accomplish. Perl is not one of these languages.

Under this definition, other dead languages include sh-derivative shell scripting (people only _learn_ it because shell scripts that already exist must be modified), and anything to do with SOAP (it was stillborn; people only _ever_ learned about it to deal with codebases that used it. Then, horrifyingly, they ended up creating more of those codebases.)

</comment></comment></comment></comment></comment></comment><comment><USER8> When I came out of Google I could see the Python features that endeared it to Googlers (although I expect Go to replace Python pretty much everywhere there eventually). Blekko is a perl shop and it certainly felt a bit strange, but having gotten acclimated I can see the appeal. Every now and then I come across some really idiomatic perl and find it mind bendingly opaque, but for the most part I can code up a quick script in it faster than I ever could in Python.

Of course when you write code in a dozen languages you stop seeing the language after a while and just see the code. And at that point it really is all the same.

<comment><USER9> > Of course when you write code in a dozen languages you stop seeing the > language after a while and just see the code. And at that point it really is > all the same.

Fully agree. You start to look how language X exposes the CS concept Y, instead of just looking at language X feature list. A kind of meta level, if you will.

</comment></comment><comment><USER10> In my opinion, they buried the key point... the dead end of Perl 6.

Up until last year, I did a lot of web development in Perl. Its strengths were CPAN & community, ubiquity and top-notch text processing. Its acquired taste was very elegant expressiveness once you grokked the grammar.

Then all the Perl leadership focussed on the black hole of Perl 6 which was solving a problem no one had but CS linguists. So Perl users like me felt there was no future in Perl. Perl 6 would have to be relearned for no tangible benefit so why not learn something new with a growing rather than stagnant/declining ecosystem? No one was forced to leave, but like a trap door, as soon as a Perl programmer learned something new, they were only going to continue to decrease their use of Perl.

The rise of Python and Ruby (and Ruby on Rails especially) and even PHP, were grave wounds to the health of Perl, but Perl 6 was the self-cutting that bled the community beyond the point of self-repair.

<comment><USER11> I don't think Perl 6 is a dead end. Far from it. From what I know is that its nearly feature complete. A small set of features remain, but those are only like what should be added for completeness sake.

Bulk of the effort is in developing MoarVM, which is likely to become a suitable replacement for Parrot. Documentation, Speed and standard libraries remain as open issues. Of which last I heard was Larry Wall was writing a Camel book equivalent for Perl 6. So its mainly speed and standard libraries.

I would give end of next year, by the time its ready for prime time.

<comment><USER12> _I would give end of next year, by the time its ready for prime time._

I wish this claim wouldn't come up in every Perl article because that's a big part of Perl's perception problem. P6 is entering its 15th year of advocates claiming that it'll be ready in "about a year and a half".

If that claim is true this time, then it puts off people doing interesting things with Perl now as they figure they'll wait for a successor to look at it.

If that claim isn't true, then it puts off people doing interesting things with Perl now as the claim will change to be "about a year and a half from now" in another 18 months.

<comment><USER7> I agree with this as well, but from the other side. Giving out timeframes based on volunteer schedules in an industry that is already famously known for not hitting release times is not really useful. I think it's more useful to say "Perl 6 is already useful for many tasks, feel free to download one of the implementations and take a look. If you find it lacking in some area, let us know and maybe we can fast-track a solution for that." IMO that's not only more accurate and truthful, it's also much better way to draw in potential users.

<comment><USER12> Yes, predicting schedules based on volunteer effort is much more difficult than predicting schedules based on paid developer effort. Your proposed wording is a lot friendlier, but it doesn't match my experience with the project. (However, I've already written far too much on _that_ subject, so I won't bore everyone again.)

<comment><USER7> Well, I know it's in use in a few places now (I personally know someone using it at Google's engineering as a tool to retrieve and collate information, utilizing the newer async features), but of course there are still many rough spots. Whether it fits the bill for that person will be highly dependent on what they need.

I'm of the opinion the only way to solve the chicken and egg usage problem is to convince a few people to be chickens. That's not going to happen without them trying it out. (I'm aware you've thought quite a bit on this issue).

</comment></comment></comment></comment></comment></comment><comment><USER13> This article is full of rubbish. Like this:

      2000 Python 2.0 released    1994 Perl 5 released
      2008 Python 3.0 released    2000 – present[/b] Perl 6 "in development"

It's more like

      2013 — Perl 5.18 released

Perl 6 is entirely different language (with unfortunate name). And honestly, as a language it's light years ahead of python.

<comment><USER14> I liked writing Perl instead of bash but I couldn't shake the "whole thing is a hack" feeling. That why I found myself using more and more Python.

Is Perl 6 is more consistent(for lack of a better word) language ?

<comment><USER11> >>Is Perl 6 is more consistent(for lack of a better word) language ?

Not the right way of looking at it.

Perl 6 doesn't continue from Perl 5. Its more like a total redesign. Some even say, they are so different Perl 6 isn't even Perl(5) anymore- only common things being sigils, core philosophy and the author.

I can't obviously write a complete synopsis of Perl 6 in a comment. But its like what Perl 5 would look after 20-30 years in development + Lisp powers in C syntax.

</comment></comment></comment><comment><USER15> I'm by no means a perl expert having only written maybe 10k lines of Perl but ...

Perl seemed to me just hack upon hack. You can see the progression. First there were no local variables. Then "local" was added which effectively pushes the current value on the some stack and retrieves that value on the way back, then later "my" was added to actually give local variables.

Similarly all the crazy special variables @_,$_, $a, $b, $&, $', $+, @+, @- %-, $^R, $., $/, $|, $\, $", $; etc etc etc. I'm sure someone out there really loves that stuff but to many it's one giant hack, disliked for similar reasons to PHP's disorganization.

On top of that it died at version 5 because version 6 never came out.

For web stuff, PHP at least provided a huge speed boost (over CGI, the typical way Perl was used) PHP also supported the whole shared host model much better than Perl/CGI. I'm not saying I like PHP. PHP's templating roots also made it more approachable by beginners. I'm only pointing out why for some use cases PHP killed Perl.

On the other side Python also killed Perl. Python seems like far less of a hack upon hack design. Python also has a comparable number of libraries, many builtin making it usually as easy to bang something out as Perl was.

<comment><USER16> I have written maybe 100-200k lines in Perl.

> Similarly all the crazy special variables @_,$_, $a, $b, $&, $', $+, @+, @- > %-, $^R, $., $/, $|, $\, $", $;

Of these the only four most Perl programmers should ever use are @_, $_, $a, and $b. The rest are great for advanced manipulations (probably along with the local keyword) but are best thought of as configuration tweaks to the runtime.

> On top of that it died at version 5 because version 6 never came out.

Perl 6 did come out. It just doesn't have that much of a community and has about the same relationship to C++ does to C. Perl 6 won't kill perl 5. Ever.

Perl is dead in some environments (and good riddance), but it is a very powerful development environment for others and I doubt it will ever die per se.

</comment></comment><comment><USER17> In terms of expressiveness I think Python falls closer to Java than Perl. People make fun of Perl's sigils but I think Python's magic underscores and 'self' everywhere are much uglier in a verbose way. And no one will ever convince me that significant-white-space and not having block enders are good ideas, it makes refactoring and copy-pasting code hazardous. And I don't understand why every language hasn't added Perl's native regex syntactical sugar, it's a huge win for many problems.

But yea, Python won.

<comment><USER18> To your last point about regexes: I think the general idea is to discourage their use, at least as a default. It is so easy to use them in Perl that they are used _way_ too much, e.g. when you could do a regular (and faster) string search.

<comment><USER19> But isn't that a crime of premature optimisation? Perl's integration of Regex makes them easy to use and they fit naturally in the language, a lot more than in most implementations.

Being able to use Regex easily is a plus in my book. Yes they are lower than some dedicated string search or some state machine ad-hoc implementation, but you can document Regexes and they pack a lot of punch.

If a Regex is causing a concern in term of performance, then it may be time to review that code and optimise it, otherwise why even bother?

When people talk about Regex being bad and they say you can often use string manipulation instead they only talk about the most trivial uses of Regex.

As soon as you go beyond that, using a Regex is almost always going to be cleaner than spewing lines of codes and building state machines to achieve the same functionality.

<comment><USER20> It's more a matter of different design taste than it is an optimization.

(I don't think it is controversial that Python has a relatively simple language definition/grammar/etc; regex as language syntax would expand all of that quite a bit)

</comment></comment></comment></comment><comment><USER16> Hmmm... This article strikes me as relatively missing a few things.

Perl 5 is a mature language. There is a lot of effort at building Perl 6, but at this point it doesn't really look like Perl 6 will be a successor to Perl 5 (the metaphor now is "little sister"). It's so different, it is like learning a new language.

Now, I do a lot of programming in Perl. I have done some scripting in Ruby, Python, PHP, and more, but I always come back to Perl because the language is remarkably flexible. (Rebol is probably the second I frequently come back to, and Red looks promising.)

Predicting the demise of Perl is relatively premature. I don't think we will ever see Perl 6 supplant Perl 5. Rather these will become different languages (with a relationship similar to that of C vs C++).

Now you can write crap code in any language, and I just love how Python gives invisible characters semantic meaning (not), a problem that is likely to get worse as the number of whitespace characters continues to proliferate (not just plain spaces and tabs, but non-breaking spaces vs regular spaces....).

What perl has lost is the "let's quickly throw together an app" crowd. That crowd has gone sometimes to Python, sometimes to Ruby, and sometimes to Lua. From where I stand, good riddance. This is what gave Perl a bad reputation in the past.

To plug my own projects, right now I am working on a framework for delegating Perl object methods to PostgreSQL stored procedures.[1] At some point I may port the work to PHP and Python, but currently Perl is where this is really going for me. The thing is that such work is not applicable to the "throw together an app using an ORM or NoSQL fast" crowd, but it allows for some very sophisticated, powerful, and robust business tool development.

Additionally I have to plug [http://cpantesters.org](http://cpantesters.org). This is a really really useful piece of the Perl community. I got a test failure report today for PGObject::Util::DBMethod failing to load in Perl 5.6.4. My first thought was "who the heck uses Perl 5.6 anymore" and my next thought was "I guess I had better start adding minimum Perl versions to my Makefile.PL."

[1] The two most important pieces are [https://github.com/ledgersmb/PGObject- Simple-Role](https://github.com/ledgersmb/PGObject-Simple-Role) and [https://github.com/ledgersmb/PGObject-Util- DBMethod](https://github.com/ledgersmb/PGObject-Util-DBMethod)

<comment><USER21> > a problem that is likely to get worse as the number of whitespace characters > continues to proliferate (not just plain spaces and tabs, but non-breaking > spaces vs regular spaces....).

I know that people love to hate on Python's semantic whitespace, but this is the first time that I've seen someone argue that Python's lifespan is limited because we are about to enter a period of exponential growth in the number of whitespace characters.

Where do you feel that this growth in the number of whitespace characters is going to come from? Do we not already have a plethora of whitespace characters in the current Unicode standard, in addition to things like the vertical tab of yesteryear that languishes in the ASCII standard? How come we don't see any of these issues now, even with the number of whitespace characters that we already have at our disposal?

> The thing is that such work is not applicable to the "throw together an app > using an ORM or NoSQL fast" crowd

Are you trying to imply that using an ORM is the sign of someone trying to "whip something together fast?" What are your feelings on DBIx::Class? Should those people who use it jump ship to some other language so that you can bid then "good riddance?"

<comment><USER16> > I know that people love to hate on Python's semantic whitespace, but this is > the first time that I've seen someone argue that Python's lifespan is > limited because we are about to enter a period of exponential growth in the > number of whitespace characters.

I think the various Unicode whitespace characters are likely to gain more use generally. The big problem though is that whitespace characters all look alike and so you can't read and parse the way a computer does.

> Are you trying to imply that using an ORM is the sign of someone trying to > "whip something together fast?" What are your feelings on DBIx::Class? > Should those people who use it jump ship to some other language so that you > can bid then "good riddance?"

Not really. ORMs can be used in significant applications and in fact a lot of people use DBIx::Class that way in Catalyst etc. I am referring specifically to the quick and dirty app crowd. You have PHP, Python, Javascript (via Node.js) and Ruby largely taking that role over. And that's fine. Perl is a wonderful language, but to write good quality, maintainable, robust code in it takes some work. But that work is well rewarded.

<comment><USER22> > I think the various Unicode whitespace characters are likely to gain more > use generally. The big problem though is that whitespace characters all look > alike and so you can't read and parse the way a computer does.

I think the big problem is, that there are people out there, that think Python programmers have a huge urge to use non-standard whitespace characters in their source code.

> Perl is a wonderful language, but to write good quality, maintainable, > robust code in it takes some work. But that work is well rewarded.

The reward for that kind of code is the same in all languages, but your statement implies, it's maybe better to choose a language, where it's not as hard as with Perl to write good quality, maintainable, robust code. Point taken.

<comment><USER16> Writing good code in any language is remarkably time-intensive to learn. There are any number of ways to mess up code and the coding patterns and antipatterns are different in any language.

It takes struggling with the ways of doing things in the language and seeing what works and what does not. Perl is no exception, except that there is no One True Perl way. Every Perl programmer finds his or her won way.

</comment></comment></comment></comment></comment><comment><USER11> I'm not sure why every Python lover has to be Perl troll. No seriously. The author is clearly a Python fan boy, and he can very well write a good technical article to illustrate Python's goodness. I'm sure we all can appreciate that. But you don't have to troll Perl endlessly to do that. Besides all that, I've been hearing this Perl is dead thing since what, 10 years? If that was really the case Perl should not only have died, but should have even been forgotten from our very memories.

Something tells me most Python lovers take Perl as a very serious competitor. Else they wouldn't be writing articles like these.

Python's big rise came after hipster crowds got web frameworks written in Python. If you use hibernate or spring in Java, you can only come to love Python's web frameworks. But that time is long gone now. The crowd went to newer languages like Scala and Go. For all practical popularity purposes. Perl and Python are the very same these days.

If you are really worried about popularity. Lets talk of Python's falling popularity compared to languages like Go and Scala.

>>By the late 2000s Python was not only the dominant alternative to Perl for many text parsing tasks typically associated with Perl

When it comes to serious text parsing work, Perl is still the only practical alternative you have. Ever checked upon Perl's Unicode capabilities?

>>2000 – present[/b] Perl 6 "in development"

The development of Perl 6 didn't start in 2000. And Perl 6 and Python aren't even in the same league for comparison.

However the author completely misses the point. I can sit on top of a high priority production issue, just have a big log file. If all I have is that- Perl has the tools to help me get my job done in a couple of hours. Call me back, when Python can help me do that.

>>Perl 6 has been an ongoing development since 2000. Yet after 14 years it is not officially done, making it the equivalent of Chinese Democracy for Guns N' Roses

Comparing Perl 6 and Python's progress is a bit ridiculous. Merely the ambition and audacity of what Perl 6 is aiming to achieve is what Python would like to in the next 20-30 years of iterative development.

Perl 6 is not your usual language which aims a different syntactical style for decision and iterative statements and then calls it progress. A simple tour of the Perl 6 spec can help you on that.

</comment><comment><USER23> This could have been titled "The Rise Of Python".

Both languages have their uses. I write almost all of my code in Python these days, but fall back to Perl for complicated bash scripting. Shell scripts in Python feel clumsy, while Perl is very well suited for that environment.

<comment><USER24> >Shell scripts in Python feel clumsy

Not once you've seen this: [http://amoffat.github.io/sh/](http://amoffat.github.io/sh/)

<comment><USER23> Oh wow, that's pretty sweet. I'll have to play around with that.

</comment></comment></comment><comment><USER25> Still coding perl. I got something against a programming language telling me what to think the way Python does. Python is latin, perl is english.

<comment><USER26> U understand English? Dude, shit is cray.

<comment><USER8> I believe you meant to say 'shit is wack'

</comment></comment></comment><comment><USER27> Perl missed out on the hype-bubble of the web 2.0 craze which shot Python and Ruby to the top of the charts in the early/mid 2000's. But it wouldn't surprise me if Perl was "rediscovered" at some point sort of like how JavaScript has experienced a renaissance since Node and the much-improved runtime engines showed up.

Personally, I have done a little work in Perl, but I never really considered it as tool I would want to build a large app using. I have always argued however that Perl is an ideal replacement for shell scripts and I have wondered for awhile what an interpreter shell would feel like if it used Perl as the language rather than say Bash.

<comment><USER28> given the relatively small number of new programmers is an actual advantage for us: increased salaries. i don't know the actual reason why, but we have students who, after 3-4 weeks of perl training are thrown in production environment where they fix bugs and implement features on par with our senior devs. It might be because they are very smart, or because the language is actually simpler to learn than it looks at first sight. And the production environment that I'm talking about is a very complex web app from an architectural point of view: it has mysql, memcached, the authorization of documents is done through sphinx search engine, we're using dbix class as an orm and catalyst as a web framework, etc

<comment><USER29> Authorization via sphinx? Interesting!

In any case, we use Perl heavily at Craigslist and are helping to sponsor the continued work on Perl6. I don't think it's nearly as bad as people seem to think. But time will tell, of course.

<comment><USER28> Yeah, basically there are 100k+ users in DB and 800k+ documents. Each document is filed under one or more geographies and one or more industries. Each user is entitled to access one or more geographies with one or more services. The SQL queries, besides that they have very complex where clauses, are very slow.

We use sphinx by indexing those documents, and attaching the geographies and industries as tags to each document. Whenever a user logs in, it takes only a few hundreds of miliseconds to get the latest documents he needs to see

</comment></comment></comment></comment><comment><USER30> A few days ago I was at a Half Price Books store. Something which struck me at the moment was that while there were probably 20 Perl books (some of them duplicates), there wasn't a single Python book. I took it as in indication that Perl is in decline and people are unloading their personal perl library and nobody is buying the used ones; meanwhile, people are holding on to their Python books and ones which show up get snapped up.

The alternate interpretation is that Perl needs a LOT of books to explain things due to its quirky syntax and myriad coding idioms, so there are simply more Perl books in circulation.

</comment><comment><USER31> In what possible universe could Perl be considered "straight-jacketed"?

<comment><USER32> Also, pedant nitpicking: it's straitjacket.

<comment><USER33> "straightjacket" is also acceptable.

</comment></comment></comment><comment><USER34> >dubbed the Swiss army knife of the Internet

"Swiss Army chainsaw" is the correct quote (as can be verified by following the source link provided in the article).

</comment><comment><USER35> It seems the perception of Perl 6 as a long delayed update to Perl 5 is a serious problem for the languages. Perl 6 is not really the next version of Perl 5, it is more like another language.

Perl 5 is still under active development. The latest stable release was version 18.2, made in January. Perl 5 will continue to exist even when more people start using Perl 6. Also, Perl 6 is available and usable already.

</comment><comment><USER5> Contrary to popular belief Perl is still very much alive and healthy. Sure, it has baggage, but so does any language that kept evolving for decades. If you want to know what Perl really looks like these days take a look at the Modern Perl book ([http://modernperlbooks.com/books/modern_perl/](http://modernperlbooks.com/books/modern_perl/)) and Mojolicious web framework. ([http://mojolicio.us](http://mojolicio.us))

</comment><comment><USER36> Perl was the first scripting language I really learned when I was an intern at Sun. I read the whole Camel Book my first couple weeks there. I had an awesome sysadmin mentor that was a Perl guru, and when I asked for help he would give me mysterious one-liners that did powerful things, simply saying "use this". I had little idea what I was doing at the time, but it was awesome.

I use Ruby now for most scripting, and it is also awesome, but a lot less mysterious.

</comment><comment><USER37> I understand that this is written from an academic point of view and focuses on scientific computing, but writing "upstart PHP grew in size to the point where it is now arguably the most common language for web development" is a serious understatement.

PHP dates back to 1994, and (arguably) became a serious contender with the release of PHP 3 in 1998. PHP pushed out the then-dominant web programming languages ASP (a Visual Basic variant) and ColdFusion, along with Perl. At that time Python and Ruby were not on the web development radar.

PHP is not "arguably the most common language for web development": it's by far the most common. Much of that is due to WordPress, Drupal, and other PHP- based CMSs, but unlike Ruby and Rails, PHP had a large developer base before WordPress and Drupal.

The article also completely ignores JavaScript, which thanks to node.js is gaining web developer mindshare faster than either Python or Ruby, and may push PHP's share down.

[PHP also uses the hated $ to prefix variable names, but that hasn't slowed it down. PHP is not as pretty as Python or Ruby but it's a lot easier to read than Perl.]

<comment><USER38> "PHP is not as pretty as Python or Ruby but it's a lot easier to read than Perl."

Good Perl is quite readable, and bad PHP, well, you are a fortunate man if you have never encountered any, and a top-notch reader if you have and have found it easy to follow.

</comment></comment><comment><USER39> Languages that target and reach large numbers of beginners tend to do well. PHP tends to be the primary example, but BASIC and all forms of it continued by Microsoft are another. When any newb can sit for a few minutes with your language and a HOWTO and make a functioning (web)app it has a chance to be successful.

It's hard to target people with a 'harder' syntax even if it may be better for some particular reason. Once a person has learned one language it is more worthwhile to gain a more broad knowledge base in that one rather then invest time learning in another.

It's likely most people that learned perl didn't start with perl as their first language. At the time it what came with whatever form of unix they had and extended the scripting they did, but was not friendly. There was just a lack of alternatives at the time. Now, in an interconnected world with no shortage of better alternatives, there is simply little reason to invest any time in learning Perl.

</comment><comment><USER40> My me-too post.

I was a web developer working nearly exclusively in Perl during the time period the author describes. I understand the author's lack of a handle on the period as he was, as he describes, in middle school at the time. Me, I had a job and a family and I was an actual Perl programmer. Come at me bro.

That aside, the description of a transition of developers from Perl to Python just didn't happen the way it is described in the article. Or, to be fair, it didn't happen that way for me.

I worked on a team extracting data from a number of disparate data sources and presenting reports on the web - basically the idiomatic Perl task. We tried to bring in PHP for a bit but found it wanting. As our jobs evolved out from under us, each of us moved on from Perl. Reporting jobs were becoming largely obsolete and there was market demand for working in other languages elsewhere. Being the early oughts, most of the engineers I knew had at least a few languages in their repertoire.

Of the developers I worked with, I was the only one to pick up Python. I remember feeling like I wanted to work with a dynamic language where OO was more core to the language feature set. Ruby and Python were both viable, though less known, options. I don't remember why I chose Python over Ruby, but I did.

My colleagues went on to work in Java or C#. Over time, I did a bit of both as well, especially C#. One buddy of mine still does his personal and peripheral scripting in Perl. I've largely forgotten the language.

Back on topic, I simply did not see an exodus of developers from Perl to Python. It just didn't happen that way within my community. Jobs got phased out, new ones began, often with new tools.

Off topic, what I did see at the time was a large movement of COBOL developers to JAVA. I saw that as a genuine migration, in earnest, of developers who were facing obsolescence.

</comment><comment><USER41> I only had a shallow knowledge of perl, then I read this [http://matt.might.net/articles/perl-by- example/](http://matt.might.net/articles/perl-by-example/) . As much as I like linguistics, perl sometimes feels a little too creative :)

<comment><USER42> FYI, that article got criticized on HN pretty heavily not ago for not doing things in the 'modern Perl' style:

[https://news.ycombinator.com/item?id=7220167](https://news.ycombinator.com/item?id=7220167)

<comment><USER41> Thanks, I assumed good authority from the author since he's into Programming Languages research. Heading to your link now.

</comment></comment></comment><comment><USER43> I used perl as my go-to general purpose language for years and years until I joined a python team in 2004, now the only thing I use perl for is as a sed replacement. The perl6 stuff just killed all its momentum dead, and then it seemed to drop off the face of the earth.

I don't see it coming back anywhere near what it was fifteen years ago. Too little too late.

The only thing I miss about perl is the regexes right there at the heart of things, but I'll trade those for scipy/numpy/cython/etc and come out the better for it.

</comment><comment><USER44> I'm going to take a moment to vent about Perl. My company was experimenting with it as an alternative to Ruby based on the enormity of available CPAN modules.

1\. CPAN is awful. The website itself is so bad that the "correct" way to browse it is to use the big brother "Metacpan". Metacpan is also very bad, they strayed too close to CPAN design. Navigating it is a pain, and most of the documentation is done very poorly because no one puts time into formatting their readmes. None of the modules are in github, the issue tracker is a nightmare, the links make no sense ( "Source (raw) Browse (raw)" ) - <USER2> website itself is poorly done.

2\. CPAN has many modules, which sounds like a selling point. The truth is that many of the modules we have worked with have bugs and poor documentation, and almost all of them are unmaintained. The owners either gave up or actually died (this is an old language after all). There is absolutely no support for trying to do common tasks with CPAN modules. You can't Google for your error, you won't get a response on StackOverflow. Bug reports don't get answered because the ecosystem is a ghost town. This makes trying to do common tasks painful.

3\. CPAN is just messy all around. There's not even a command line flag to find out what version of a module you have installed. You have to hack into its internals to figure out what versions you're running. Some modules are hosted in foreign countries that intermittently decide not to download. Builds have broken due to inability to download from a mirror. A "benefit" of CPAN is that modules are tested against multiple architectures for you. The reality is that these tests don't matter. The Perl developers I've worked with bypass the tests with CPAN by installing with --notest because it's faster, and more than once a module has failed to install because the tests failed. But the failure was either a false positive or had no noticeable impact on implementation, and there's no alternative and no one to respond to bug reports. The only known benefit of CPAN - automated test running, has never once proved helpful.

4\. One point I like in this article is that Python makes the right thing obvious. Perl's "multiple ways to do things" is one of its bigger design flaws. It seems like Larry Wall (creator of Perl) has a no-one-likes-this- langauge-so-try-to-please-everyone-by-offering-every-way-to-do-it complex. It's all to the detriment of the language. I have to Google for how to iterate over a hash every time, because there's multiple ways to do it, and they all suck. I never know if iterating over a $hash is the same as iterating over a %hash or a \%hash. Or if I should be searching for "hash" or "hashref" or if I should be using a "list" or an "array" or a scalar or who cares. The multiple ways to do things only amounts to one asshole on the team will exploit some unknown feature of map to write shorter code, not document it, and no one can read it. Any efficiency gained from shorter code is lost to unmaintainability. Also, Perl is not efficient, so it doesn't matter.

5\. The language itself is gross. Beauty is subjective, readable code is not. The prefixing of variable names with @, % et all makes dissecting code hard and Googling impossible. The tacking-on of modern functionality will slap you in the face repeatedly. See: references. References are one of, if not the, biggest design flaw in Perl. They were introduced as a tack-on to hack over it's shitty default data structures. They make reading and writing code confusing, overly complicated, and haven not once offered us any benefit. Perl's leaky abstraction over poorly implemented data structures is easily seen in references.

6\. No really, the language is gross. It has magic built in, and the syntax is a nightmare. Everything is done with sigils (characters like ~!=@#$ etc). You get function arguments as @_ . You do a regex match with $string =~ /(capture)/. This will magically populate $1 through $n with capture groups. This is bad. To substitute a string, you do $string =~ s/a/b. This modifies the string in place. Try to Google for how to not modify the string in place. Seriously, try and Google for it. If you forget to include an even number of values in a list it becomes another data structure entirely. If you don't put a '1;' at the end of your module code it will fail to work (no, really).

7\. Larry's personal beliefs stray into Perl too much. Larry is a well known Christian, and you must "bless" a reference, a keyword baked into the language. This creeps me out. It doesn't really matter, and I 100% acknowledge how judgmental I'm being, but it still is out of place in a programming language.

8\. All of these reasons culminate to one point I just realized: Perl is a bad language for a team. It might be fine for one person to write code that will never have to be maintained or read to accomplish some dirty task. The "features" of Perl ruin it for a team environment. Feautres like its "flexibility", wheel reinventing to avoid buggy CPAN modules, unreadable features hidden in sigils, magic, poor documentation, and hacker culture make it a very poor choice for multiple people to work on the same thing.

This is the perspective of a relative newcomer (~3 months of Perl exploration). I'm not a Python advocate and I don't have a strong opinion of what other language you should use, but Perl has caused us many problems and we switched to Ruby early on because of them. Maybe if / when I learn more about it I'll have a different opinion of it. Right now though I agree with this article and seeing Perl go out the door is fine with me.

<comment><USER45> Troll harder, greenhorn. (account "metsgrets" created 7 hours ago)

> CPAN is awful […] Navigating it is a pain […] the issue tracker is a > nightmare

These are opinions. I cannot see any facts to substantiate the claims.

> most of the documentation is done very poorly because no one puts time into > formatting their readmes

No, most of the documentation is the best among libraries in any programming language because everyone uses documentation templates and then fills in the details in copious amount. These templates have been honed over years, and the docs are regularly quality checked by automated services. It also helps that the documentation format POD is so so stupidly simple that it never gets in the way of work: a programmer spends all the time writing content, none on formatting.

> None of the modules are in github

All of the modules are in Github.

> the links make no sense ( "Source (raw) Browse (raw)" )

"Source" shows the module's source (HTML, syntax highlighted). "Browse" browses the directory structure of the unpacked distribution. The raw links are the plain text equivalents served by the API primarily for programmatic access. All of this is readily obvious by just following a link.

> many of the modules we have worked with have bugs and poor documentation

Unsubstantiated, no details.

> and almost all of them are unmaintained

CPAN freshness tells a different story.

> owners either gave up or actually died

There's a process in place for taking over maintenance. It is used a couple of times a month.

> There is absolutely no support for trying to do common tasks with CPAN > modules

Wrong. Any common task has several modules.

> You can't Google for your error

Unsubstantiated, no details.

> you won't get a response on StackOverflow

Wrong. Unanswered quota is only 10%.

> CPAN is just messy all around

Same is true for any file archive. Show me a programming language where this is not the case. At least it's centralised, not strewn across the Web! On top of the archive, curated indexes such as [http://p3rl.org/Task::Kensho](http://p3rl.org/Task::Kensho) exist.

> There's not even a command line flag to find out what version of a module > you have installed. You have to hack into its internals to figure out what > versions you're running.

Wrong.

        $ pmvers Catalyst
        5.90060

        $ perl -MCatalyst -E'say Catalyst->VERSION'
        5.90060

> Some modules are hosted in foreign countries that intermittently decide not > to download. Builds have broken due to inability to download from a mirror.

Then pick a mirror near you. [http://mirrors.cpan.org/](http://mirrors.cpan.org/) The standard CPAN client does this automatically during first run.

> The only known benefit of CPAN - automated test running, has never once > proved helpful.

Unsubstantiated, no details.

> It seems like Larry Wall (creator of Perl) has a no-one-likes-this-langauge- > so-try-to-please-everyone-by-offering-every-way-to-do-it complex.

Wrong, this is because humans have different ways to think and preferences how to express themselves. The programming language works _with_ the grain of the human mindset, not against it. [http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt](http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt)

> I have to Google for how to iterate over a hash every time, because there's > multiple ways to do it, and they all suck. I never know if iterating over a > $hash is the same as iterating over a %hash or a \%hash.

Then you know less than a beginner in his third lesson.

        ⎆ my %hash = qw(a b c d); my $hash = \%hash
        ⎆ while (my ($key, $value) = each $hash) { say "$key => $value" }
        a => b
        c => d
        ⎆ while (my ($key, $value) = each %hash) { say "$key => $value" }
        a => b
        c => d
        ⎆ while (my ($key, $value) = each \%hash) { say "$key => $value" }
        a => b
        c => d

> if I should be searching for "hash" or "hashref" or if I should be using a > "list" or an "array" or a scalar or who cares

Only bash and Tcl free you from thinking about and selecting the appropriate data type.

> The multiple ways to do things only amounts to one asshole on the team will > exploit some unknown feature of map to write shorter code, not document it, > and no one can read it.

This is a social problem, and not the responsibility of the programming language or its designer. Anyone can write crap code in any language. Enforce code style and policy locally. Static analysis tools like [http://p3rl.org/perlcritic](http://p3rl.org/perlcritic) exist. Apply them.

> Perl is not efficient

Perl remains the fastest of the scripting languages.

> Beauty is subjective, readable code is not.

Unreadable code is a social problem across all programming languages. This has nothing to do with Perl per se.

> The prefixing of variable names with @, % et all makes dissecting code hard

Wrong, sigils make the nouns stand out, just like capitalisation in written German. Both empirically make reading faster and comprehension easier.

> Googling impossible

Wrong. It is true that search engines drop sigil characters from the query, but the context words still find the result in the index.

> References are one of, if not the, biggest design flaw in Perl […] make > reading and writing code confusing, overly complicated

Unsubstantiated, no details.

> haven not once offered us any benefit

Wrong, as references are the basis for objects (OOP).

> the language is gross. It has magic built in, and the syntax is a nightmare

Unsubstantiated, no details.

> You get function arguments as @_

Concept stolen from Shell, already remedied in version 20. Signatures have been available for years with modules.

> You do a regex match with $string =~ /(capture)/. This will magically > populate $1 through $n with capture groups. This is bad.

Agreed, side effects are evil. That's the legacy interface and impossible to deprecate/remove. The expression will also return a list of the captures which you can then assign or mangle as you wish.

        my @results = $string =~ /(capture)/

Good style dictates to prefer this interface.

> $string =~ s/a/b. This modifies the string in place. Try to Google for how > to not modify the string in place. Seriously, try and Google for it.

Yes, and?

        g perl substitute return modification

(Type it out to see Google suggestion/autocompletion.) First five results all teach:

        my $new = $string =~ s/a/b/r

> If you forget to include an even number of values in a list it becomes > another data structure entirely.

Wrong, a list is a list no matter how many elements.

> If you don't put a '1;' at the end of your module code it will fail to work > (no, really).

Valid complaint. Again, it's too late to fix it because existing code needs to keep working, back-compat is serious business for perl5-porters. New projects with modern Perl just avoid the need for that last line: [http://p3rl.org/true](http://p3rl.org/true)

> bless […] but it still is out of place in a programming language.

The word is religion neutral. Your biases show.

> The "features" of Perl ruin it for a team environment.

Unsubstantiated, no details.

<comment><USER46> Yeah, I don't understand why people want to hate on perl for no reason. Perl people don't generally hate on other languages much (maybe aside from Java and PHP).

<comment><USER47> sounds like he didn't really understand many features of the language.

</comment></comment></comment></comment><comment><USER48> Perl - the ultimate job security tool.

When I come upon a Perl program that does 80% of what I need, and would do 100% when modified, I simply turn around and look again. I consider reading other peoples Perl code on the same level as firing up Hexrays to debug closed source Mips programs.</comment>


Answer: How many center-pivot irrigation systems do you see? - <AUTHOR> http://searchresearch1.blogspot.com/2016/08/answer-how-many-center-pivot-irrigation.html <comment><USER2> I always wondered why these are laid out in a grid, and not hexagonally, which is optimal for circle packing. You could fit more in that way.

<comment><USER3> Good question.

That would be fairly (ok, wildly) impractical.

Most of the roads are gravel, which means that maintenance would be a nightmare. Road graders aren't great at keeping the blade level on turns. So you'd get buildup/digout at every turn.

When it rained you'd get run-off and erasion. Which makes me think of drainage, wow, with the water making 120 degree turns roughly every half mile you'd get some serious washout on those occasions when we get 2" dumped on us in what feels like 10 minutes.

Zig-zagging across the country with a 24-row planter in tow would be a giant pain in the ass (you plan your route minimize the number of turns you're making). Would be a pain driving a combine fitted with a 12 row head. And at harvest the trucks taking grain to the elevator or silos would be doing the same zig-zagging.

It's not like the grain that's outside the obvious circle doesn't yield. It get irrigated via runoff as well as powerful sprinkler guns at the end of the pivot arm.

Credentials: grew up farming in central Nebraska, married into a 5th generation farming family. Thousands of acres, all centrally irrigated via pivot.

Edit: Didn't want opening tone to sound argumentative/condescending.

Edit 2: Just thought about power lines. They'd have to zig-zag too. Which means the pole on the zag would have lateral force vectors acting on it, so it would have to be reinforced/anchored. When the afore-mentioned washouts happened, down goes pole and powerline.

<comment><USER4> Your points are totally valid. But you wouldn't need to make sharp 120 turns. You could just have very slight waves with a frequency of 1 mile.

[http://i.imgur.com/vJq0Q3i.png](http://i.imgur.com/vJq0Q3i.png)

Of course, driving on roads like these would be annoying.

<comment><USER5> > Of course, driving on roads like these would be annoying.

ITYM _awesome_. Those roads are normally 30 mph, so at with 1 mile fields one would change course every two minutes

I wonder if it might help protect against highway hypnosis to have a course adjustment every mile or so.

<comment><USER6> Kansas, and likely other mid-Western states that I don't know about, have historically added "artificial" curves on their highways to increase safety by stimulating drivers and reducing boredom.

</comment></comment></comment></comment></comment><comment><USER7> Discussions like this are why I love this site. I've seen these from airplanes, but never even thought about it enough to know it was called center-pivot irrigation. Now I know how big they are, their density, why we can't arrange them in a hex, etc.

Alright, so here's my question: Since we can't arrange the roads in a hex, why not make the grid a little smaller or the irrigation arm a little longer so that it can reach the corners of the grid. It would obviously run over the road at the midpoint of each side, so if the road needs to stay dry-ish, shut off the water supply automatically somehow at the ends of the arms. Then you can make the whole square green. This creates an obstacle to watch out for when using the road, but otherwise what am I thinking wrong here?

<comment><USER8> Or just make the arm retractable.

<comment><USER9> The more moving parts the more expensive, especially in maintenance. It's just like harddrives in server farms, even small changes in drive reliability have a big influence due to the number of them in operation in parallel.

</comment></comment></comment><comment><USER10> I wonder what kind of interesting stats one could dig up from aerial images of the farms near La Crosse, WI. Instead of a grid of circles, the farms carve out a bunch of fascinating patterns in the fractal topography around the river. (I'm sure there are similar layouts in other regions, but that's the one that stands out in my memory.)

Example: [https://firstname.lastname@example.com,-90.9363052,5382m/da...](https://firstname.lastname@example.com,-90.9363052,5382m/data=!3m1!1e3)

</comment><comment><USER11> Any suggestions for open source tools doing this, e.g. in python or R?

<comment><USER12> Here is one using open CV in python [1]. While there are many ways to find circles the Hough transform is a fairly simple and popular one, I don't know what Matlab uses internally but it would probably be an optimised version of Hough for circles. you can see some more here [2], implementing this process in raw python (with PIL or pillow) was something we did in our image processing course in undergrad so certainly not out of reach if you wanted to give it a go.

[1]: [http://opencv-python- tutroals.readthedocs.io/en/latest/py_tu...](http://opencv-python- tutroals.readthedocs.io/en/latest/py_tutorials/py_imgproc/py_houghcircles/py_houghcircles.html) [2]: [https://en.wikipedia.org/wiki/Circle_Hough_Transform](https://en.wikipedia.org/wiki/Circle_Hough_Transform)

<comment><USER13> I built a Machine Learning algorithm about a decade ago for doing this kind of feature extraction. It was targeted for finding samples on a tissue microarray, but it's basically the same problem (find approximately circular features on an approximate grid).

The research was never published and it was a kind of a hack (an EM-style algorithm that added a step to update grid parameters after the M-step of the centroid fitting).

It worked well enough, but would not be able to handle the heterogeneous circle sizes (1 mile + 1/2 mile) that are demonstrated in the post. Something like this is so well constrained (1 or 2 circle sizes) that running a hand- tuned mix of segmentation algorithms is a pretty good approach.

</comment></comment></comment><comment><USER14> How to count them with less effort - no need to count over the whole map. Perhaps Google would ban you if they saw too many requests for map tiles.

So, here's how to do it: sample 100-200 locations in a country. In each location, extract a tile of the map and count the circles in there. Then you need to scale the sum by the total surface of the country divided by the total surface of the sampled tiles.

<comment><USER15> The problem with that is that the locations of the sites are probably very correlated, meaning that your samples will no longer be independent, and your estimate would probably be biased.

<comment><USER16> If the sampling process gives you a random subset of tiles, I don't see how the estimate could be biased. Even if you have a strange distribution of circles (heavily clustered in certain geographies), the weak law of large numbers would mean that the sample mean is an unbiased estimator for population mean if your sampling process is iid (random number generation is by definition iid).

[https://en.wikipedia.org/wiki/Law_of_large_numbers](https://en.wikipedia.org/wiki/Law_of_large_numbers)

I think you're confused between which restrictions apply to the sampling process versus the underlying population.

<comment><USER15> Ugh, you are of course correct, I should not be allowed to comment on statistics before having my first coffee. I think I had some diffuse ideas about this not being a poisson processes in my head that lead me to this faulty conclusion.

</comment></comment></comment></comment><comment><USER17> One could probably improve the detection quality by using something like the NDVI to separate vegetation from the background.

</comment><comment><USER18> And here's the Question: [http://searchresearch1.blogspot.com.au/2016/08/searchresearc...](http://searchresearch1.blogspot.com.au/2016/08/searchresearch- challenge-8416-how-many.html)</comment>


Dynamic Tracing a Pony and Python Program with DTrace - <AUTHOR> https://blog.wallaroolabs.com/2017/12/dynamic-tracing-a-pony---python-program-with-dtrace/ <comment><AUTHOR> My colleague at Wallaroo Labs wrote this and I submitted while he is still happilly sleeping (timezones are a wonderful thing). Happy to answer any questions I can and if there are any I can't, after he wakes up, I'll direct him here to try and answer them.

<comment><USER2> Good morning. The world has continued to turn, and now it's my turn to say hello and to offer a chance to answer questions from HN.

-Scott</comment></comment>


"Breaking Down Barriers to Innovation Act" Targets Many of DMCA's Problems - <AUTHOR> https://www.eff.org/deeplinks/2015/04/new-breaking-down-barriers-innovation-act-targets-many-dmca-section-1201s-problems

<comment><USER2> The bill [0]

[0] [http://www.wyden.senate.gov/download/?id=f2d03a70-63d7-432c-...](http://www.wyden.senate.gov/download/?id=f2d03a70-63d7-432c-99e8-ae9a3fb4befe&download=1)</comment>


Quicktime Player 7 Lies About Playback Speed - <AUTHOR> http://curi.us/1484-quicktime-player-7-lies-about-playback-speed

<comment><USER2> This could be intentional. Like how human perception sometimes requires exponentional changes to perceive a difference. Example: The audio decibel scale.

<comment><AUTHOR> Why not just have a non-linear scale but labelled correctly?

And it's fixed in quicktime 10.</comment></comment>


Putting Devs Before Users: How Frameworks Destroyed Web Performance - <AUTHOR> https://medium.com/@CM30/putting-devs-before-users-how-frameworks-destroyed-web-performance-6b2c2a506aab <comment><USER2> I don't think engineers use frameworks because they think it makes them look cool. They may choose between multiple, competing frameworks based on community perception, but not between using a framework and not using one.

It's usually an argument from business needs that leads to application bloat. For example, what PM on a startup would sign off on spending two weeks to implement a custom date library and date picker component when there are excellent, if sizable options available to install _right now_? What small- or medium-sized company is going to create an in-house application framework when React is very good, and there are thousands of people you can hire who already know how to use it? A major reason applications get bloated is because development time costs the company more than client bandwidth and CPU do.

So, in that sense, it's not a matter of convenience either: It's a selection made based on weighing the constraints and options and selecting the best one. If poor application performance started costing companies a lot of revenue, I'm sure the result of the calculation would change.

<comment><USER3> > I don't think engineers use frameworks because they think it makes them look > cool.

I've been in this line of work for a long time, and I'll admit its a huge factor. Webdev is a very fad-driven business, and I've seen numerous technologies come-and-go where they were hot, but not they are now super not. And to some degree this is logical, because you want people who can adapt to whatever is latest-and-greatest and not just a particular platform. But when recruiting it certainly helps.

Plus the old chestnut that 50%-80% of software projects are failures, and looking out for number one means resume-oriented development for the next job. You are probably better off with a failed project on a 'cool' framework than a successful project on an uncool one.

<comment><USER4> I've talked to several really enthusiastic developer advocates about technology in the corridor and when it comes to describing the actual product or use of the technology they tend to mumble, or wave hands, or state some product that HN would argue about (e.g. advertising). All the developer advocates I've met who promote latest tech really don't seem to like their companys product.

I would say that developers try to make it a fad to keep themselves interested and engaged in an otherwise boring, soul destroying or socially harmful job.

<comment><USER5> Don't forget that a dev may need another job in the future. And it doesn't help finding one when spending the last 2 years building an app with some "oldschool" tech stack that performs well. Most companies are looking for dev's who worked with the cool fancy stuff like react because that's already the tech stack they are using.

And what is so bad trying to make my job interesting? If it's boring I wouldn't care much about the end result. Just another 9 to 5 job then.

<comment><USER4> Nothing bad about making something interesting. You would be interested in the end result - but for developers who do this the end result is the technology they produce and not the product that the tech is being used for.

I think it would be one of the reasons why "putting devs before users" happens.

Also - look at the HN Who's Hiring threads. Almost all postings don't talk about the product or their users. They talk about the technology.

<comment><USER5> That's true, in most of the company's I worked (includes the current one) I'm not interested in the product at all. I work there because I can decide which tech stack we use, try and learn the fancy stuff and have some fun building it. Why? Because I can - I am one of the few "good" dev's out there. So many companies are hiring and they take what they can get. And I as a dev can choose where I want to work. And of course I choose the interesting one. In conclusion there are much more companies hiring then good dev's looking for a job. So the company has to make itself interesting for dev's.

But I don't think that's bad at all. With modern devices and Browsers you can't tell the difference between using a framework or not.

<comment><USER6> That was a funny bit of honesty. You should have stuck with it till then end and tell it like it is: It doesn't work on slightly older devices. Or something like: You really notice things don't work when using a slightly older device.

Jokes aside, I cant seem to find data on the age distribution of interneted computers.

<comment><USER5> You are the kind of person who believes that every app should support ie8 and even before that, right? Don't forget to limit your 500ps car to drive only 25mph...

<comment><USER6> It isn't your fault they hire people who don't care about the product. That you pick a tech stack that inspires you is a logical [and predictable] follow up.

I think a lot of people still think things are/should be something like: First the product, 2nd the customer, 3rd the company, 4th the investors and the employees last.

But the reality is often more like: First the investors, 2nd the employees, 3rd the company, 4th the customer, and oh we need some kind of product too!

You get the open floor plan so that the investor can see lots of people working. A nice ping pong table to illustrate the lack of employee equity. A fun tech stack to attract and keep the employees happy. Large expensive chunks of plastic with the company name on it. Great customer service to help the customer with _their_ problems and lastly a product that doesn't work.

Again, I'm not suggesting any of this is your fault. On the contrary, one cant teach passion. You either care about the product or you don't.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Frameworks allow websites to be built faster, maintained with less expertise, and changed faster over time. That is the benefit to the user. That things are slower than they could be doesn't matter to most users. Most companies can't afford to pay people to maintain a "good + fast + quick to make changes" site.

There's an argument to be made that if business would just simplify their needs and desires to make sure everything is simple and fast, isn't that in and of itself putting devs before users? This works both ways.

Also, if you don't want to pare down your features to barebones, and you're not going to use a framework, someone's inventing one. If you have someone who's going to build you a superfast framework and be a cool hacker, then you probably can't afford them, or you can't afford to keep them. Then we get a post on HN about how bad this one coyboy coders's framework was and all the effort that was spent to modernize using %modern_framework%.

<comment><USER8> If this is true, then why does it take so many engineers to make web sites today?

People keep claiming these things increase productivity, yet there seems to be very little evidence of productivity increase.

<comment><USER9> +1. For example, according to one of their job listings[1], Twitter currently has 25 people working on the main twitter.com experience.

Twenty-five people! For a Twitter client! And they're still trying to hire more! (Important to keep in mind: this doesn't include any of the people working on the database, or the advertising algorithm, or the server architecture, or any of the other hard problems Twitter faces. This is just the team that writes the JavaScript code that takes the Tweets from the JSON API response and puts them onto the screen.)

[1] [https://careers.twitter.com/en/work-for- twitter/201910/twitt...](https://careers.twitter.com/en/work-for- twitter/201910/twitter-com-senior-javascript-engineer.html)

<comment><USER10> I'm shocked it's only 25. I would have expected an order of magnitude more given the number of features and sheer reach of Twitter. That can't possibly be right.

Not sarcasm btw. I think you're underestimating how much work there is.

First, there are a ton of features: lazy-loading tweets, retweet, favorite, lists, all the stuff related to analytics, settings. Simply maintaining that stuff with security updates and bugfixes is a significant commitment.

Then there's accessibility and localization to consider.

Next there's fix and feature experimentation. They probably don't release new features and fixes to everyone at once. Instead they roll them out slowly, or show different versions to different users, compare, analyze and iterate.

Browsers update approximately every 6 weeks, so that's something to keep abreast of. At Twitter's scale, a CSS rendering bug that affects 0.1% of sessions will be seen by hundreds of thousands of users.

And it's not just "a Twitter client". It's THE Twitter client - the canonical one. It has to have higher standards of performance, quality, and reliability than a random Twitter Android or iPhone app.

<comment><USER11> > Then there's accessibility and localization to consider.

For anyone unaware, Twitter's whole UI changes to support right-to-left languages, not just the text.

</comment></comment></comment></comment></comment><comment><USER12> I find this development incredibly sad. Originally, SPAs looked promising from a technical perspective because they could potentially eliminate lots of redundant server-side HTML rendering and duplicate transmission of data (because templates, code and data items could be cached on the client and assembled as needed).

Today, we somehow seem to have gotten the worst of both worlds: We got the additional overhead of client-side rendering but we can still not reliably cache data, so not a lot of processing or bandwidth can be saved.

<comment><USER13> For me the main appeal to SPAs are testing oriented. Assuming I need some kind of interactive functionality that can't be done using a form, testing across the browser interface is difficult when doing HTML view production on the server side. If you are doing HTML view production on the client side, suddenly it's much easier. I test that the server produces the correct data given a request and I test that the client renders the correct views given the data. In Michael Feather's parlance, I've got a viable "seam" for testing against.

<comment><USER14> But if something can be done with links and forms, SPA makes it harder to test. So I prefer using JS only for islands of interactivity within specific pages, not making the whole application one big island.

</comment></comment></comment><comment><USER15> I originally started my career as a Rails developer, and for the last few years have been doing more frontend JavaScript (React), as that's where the €€€ is. For all of the projects I've worked on, server-side rendered Rails would have been a much better stack choice. It would have been quicker to develop for, easier to hire for, and more performant to the end user.

Now I'm not trying to say this works for everyone, maybe when you get to unicorn scale it makes sense to do something different, but these are small projects with no more than a handful of developers. Hiring React developers is easy, hiring Rails developers is easy, but hiring developers who know both well is much harder.

Most of the projects have been for pre-revenue startups, so what's important at that stage is speed of development. You really can't beat Rails for development speed of CRUD applications (which let's be honest, most apps are), and then you can add a sprinkling of JavaScript on top for some modern features (and with something like react-rails you can easily integrate React). If at a later stage you need an API for mobile applications, Rails makes that easy (you can even share the same code for API endpoints and regular HTML views).

In terms of performance, at this stage of a company you can get pretty far by horizontal scaling. Rails is a fairly mature framework, so it's easy to maintain and isn't going to introduce any breaking changes anytime soon - compare this to one of the projects I worked on, which is stuck on React 15 with vanilla JS and probably will never be upgraded.

Now just to repeat I'm not saying this works for everyone. Another project I recently worked on was a React + Typescript app. There was already an existing GraphQL endpoint and it needed a lot of interactivity, so Rails wouldn't have been a good choice here. But for a lot of projects I'd say that server-side rendered Rails is a better choice. it may not be sexy anymore, but if you are a startup and want to get something done fast and for it to be maintainable, it's probably the right choice.

<comment><USER16> I wish more people would think like this. Javascript only gains you in latency if you handle things locally - which _nobody_ does. That means that server- side rendering beats pretty much all SPA's, and somehow nobody cares. And if a client action results in 5 requests, as it often does, then server-side rendering is a _lot_ faster.

Or to put it directly: craigslist is faster than amazon.com. And, frankly, more fun to use.

</comment></comment><comment><USER17> Html is a language. CSS is a language. JavaScript is a language. You can build the Dom by loading html, and you can build the Dom by making calls from JS. You can write style rules against a selector using CSS, or you can write some declarative JS that looks almost the same but with more commas and fewer semicolons. Going back to the good-old-days isn't going to save you since the language is incidental.

Anyone who puts up their first Gatsby site is going to be amazed by how fast the performance feels. They certainly won't be wishing they'd burned their JS stickers.

My biggest problem with the article is that it ignores the cost of "putting users before devs". Writing the simplest, most performant iteration of a site that matches the minimum requirements as you perceive them for today's users isn't that expensive. But that approach crumbled quickly as parameters change slightly. You're one bad focus group or new CEO away from needing to completely rebuild from scratch, except you'll probably need to keep maintaining the old site forever. Then the new site when it becomes the new old site. Then the next one. Repeat until your increasingly-expensive business is completely unviable.

<comment><USER18> CSS is a dystopian nightmare from a Lovecraftian dimension of metaphysical horror.

I had to do a teeny-tiny bit of CSS work before Christmas and I literally had to look up the edge cases and exceptions for all of the five common CSS statements I ended up using, because they were all context-dependent in insane ways - endless "This only works if XXXX is also applied here, but does nothing/fails silently if it isn't, even though you might expect it to work, and this mode is only documented on StackExchange etc because the official CSS docs are incomprehensible and no one ever reads them anyway. And by the way, you'll also need a file of resets for many of the most common options."

[https://www.w3.org/Style/CSS/current- work](https://www.w3.org/Style/CSS/current-work)

<comment><USER17> Well... yeah.

I'm much happier using some css-in-ts solution, because then I can use stricter types against what I define. No need to track down why my `background-colour` isn't doing anything somewhere, or setting up some separate tool to validate it.

While we're looking at cultural problems, this view of style-work as somehow being easier/lighter/less-important/etc. vs the "real" code is at the root of so many of these problems. It's very fashionable to praise functional programming and all the virtues of being declarative, yet we can't connect that with good practices for style.

</comment></comment></comment><comment><USER19> The author makes a very weak argument, not even listing any examples. There is no modern framework that is 2-3MB, that is absurd. The whole point of SPAs is to increase performance. Sure there are sites with horrible implementations of SPAs where loading the page triggers a second refresh ( _cough_ spectrum.chat _cough_ ) or that are just outrageously slow (eg. gmail), but those are certainly not the majority, and are caused by poor engineering, not the framework. Poor performance is more often caused by ads (ever surf the internet without adblock?), tracking, unoptimized images, poor client-side rendering, etc.

Although web performance is certainly a problem, the bigger problem with the web in my opinion is actually poor UX. Often when I'm on a website it's very confusing how to figure out how to do basic tasks like finding the search bar. Medium has the most appalling comment system I've ever seen, requiring 3+ clicks/refreshes to read a comment on an article.

Although I agree the web performance is a serious problem, this is a very weak article, and I'm surprised it's on the front page. I guess people will upvote anything that complains about web performance, no matter how poorly reasoned and misplaced the blame is.

<comment><USER20> The median desktop site is almost 2MB. [https://httparchive.org/reports/page- weight](https://httparchive.org/reports/page-weight)

<comment><USER21> That includes resources like images, videos etc.

Javascript is 1/5 i.e. 420KB

<comment><USER22> The linked Medium article is over 3MB, almost 2MB of that being JS.

<comment><USER23> It's not the UI framework that's adding the bloat, it's a bunch of tracking and fingerprinting scripts. They would still be there even if the UI was server-rendered HTML, because that's Medium's business model!

</comment></comment></comment></comment></comment><comment><USER24> People are not using frameworks because they are fun. That is because _using frameworks is in no reasonable way fun_.

I would argue that developers who aren't having fun are going to create bad products. They certainly are not going to push themselves or be particularly creative. I further don't believe for a second that the utility of libraries like moment.js (and the many improved children it inspired) has anything to do with maximizing "fun". Depending on your objective and perspective, they make the job tolerable and/or possible with far fewer bugs than would exist if you tried to build something from scratch.

I do have good news for everyone, however: you can use tools like Stimlus Reflex (Rails) or LiveView (Phoenix) to build reactive UIs that require none of the heavy client libraries slowing down your pages. Using these tools is simpler, faster and indeed more fun because you're managing state changes on the server and only delivering the bytes that have changed.

Here's a reactive tabular data navigator that supports sorting, filtering and paging without any app-specific JS code required, period. Total JS payload is 54k over the wire, and to be clear... that's for every example on the site.

[http://expo.stimulusreflex.com/demos/tabular](http://expo.stimulusreflex.com/demos/tabular)

<comment><USER25> Maybe it's because I'm at work, but wherever I click on the site, it won't work - neither on Firefox, nor on Chrome.

(No TODO items are added, no sorting will be invoked, no chat message is submitted and no tabs can be changed).

<comment><USER24> That is _very_ strange.

Do you have websockets disabled at the firewall level or something? Do you see any errors in the console?

I am strongly invested in helping you get this working, so consider me willing to help and highly appreciative.

<comment><USER25> Yeah seems you are right. Can't connect via websockets. Console output:

Firefox can't establish a connection to the server at ws://expo.stimulusreflex.com/cable. action_cable.js:241:25

<comment><USER24> I don't like to punt, but this seems like perhaps it's on your end. Thankfully, we haven't had other complaints of this nature and it sounds like perhaps you have a security layer (firewall, browser plugin perhaps) that is not giving you a neutral testbed.

One surefire way to tell is to try the site in Incognito Mode. You could also try on your phone, although admittedly most of the demos are still slanted towards desktop interaction. That's 100% on us and not the tech itself.

</comment></comment></comment></comment></comment><comment><USER26> Is it just me, or has anyone else sensed a shift _back_ from thick SPAs to Server-side rendering precisely because of performance?

<comment><USER27> So much of the backlash is due to the simple (but very significant) confusion between web pages and web apps.

No one should build a web _page_ as an SPA with JS. Most web pages are ideally suited for static site generators. Just abiding by this simple rule would make life vastly better for users.

By the same token, it would be relative folly to try to build a chat client using server-side rendering. It _can_ be done, but a chat client, like a spreadsheet or email client, are all proper _applications_ , and so are ideally suited to being built as SPAs.

There are some projects that lie in between, and in my experience, these usually work out best if coded using a server-side framework with a tiny amount of client JS for UI tweaks. Reddit is a good example of this. Reddit has become significantly worse once re-coded as an SPA.

As for the whole idea of building web apps _without_ using frameworks: I lived in the era and did just that. Usually, the result was a total nightmare, with a rat's nest of jQuery and various other crap. If you were lucky, you worked for a company that knew the value of abstracting out common features and using a pattern such as MVC or MVP. In that case, you end up with what's more or less a framework by the end, and indeed, most large companies and consultancies had their own in-house client-side frameworks. If you're doing that, it makes sense to open source the framework to share the burden with other companies.

The real complaint seems to be the _misuse_ of client-side frameworks. But this is a function of junior devs and poorly-trained devs misusing a framework, not the framework's fault. Such developers would make even slower apps without a framework, believe me. Only it would be be a rat's nest of unorganized spaghetti code.

<comment><USER28> You have pretty much nailed it.

</comment></comment></comment><comment><USER29> The page mentions the "re-imagining of Hacker News", which was actually built.[1] Were they serious?

[1] [https://interface.fh-potsdam.de/future-retro/HN/](https://interface.fh- potsdam.de/future-retro/HN/)

<comment><USER30> Do they have to be serious? To me, this is the playful sort of thing you would see on the "old internet" that people miss.

</comment></comment><comment><USER31> I wish the author had included an example instead of just going after a straw man.

There are lots of devs out there that don't know what they're doing or aren't permitted time to optimize their apps. Frameworks are a tool that can be used and misused.

</comment><comment><USER32> _I fully believe a lot of developers and software enginers put their job satisfaction above their users or customers._

I agree wholeheartedly the web on average is getting more bloated.

But as a counter point: My own job satisfaction derives from delivering an amazing and snappy experience to end users. And I'm sure there are others like me out there!

</comment><comment><USER33> I have heard this rant too many times. Other comments in this thread are also just adding to the rant or trying to justify SPAs.

Can someone please suggest some alternatives.

<comment><USER34> Don't worry about the fud these people are spreading and use the tool you know to get the job done. If that is ruby on rails using templates with plain html and css do that, if it's react do that. None of this worrying about "bloat" matters, just get it done.

The two most successful chat apps in the world today are slack and discord and they use react and electron on the desktop.

<comment><USER35> Slack is not "successful". Slack is a for profit business bleeding money is slow and still not seeing adoption by many major corporations.

How many Slack users are on the free plan?

<comment><USER34> An app can be successful on many metrics, profitability is not the only one. Slack is successful in that it has 10 million daus, 85000 paid users, and it managed to have the company valued at 12.4 billion dollars.

Ignoring the valuation of the company I would consider any program with 10 million daus to be successful.

And funny enough 10 million people choose to use slack and 14 million choose to use discord over irc every day despite the supposed "bloat" of the software.

If you are a developer building an mvp and the thing you are worrying about is "bloat" I will put money on you not being successful.

<comment><USER35> There is no definition of success for a for profit company accept profitability. Anyone can sell a bunch of dollars for 95 cents.

And as far valuation, Uber and Lyft both have multi billion dollar valuations and are both losing billions a quarter.

<comment><USER34> Regardless of your quibbling, if the creators of slack and discord decided to not use modern web frameworks to build their software they wouldn't exist.

<comment><USER35> You think Slack was ever undercapitalized to a point where they couldn't hire both Mac and Windows developers?

Companies have been producing both native Mac and Windows software for over 35 years.

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> I don't agree with this, really in any sense at all. Firstly, you could argue that using battle-tested projects with thousands of hours behind them can yield you better performance, as well as reducing training time because more new employees will already have the necessary skills. It also tends to be better for accessibility than roll-your-own.

Secondly, the article completely forgets to mention what really causes slow down: loading sources from multiple third party domains, especially bulky ads, tracking, and popover scripts.

</comment><comment><USER37> The reality is we (web and other developers) tend to waste end-users time way before raw performance is perceieved as an issue. Take for instance medium.com where you are expected accept complicated terms and conditions, and then give away your facebook account or google account, after which you are prompted with some kind of survey and then there a good chance you will be asked for money ;) all of this is the norm for the web.

</comment><comment><USER38> Comes down to incentives. Why would the agency or SME dev care about the end user? Will they get rewarded if they do? Nope. Dev salarymen are concerned, rightly, with their careers. This is why they do stuff like make a brochureware website that should be dead-simple into some demented chimera of 5 different "best practice" frameworks, submerged in 10 feet of technical debt to boot. They do so because they can put that stuff on their resume, which will (for management and recruiting incompetency reasons) get them into a better job next year or month. To hell with the devs who follow them, and to hell with the client, customer, or end users in general - they ain't me. But the solution is to modify incentives, not to indulge in the sperg-outs our profession is infamous for, since those are only "I'm cleverer than you all" rants, which are again, "me first".

</comment><comment><USER39> I understand the pressure on js frameworks and the like. Even Microsoft attacked the same problem with Blazor. But the original goal of these frameworks is and still is portable code. I might be the rare engineer whose work flow is accelerated by these frameworks, but I also carry an approach to creating well patterned interchangeable components. And by and far I believe that is the real issue in the industry.

However if we are talking about speed. I do agree. But that is because to me it is madness to have these frameworks sitting on the main thread. And should be concurrently offloaded to a worker. Reactor's concurrent mode is also a great stab at this problem. Howver I believe the point is missed.

Being the only bindings a framework should have on the main thread is it's interactions with the dom. Everything else, including the virtual dom should be on a different thread.

So while I understand the push back, I believe people are missing the point. These frameworks have been implemented in the easiest fashion and have matured. But now that we can rely on multiple cores and ht. There should be a response.

Not to mention Web Apps vs Web Sites. We need to make that distinction, especially in line with wasm now being matured.

Edit: As for serverside rendering. If your backend engineer can't figure out how to cache this. I question the hire.

<comment><USER40> The reason frameworks usually don't run in a worker thread is because it is difficult to efficiently cross the barrier between workers and the main thread. Either you need a shared array buffer or the contents of your messages have to be copied on write. Even web assembly has similar issues as it runs in the same thread as any JavaScript you have.

I do agree about making the distinction between sites and apps though. A lot of the contortion frameworks do is to avoid triggering layout excessively. You can't even get the position of a DOM element without layout rerunning to figure out where it should be. I suspect a lot of these quirks are legacy web behaviors more applicable to sites than applications.

<comment><USER39> I've done some experiments in regards to a message service. And though a lot of this work isn't ready for production I have seen a lot of success. Long story short SSR to rebind via webworker. Unfortunately it's just one of many experiments that are way back in my todo list now.

</comment></comment></comment><comment><USER41> I'm glad I'm not alone. Burn your JavaScript stickers.

</comment><comment><USER42> Building online blog for the millionth time is boring and using a new framework makes it less boring - that's the main reason there is a new cool JS framework every six months

</comment><comment><USER43> What most JS frameworks like React and Vue got and get wrong is their runtimes, meaning that a good designer/developer experience scales with the amount of code that is shipped, an anti pattern because that it can be done better as demonstrated by Svelte, which by being a "web compiler" basically decouples the DX and production code. It's the real deal for webdev, going back to React or Vue feels awkward after using Svelte.

</comment><comment><USER44> From the article's detractors I learned that while things are bad, they get the job done and we get paid, no problem. Yet faster loading does increase conversion and profit. Not to mention users will love a product that feels good. A good work organization is more beneficial than finding your way around someone else's organization (the mega frameworks). Can any manager who also loves quality chime in? Thanks.

</comment><comment><USER45> The counterpoint is, who are we to say that "performance" matters. Certainly for things like search, yes. But much of the time, features matter more. Frameworks happened because they allowed engineers to iterate more quickly, which allowed PMs to find the set of features that work for users. We are, after all, still using JIRA.

</comment><comment><USER46> A blog post talking about performance but showing no numbers to prove the point? Questionable.

HTML, CSS and DOM manipulation all by itself is already a performance trainwreck. CSS layouting is ridiculously expensive.

The actual framework overhead is usually negligible, especially when considering that writing "optimal" vanilla code is not something that people actually do, or when they do it is a security risk (setting innerHTML without sanitation).

The point about 2-3MB bundle sizes isn't valid either, no framework that is any good has more than a few dozen of kilobytes extra payload.

</comment><comment><USER47> Rule 0 should always be the one from Tron: Fight for the users.

In this case, "if the user isn't gonna need it, don't bother."

</comment><comment><USER48> Speed is the number one feature. SPOs are the antithesis of fast.

[https://twitter.com/gravislizard/status/927593460642615296](https://twitter.com/gravislizard/status/927593460642615296)

<comment><USER49> Actually, features are the #1 feature, and the slow performance of the web proves it.

</comment></comment><comment><USER50> test

</comment><comment><USER51> I wanted to call out Patreon for one of the slowest web applications today. Guys: click on developer tools and watch the paint dry.

</comment><comment><USER52> As a developer I'm much less comfortable working with JS frameworks. It seems like each one tries to hijack the JS experience and create its own.

Does anyone have experience writing SPA/PWA without frameworks? I'm interested in the idea of minimal JS even at the cost of productivity.

</comment><comment><USER34> This article contradicts itself and it doesn't actually describe how frameworks destroy web performance.

I can easily make websites that will rank 100 on google pagespeed insights using React.

The bloat and slowness of modern websites is not from javascript and any frameworks.

</comment><comment><USER53> While I completely agree with most of this article. I think some of it is untrue. A lot of the new functionality is needed for a increasing amount of apps.

For example, I work on an app which wouldn't be possible on the web 5-10 years ago. It's a single page app because it needs to be. It uses a lot of javascript making many requests because we have to and the customers requires it. We could probably make it a lot faster, the issue is that the amount of functionality that we are trying to include in a short amount of time leaves us no other choice than to include yet another library etc.

I know this case maybe isn't the kind of app the article is targeting. But I think even "simple" apps today often include some part of complexity that would be hard(er) to do in a "old style" multi page app.

That being said, I use a lot of old style apps. I use the old reddit instead of the horrible new one. I use HN, I use fastmail so I do think speed is very important.

<comment><USER12> > _A lot of the new functionality is needed for a increasing amount of apps._

Could you make a few examples?

> _It uses a lot of javascript making many requests because we have to and the > customers requires it._

Why couldn't the requests be done by the back-end?

> _But I think even "simple" apps today often include some part of complexity > that would be hard(er) to do in a "old style" multi page app._

Absolutely, but isn't that exactly the point of the article? Working with a framework can make development massively easier - however, the benefits of this only go to developers, while users have to bear the costs.

<comment><USER53> > Could you make a few examples?

Sure, not in any particular order (and there's a lot more)

1\. Users can use drag and drop functionality on areas, making updates to the backend as they are moving stuff around. To have the webpage reload would not be an acceptable experience.

2\. File management. Users can upload files and create folders, refreshing the page after every update wouldn't be nice.

3\. Users can retrieve data on many objects. Open specific objects and see it's data in popups. Edit the data, add comments, upload images etc. Wouldn't work very well with a refresh.

> Why couldn't the requests be done by the back-end?

When the backend can do the requests, it does. I meant doing requests to our backend and to static resources.

> Absolutely, but isn't that exactly the point of the article? Working with a > framework can make development massively easier - however, the benefits of > this only go to developers, while users have to bear the costs.

Not really. I am saying that many new apps aren't simple crud apps anymore.

<comment><USER54> What part of that do you think wasn't possible on the web 5-10 years ago? The term "ajax" is 15 years old now.

<comment><USER55> It's not that it wasn't possible, but it was really fiddly keeping the HTML up to date with all state changes, and having the rendered template match up with what the JavaScript wanted to do.

I ended up having to cut a lot of features to make projects happen on time, and adding a new complex feature to an existing site coded with unobstrusive JavaScript was always felt like a full rewrite.

Doing it with React though is like being back to working with desktop GUIs. Anything you want we can do.

In the older days, anything that had to be a complex webapp would be easier done as a java applet, or a flash app.

</comment></comment></comment></comment></comment><comment><USER56> This is all over the place and doesn't really present a coherent argument.

The author complains about developers who "want to show off" and then derides the use of frameworks. But showing off would mean _not_ using off-the-shelf solutions, and instead trying to hand-craft everything.

The author complains about how frameworks bloat the page, but react + react- dom, as of version 16 (the most recent measurement I could quickly Google), weighed in at 109 kb (34.8 kb gzipped). Sure, client-side rendering means you wait for the JS to bootstrap before you get to see content, but React also has good support for doing initial renders server-side.

It feels like the author just spilled out his or her assumptions and prejudices without examining or researching them at all.

<comment><USER57> The author is right. It just sucks to read what's true. He's not entirely right but he's on the right track.

You'll find a lot of tiny companies with dev. blogs where they explain in- depth the scaling strategy of their unknown, sporadically-used product.

Yes, react and vue are a few hundred kb gzipped. But are we seriously going to pretend that projects built with react are in a few hundred kb range? You can't even predict how big a project will be. It's not react's or vue's fault, it's simply how it is - add assets, add css, add additional libraries for <insert reason here> and it's not unrealistic to get 2-3 MB that you need to download.

A lot of people are designing their products to show off to their peers or for google (SEO). Users get left out. And we (users) are starting to feel it. Heed the warning or turn the blind eye.

<comment><USER55> In the good old days, there were plenty of terrible user experiences built with traditional technology. All of those apps failed to make a mark in people's memories and have been forgotten.

I do remember stuff built in Frontpage breaking terribly if you resized your browser. I remember Joomla outputting reams of html that the browser would choke on the nodes. I remember doing chat apps via iframes and long polling. It was all there.

Better technology has only lead to better outcomes on both the low and the high end, and it's a lot easier to debug and fix the low quality outcomes.</comment></comment></comment>


A self contained and full functional Spyderlib Mac app - <AUTHOR> http://code.google.com/p/spyderlib/issues/detail?id=697

<comment><AUTHOR> You'll find the .dmg file in the download section: <https://code.google.com/p/spyderlib/downloads/list></comment>


Google signs up three schools for Chromebooks - <AUTHOR> http://9to5google.com/2011/08/25/google-signs-up-three-schools-for-chromebooks/

<comment><USER2> Good luck to these schools. Google still needs to learn how to do customer service (do they believe in it yet?), and if there's any constant in the universe, it's that _nothing is constant_ (ie, shit breaks).</comment>


Japanese Lucky Almanacs and Their Knockoffs - <AUTHOR> https://uniqueatpenn.wordpress.com/2016/10/05/japanese-lucky-almanacs-and-their-knockoffs/ <comment><USER2> So it's like Tong Shu? The more I looked into Japanese culture, the more I found Chinese culture in it.

</comment><comment><USER3> Why does this show in the HN landing page if it was submitted over 2 hours ago and only has 3 likes while there are other articles with more points that have been submitted sooner?

<comment><USER4> I believe the points shown are upvotes minus downvotes, but the ratio of upvotes to downvotes probably affects the ranking of a story too.

<comment><USER5> Stories can't be downvoted, only flagged. More likely it was lifted by the mods for being a good article, which I think it is.

<comment><USER6> Since when do mods "lift" articles? Is there some evidence for that?

<comment><USER7> I don't have a source, but I've seen this referenced before and I don't think it's a secret.

Also, IIRC there's a (hidden) modifier based on domains that artificially moves submissions up or down the rankings. Suffice to say that article ranking isn't just a function of time and votes.</comment></comment></comment></comment></comment>