New finding may explain heat loss in fusion reactors - <AUTHOR> http://news.mit.edu/2016/heat-loss-fusion-reactors-0121 <comment><USER3> Note what is required to do something like this:

You need to solve a 5-dimensional (+ time) nonlinear integro-differential equation. Not only that, but you need to keep it going for a long enough time for turbulent fluctuations to average out, and cover both ion and electron scales (that last bit is the big new contribution here).

And once you're done with that, you need to repeat it at even higher resolution as evidence that what you're seeing is physical.

Bravo!

<comment><USER4> I know some of those words. Anyone have a ELI5?

<comment><USER5> Take a simple differential equation as an example, like dy/dx = x. To solve this we need to find a function y(x) whose derivative is equal to x. This particular differential equation is well-behaved, and the solution is simply 0.5*x^2, which you can verify using basic calculus.

Not all differential equations are nicely behaved. Many do not have analytic solutions at all, meaning that we can't even write down a function that satisfies the equation. However, such equations can still be solved approximately using computational techniques. This can be incredibly difficult and computationally expensive (note the huge resources required to achieve this breakthrough) but can produce very useful results.

<comment><USER6> How many 5 year olds do you know that understand "well behaved differential equations" and derivatives?

<comment><USER7> ELI5 is not for actual 5 year olds.

<comment><USER6> Agreed, but I was implying that he didn't simplify it nearly enough. I actually understood the parent post more clearly than this ELI5 version.

<comment><USER8> The real math that describes the behavior of fusion reactors is too complicated to actually carry out, so physicists have to make some simplifying assumptions. They try to choose assumptions so that the results they get are still valid, kind of like when you say, "Keep the change" at the grocery store. You assume that giving up small amounts of money on occasion won't make you go bankrupt, even though you're not actually adding it up all the time to keep track of how much you've given up.

It turns out that one of the simplifying assumptions that physicists have been making over the years _does_ change the result. Giving up the "spare change" _does_ make you "go bankrupt." In this case, ignoring small-scale turbulence makes you lose a significant amount of heat. But figuring that out required some really hairy math and a butt-load of computing power.

Is that simple enough for you?

<comment><USER6> Yes! That was _way_ better, thank you!

<comment><USER8> You bet.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> MIT article this points to: [http://news.mit.edu/2016/heat-loss-fusion- reactors-0121](http://news.mit.edu/2016/heat-loss-fusion-reactors-0121)

<comment><USER10> Ok, we changed to that from [http://futurism.com/nuclear-fusion-breakthrough- mit-experime...](http://futurism.com/nuclear-fusion-breakthrough-mit- experiments-help-reveal-source-heat-loss/). Thanks!

</comment></comment><comment><USER11> I'm always suspicious of "breakthrough" announcements when it comes to fusion, especially ones that originate from a college's PR office. Can someone put this in context for us? Is it a big deal?

<comment><USER12> It's a theoretical breakthrough that explains an unexpectedly bad behavior of current designs that was not understood so far: a discrepancy between theory and experimental observations.

Now that the model is fine enough to explain the turbulences observed in the experiments one might hope that this will help suggest design changes to better deal with the turbulences. However the MIT article does not suggest any practical design modification yet.

<comment> semi-extrinsic It is a hard thing to write the code for and then run a simulation of coupled plasma turbulence taking 15 million CPU-hours to explain a phenomenon.

But it is another thing entirely to take such a huge simulation and try to use many of them to do tokamak design optimization.

<comment><USER13> I would be curious to know the process for even modeling this sort of thing. How do they know they got it right? How accurately does this model existing experiments? Im also wondering if they model to a result vs modeling to what should actually be happening. Would anyone learned on this subject please chime in? I've always wondered how modeling these types of complex systems works.

<comment><USER14> > I would be curious to know the process for even modeling this sort of thing. > How do they know they got it right?

It helps that the model creates the same outcomes as the actual observations (and the old model didn't). This isn't an ironclad guarantee that the model reflects reality, but it suggests that we're moving toward a more accurate reflection of nature.

> I've always wondered how modeling these types of complex systems works.

To explain I will use a simpler example -- weather forecasting. In weather forecasting, we need to model the atmosphere. It's not possible to model the entire atmosphere directly, instead we break the atmosphere into a bunch of cubes, each with an initial temperature and humidity and a few other things.

Then we process the cubes in a supercomputer consisting of many processors running in parallel -- one processor per cube. The actual computation consists of seeing what effect a cube's neighbor's pressures, temperatures, etc. have on the tested cube, for a brief interval of time. Then we repeat the process for another slice of time. _Ad infinitum._

This is obviously a numerical process, with no overarching equation that explains it all, but with some basic first principles at work (a theme in modern physics). Such a process becomes more accurate if we can create more, smaller cubes, and for that we need more and faster processors. So most of modern supercomputer design involves thinking of ways to acquire more and faster parallel processors.

The kind of model that led to the discussed result follows the same basic pattern. The irony is that the most often cited reason for having supercomoputers -- to be able to say whether it will rain 72 hours from now -- is also the least likely to succeed, because of the role played by quantum mechanics (i.e. by chance processes) in earth's atmosphere.

<comment> semi-extrinsic Some corrections/nitpicks on your weather forecasting example:

* there are most definitely some overarching equations that explain it all. We just can't solve them analytically. But we use them to write the code.

* when you say "one processor per cube": if you mean cube = grid cell you're way off. You want to have at least ~ 10 000 grid cells per processor to have any level of performance.

* it is definitely not quantum mechanics that makes weather hard to predict. It's what's popularly called "chaos", or mathematically, "exponential sensitivity to variations in initial data".

* getting more performance for this type of application is not about getting more cores, it's about getting more memory bandwidth. That's why e.g. GPUs are useless for speeding up weather forecasting.

* funfact: weather simulations today are not running any faster than in 1994; it's at about 15 minutes per simulation. The increases in computing power are used to a) increase grid resolution and b) run more replicas.

* The last point is what makes modern weather simulations tick. You don't run one simulation, you run 1000, each with slightly different initial data, and you analyse the ensemble results.

<comment><USER14> > * there are most definitely some overarching equations that explain it all.

Not so, not for Earth's atmosphere, the topic I was discussing. There are first principles, but no overarching equations, analytically expressible or not. Prove me wrong -- show me the equation that tracks arctic temperature, rainfall, and snow cover, including the feedback effects that join them all, _as an equation_.

> * when you say "one processor per cube": if you mean cube = grid cell you're > way off. You want to have at least ~ 10 000 grid cells per processor to have > any level of performance.

It was part of a simple explanation, but in the future, in the name of increased throughput and as processor costs continue to fall, it will be literally true. I say this on a day when the Raspberry Pi Zero is so much in demand that I can't find one for sale.

> * it is definitely not quantum mechanics that makes weather hard to predict. > It's what's popularly called "chaos", or mathematically, "exponential > sensitivity to variations in initial data".

Both play a part. Quantum mechanics is thought to be the final obstacle to long-term weather forecasting, and chaos theory (extreme sensitivity to initial conditions) is the mechanism by which small initial causes lead to large effects.

Your last three point weren't corrections, so no need for comment.

<comment> semi-extrinsic > show me the equation that tracks arctic temperature, rainfall, and snow > cover, including the feedback effects that join them all, as an equation.

The reader is referred to "Chapter IV: The Governing Equations" of Richardson's classical book "Weather Prediction by Numerical Process" [1].

> It was part of a simple explanation, but in the future, in the name of > increased throughput and as processor costs continue to fall, it will be > literally true.

No. You didn't read what I wrote. Unless some radical paradigm shift occurs in both hardware and algorithm design, strong scaling is never going to pay off once you get less than about 10 000 grid cells per CPU. Core cost is not tge issue, power usage over the cluster lifetime is already a huge cost. Memory bandwidth is the issue, Linpack (peak float) performance is so irrelevant even management has started to ignore it.

> Quantum mechanics is thought to be the final obstacle to long-term weather > forecasting

[By whom?][Citation needed]. Of course QM is behind how atoms and molecules behave, but that doesn't mean any QM result will ever improve weather prediction. And, why stop at quantum mechanics? Why not invoke quarks and gluons and the Higgs field if you're going all the way down to fundamental particles?

[1] [https://books.google.com/books?hl=en&lr=&id=D52d3_bbgg8C&oi=...](https://books.google.com/books?hl=en&lr=&id=D52d3_bbgg8C&oi=fnd&pg=PA3&dq=equations#v=onepage&q&f=false)

<comment><USER14> >> show me the equation that tracks arctic temperature, rainfall, and snow cover, including the feedback effects that join them all, as an equation.

> The reader is referred to "Chapter IV: The Governing Equations" of > Richardson's classical book "Weather Prediction by Numerical Process" [1].

I will say this one more time: "As an equation". There is no equation that describes the system I described, there are only algorithms that cannot be expressed in closed form. The fact that they cannot be expressed or solved in closed form is revealed by the language of your reference: "by Numerical Process".

Numerical algorithms are used -- _must be used_ \-- for system that don't have a closed-form solution, i.e. an equation that describes the system. Weather and atmospheric physics are in that category. My specific example -- arctic temperature, rainfall and snow cover -- represents a system that we can't even model with any reliability, much less hope to express as an equation.

Another example, one that surprises many people, is the fact that there is no equation able to describe an orbital system with more than two masses. Those systems must also be solved numerically. ([https://en.wikipedia.org/wiki/Three- body_problem](https://en.wikipedia.org/wiki/Three-body_problem))

> ... but that doesn't mean any QM result will ever improve weather prediction

So? I made the exact opposite claim -- that the effect of QM on weather systems may _prevent_ accurate forecasts past a certain time duration.

>> It was part of a simple explanation, but in the future, in the name of increased throughput and as processor costs continue to fall, it will be literally true.

> No. You didn't read what I wrote.

Who cares what you wrote? You tried to say that 10,000 cells per processor is required for reasonable throughput. This is already false, and it will become more false in the future.

>> Quantum mechanics is thought to be the final obstacle to long-term weather forecasting

> [By whom?][Citation needed].

I didn't make an evidentiary claim, I expressed a commonly heard opinion, so I don't have to provide a citation.

> Why not invoke quarks and gluons and the Higgs field if you're going all the > way down to fundamental particles?

The evidentiary burden is yours to try to support the idea that weather isn't affected by fundamental particles.

<comment> semi-extrinsic So the terminology you are using is what confuses me. You first said "there is no equation describing the system", but now you're expanding this to mean "the equation describing the system has no closed form solution". These are two very different things. Take you three-body-problem example. That wiki page lists a set of coupled second order ODEs that completely describes the system. Yes, we must solve it numerically in the general case. The system is still described by an equation (or three), don't you agree?

> You tried to say that 10,000 cells per processor is required for reasonable > throughput. This is already false, and it will become more false in the > future.

Can you show me a strong scaling plot for any PDE solver that shows good scaling significantly beyond 10k DOFs per processor?

> the effect of QM on weather systems may prevent accurate forecasts past a > certain time duration.

No, and there are two reasons why, one practical and one fundamental. Practical first: The key here is that "exponential sensitivity to initial conditions" means you have to have precise measurements of the weather at close to the scale where QM is significant before QM can have an effect. To even think about approaching a description of that precision would require measurements of wind, temperature etc. at a grid resolution of much less than 1 mm. Leaving the huge practical problems with a measurement like that aside, if you were to measure with an (insufficient) 1 mm grid just air velocity and temperature for the Continental US, the data storage required would be 1 000 000 000 000 000 Terabytes of data for a single point in time. This is 1 000 000 000 times the total storage capacity of the largest supercomputer in the world. For a single second, and what you want is a time series spanning many days. And you're not even beginning to approach the regime where QM becomes important, that would require a storage capacity 10^18 times larger than this already absurd storage capacity. We're talking about 10^30 Terabytes of data at each instant in time!

The other and more fundamental objection to your assertion is the vast discrepancy between the Kolmogorov length scale, i.e. the smallest scale of variations in the flow, and the scale of QM. The Kolmogorov length scale for atmospheric motion lies in the range 0.1 to 10 mm. At scales much smaller than this, such as in QM, the flow is locally uniform everywhere.

<comment><USER14> > So the terminology you are using is what confuses me. You first said "there > is no equation describing the system", but now you're expanding this to mean > "the equation describing the system has no closed form solution".

 _There is no equation that describes that system_. Which part of this is confusing you? A numerical algorithm is not an equation. My other example, easier to grasp, was the three-body problem -- the existence of a numerical solution doesn't mean there's an equation that describes a three- (or more) body orbit, quite the contrary (it has been proven that no such equation can exist) -- such orbits must be solved numerically, and there is no overarching equation, only an algorithm.

The presence of an algorithm doesn't suggest that there's an equation behind it. Here's another example -- the integral of the error function used in statistics. It's central to statistical calculations, there is no closed form (i.e. _no equation_ ), consequently it must be, and is, solved numerically everywhere. This is just one of hundreds of practical problems in many disciplines for which _there is no equation_ , only an algorithm. Reference:

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

We can locate/identify prime numbers with reasonable efficiency. Does this mean there's an equation to locate prime numbers? Well, no, there isn't -- there's an algorithm (several, actually).

We can compute square roots with reasonable efficiency. Does this mean there's an equation that produces a square root for a given argument? As Isaac Newton (and many others) discovered, no, there isn't -- there's an algorithm, a sequential process that ends when a suitable level of accuracy has been attained.

I could give hundreds of examples, but perhaps you will think a bit harder and arrive at this fact for yourself.

> To even think about approaching a description of that precision would > require measurements of wind, temperature etc. at a grid resolution of much > less than 1 mm.

Your argument is that, because we can't measure the atmosphere to the degree necessary to associate changes with the quantum realm, we therefore can rule it out as a cause. Science doesn't work that way. Remember that I didn't say it was so, I said it was a matter of active discussion among professionals, as it certainly is.

> At scales much smaller than this, such as in QM, the flow is locally uniform > everywhere.

What an argument. It says that, even though at larger length scales, there is turbulence that prevents closed-form solutions (and in this connection everyone is waiting for a solution to the Navier-Stokes equations, which may ultimately be a pipe dream), but as the length scale decreases, things smooth out and become uniform (I would have added "predictable" but you had the good sense not to make that claim). This contradicts everything we know about nature in modern times, and contradicts the single most important property of QM.

> Can you show me a strong scaling plot for any PDE solver that shows good > scaling significantly beyond 10k DOFs per processor?

Would you like to make the argument that, as time passes and as processors become less expensive, faster and more numerous, any such argument isn't undermined by changing circumstances?

This paper (PDF warning):

[http://www.shodor.org/media/content/petascale/materials/UPMo...](http://www.shodor.org/media/content/petascale/materials/UPModules/beginnersGuideHPC/moduleDocument_pdf.pdf)

Makes the unsurprising argument that, as time passes and as processor costs fall, matrices are broken into more and more, smaller, parallel subsets in the name of rapid throughput (with appropriate graphics to demonstrate the point). The end result of that process should be obvious, and at the present time, 10,000 serial computations per processor is absurd -- this is not a realistic exploitation of a modern supercomputer. In reality, more processors would each be assigned fewer cells, because that produces a faster result. This is not a difficult concept to grasp.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> On his death bed, Werner Heisenberg is reported to have said, "When I meet God, I am going to ask him two questions: Why relativity? And why turbulence? I really believe he will have an answer for the first."

<comment><USER3> I think that quote is a myth. It's attributed to multiple people.

</comment></comment><comment><USER16> For those asking about an ELI5 explanation, MIT released a video on Youtube that's very clear:

[https://youtu.be/RLI6QW2x4Lg](https://youtu.be/RLI6QW2x4Lg)

</comment><comment><USER17> ... aaand meanwhile we continue to ignore LFTR / Thorium as a present-day practical, demonstrated in the 1960s scalable super safe non-proliferation nuclear energy option that seems to be held up by bureaucracy or lack of patentability.

And from what I've read, don't the fusion reactors also become radioactive from the high energy neutrons in fusion reactors? Yes the fuel isn't radioactive... but they also need to be scrapped/reprocessed after (pulling number out of butt) five years?

<comment><USER18> The idea of Thorium reactors as a better nuclear fuel option, gets proposed frequently on HN. There are real issues with it though. There are reasons why it is not a fuel of choice today, that have nothing to do with conspiracy theories. A small amount of searching will reveal this.

<comment><USER19> You may be right, but without references this is just a content-free sneer.

<comment><USER18> 10 seconds on a search engine will supply 1000's of links to issues with Thorium and LFTR, some of which are high quality and some of which are garbage. Note that the OP did not provide links in support of their position.

<comment><USER20> You have a chance to add more to conversation than the OP, then. For myself, I'd be very interested in two or three relevant links, if you can provide them.

</comment></comment></comment></comment></comment><comment><USER21> I thought we already knew that current tokamak designs were very poor in containing plasma due to unpredictable turbulence — ever since the 90s (I remember writing that in a senior high school-equivalent report on fusion), even. Hence the reignited interest in stellarators.

<comment><USER22> This sounds like telling Edison and that you can't draw Tungsten wires thinly enough to make the lightbulb work, and he should just go back to gas lamps. The whole article was about learning to predict the turbulence. Now that we have some understanding of the turbulence in a tokamak, should we just continue with stellerators anyway?

<comment><USER23> Edison didn't figure out how to draw tungsten. Edison figured out a way to make a cheap lamp without tungsten.

Frederick de Moleyns, who invented the electric light bulb in 1841, had the right idea - use a metal wire with a really high melting point. He used platinum. Worked, but cost far too much. Edison and Swan figured out how to make a cheap electric light bulb, using carbonized paper. There was a long detour through various forms of carbonized cellulose, including paper, bamboo, and extruded cellulose. Bulb life was short and efficiency was low, but it worked. Then there was a brief detour into tantalum wire around 1902. Finally, Coolidge's process for making ductile tungsten wire was developed at General Electric, and thin tungsten wire could not only be made, but worked easily. Filaments could be coiled up into compact forms. Ductile tungsten lamps came out in 1908. That was it. Incandescent lamps didn't change much over the next century.

[1] [https://archive.org/stream/menandvoltsstory00hammrich/menand...](https://archive.org/stream/menandvoltsstory00hammrich/menandvoltsstory00hammrich_djvu.txt)

<comment><USER24> interesting stuff. I'd also add that light bulbs got deliberately worse for a while. [https://en.wikipedia.org/wiki/Phoebus_cartel](https://en.wikipedia.org/wiki/Phoebus_cartel)

<comment><USER25> Did they recover subsequently, though?

</comment></comment></comment></comment></comment><comment><USER26> I'm reminded of the recent interview where Freeman Dyson calls fusion projects 'welfare for engineers'

[http://m.theregister.co.uk/2015/10/11/freeman_dyson_intervie...](http://m.theregister.co.uk/2015/10/11/freeman_dyson_interview/)

</comment><comment><USER27> Billions and Billions of our hard earned cash wasted on this ever continuuing pipe dream - attempting to recreate and then to control a man-made sun, here on earth is truly rediculous - even cold fusion is a better idea than this. I would like to create a factory for small portable nuclear reactors, standard tested proven design with inherent safety molten salt coolent - <USER2> thorium fuel - submarine option, out of site out of mind and protection from weather - desalination and aluminium smelter attachments to fully utilise continuus relaible power.

<comment><USER28> an average of $500 million a year for 60 years seems reasonable to me given the potential reward to society

[https://www.technologyreview.com/s/541636/weighing-the- cost-...](https://www.technologyreview.com/s/541636/weighing-the-cost-of-big- science/)

</comment></comment><comment><USER29> Tangential question: How much of what we learn about fusion in reactors can we apply to understanding the sun/stars or vice versa?

</comment><comment><USER30> As we get closer to "limitless energy" the cynical side of me always starts thinking about the business/political/power forces that will come into play. It's not going to be easy going once we have it.

By analogy: the first fusion reactor is Napster. Obviously the traditional oil/gas co's play the part of the record labels, trying to shut it down. And then who will become Apple/iTunes of the energy industry?

</comment><comment><USER31> Finally something to be excited about!

</comment><comment><USER32> The article at MIT has a few more details.

> simulation required 15 million hours of computation, carried out by 17,000 > processors over a period of 37 days ...

> Now, researchers at General Atomics are taking these new results and using > them to develop a simplified, streamlined simulation that could be run on an > ordinary laptop computer

> they show that this is a general phenomenon, not one specific to a > particular reactor design.

[http://news.mit.edu/2016/heat-loss-fusion- reactors-0121](http://news.mit.edu/2016/heat-loss-fusion-reactors-0121)

<comment><USER10> We changed to that URL from [http://futurism.com/nuclear-fusion-breakthrough- mit-experime...](http://futurism.com/nuclear-fusion-breakthrough-mit- experiments-help-reveal-source-heat-loss/). HN prefers original sources.

</comment></comment><comment><USER33> >A long-standing discrepancy between predictions and observed results in test reactors has been called "the great unsolved problem" in understanding the turbulence that leads to a loss of heat in fusion reactors

>In a result so surprising that the researchers themselves found it hard to believe their own results at first, it turns out that interactions between turbulence at the tiniest scale, that of electrons, and turbulence at a scale 60 times larger, that of ions, can account for the mysterious mismatch between theory and experimental results.

So basically they forgot the fact that a single pebble thrown into a pond causes ripples; or that a candle can light a room? Sounds like they forgot to apply the KISS principle and over complicated things a bit; which I can safely say, I probable do at least once a day.

</comment><comment><USER34> Steve left the door open again, didn't he?

Damnit, Steve. How many times do we have to tell you?</comment>


Ask HN: Why is it called a shell? - <AUTHOR>

Would anyone like to offer how or why the command line interpreter came to be known as a shell? <comment><USER2> Came from Unix. A "shell to the kernel" that only exposed the outer layer.

<comment><AUTHOR> Have a source?

<comment><USER2> Not really, the internet points to this doc: [http://www.multicians.org/shell.html](http://www.multicians.org/shell.html) Where Louis Pouzin of Multics claims to have coined it.

Ken Thompson describes it here [http://v6shell.org/history/unix/unix.pdf](http://v6shell.org/history/unix/unix.pdf)

Looking around, this seems more interesting (implying it is a metaphorical name of a prophet's shell listening): [http://unix.stackexchange.com/questions/14934/why-was-the- wo...](http://unix.stackexchange.com/questions/14934/why-was-the-word-shell- used-to-descibe-a-command-line-interface)</comment></comment></comment>


Building a front end with no JavaScript - <AUTHOR> https://javascript.works-hub.com/learn/a-javascript-free-frontend-61275 <comment><USER2> The date says 9 April 2019, but I swear I've read this article before, I think from HN even.

Ah, it says "Originally published on dev.to." Here you go, lengthy HN discussion from just a month ago...

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

<comment><USER3> Meanwhile the checkbox hack went on to live a life of its own.

</comment></comment><comment><USER4> I feel like it's possible to be way too puritanical about these things. Absolutely, JS bloat is an issue. But JS isn't inherently bad, and removing it can make the user experience worse, not better.

Take HN, for example. The [-] button to collapse a thread is really useful. But if it had to POST back to the server and reload the entire page just to hide a thread I wouldn't use it anywhere near as much.

<comment><USER5> If you disable JS on HN that button goes away, but you can still up / down vote. I like that, I wonder if the [-] could be implemented in CSS though, I feel like it can.

<comment><USER6> Seems like it could be done with a checkbox and some cash. I'm sure someone could figure it out.

<comment><USER7> It could be done using `input:checked + sibling` selector e.g. like this: [https://jsfiddle.net/6bgemn0s/](https://jsfiddle.net/6bgemn0s/)

For something fancier it would be possible to style a label with appropriate for="" attribute and hide the checkbox completely, then even apply some transitions: [https://jsfiddle.net/6bgemn0s/1/](https://jsfiddle.net/6bgemn0s/1/)

<comment><USER8> [https://jsfiddle.net/gaby_de_wilde/ye95zcao/29/](https://jsfiddle.net/gaby_de_wilde/ye95zcao/29/)

</comment></comment></comment></comment></comment><comment><USER9> If you think along these lines but also want some nice realtime interactivity check out the recently released Phoenix Live View which is a very clever system that allows you to push changes automatically to your client based on server rendered template diffing: [https://github.com/phoenixframework/phoenix_live_view](https://github.com/phoenixframework/phoenix_live_view)

<comment><USER10> Yes! I am so excited by this. For those that don't know, Phoenix is a UI framework for Elixir, which is a more productive flavor of Erlang (citation needed).

If you think high reliability and a superb concurrency model is something that might be valuable in a web UI...check out this project! I am desperately seeking a good excuse to build something with this.

<comment><USER11> Small correction: Phoenix is a web framework, not a UI framework.

</comment></comment></comment><comment><USER12> > _Has anyone tried modifying the description of a card in Asana lately? It 's > freaking slow! The UI lags for no good reason as you type._

I'm glad to see Asana called out on this. I swapped form Trello to Asana at the request of a client about 12 months ago. The feature set is comprehensive but performance is bafflingly woeful. I cannot begin to fathom what they're doing that causes my i7 to come to a screeching halt every time I drag a card from one column to the next.

<comment><USER13> The biggest problem IMO with JS and performance is event listeners.

If they setup event listeners on each card, talk, etc. it could easily kill performance.

Turns out this is easily solved by setting up a single event listener on the root element (body, #app, etc.) and then checking the event.target to see what changed.

<comment><USER14> React does this, both for performance and to normalize event behavior across browsers.

</comment></comment></comment><comment><USER15> But you do need JavaScript to read the article about building a front end with no JavaScript...

<comment><USER16> WorksHub dev here. JS (actually ClojureScript compiled to JS) is essential for most of our platform to function, but we're working on server-side rendering of our public pages so that they don't need JS. We've just not rolled it out fully yet.

</comment></comment><comment><USER17> The mentioned "Checkbox/Label Trick" seems to be getting somewhat popular, but that's quite a hack and abuse of HTML semantics. Hacks like that (and this one in particular) lead to issues for browsers with CSS unused/disabled/altered, quite similarly to reliance on JS.

<comment><USER18> Disabled CSS would leave such form still usable. It wouldn't look, and behave exactly as intended, for sure, but I suppose these days no one expects unchanged user experience while disabling CSS. Meanwhile, disabled JS on JS- based forms usually kills them.

<comment><USER17> HTML/CSS as in the example would indeed be usable, though a similar version of this (with inline labels and checkboxes used for "aside" notes) gets rather messy when used in a textual browser or converted into another format. JS- based expansion doesn't have to get unusable either (it can merely hide bits of a document after loading, with those present in HTML), but perhaps could become unusable more easily.

I'm not arguing for use of JS, by the way (not sure if it was clear), but rather for proper use of HTML.

</comment></comment></comment><comment><USER19> HTTP 204 is amazingly under utilized in avoiding JavaScript. It allows messages to a server without a page refresh or XHR.

Click a link, server replies 204, browser stays where it is. Remarkably handy and imho underutilized.

If you don't mind a little basic JS you can do some pretty powerful things without any XHR.

<comment><USER20> so you click stuff and nothing changes - how that is useful? :)

usually when you're sending an xhr - you want something to change, some like status bar, cart items listing, anything

btw: you can achieve the same with simple css: `element:active` should have a background image that will perform an server side action when loaded

<comment><USER21> 204s are more reliable. The "cascading" in "cascading style sheets" means they are designed and intended to be overridden. The user can and often does apply their own custom CSS.

</comment></comment></comment><comment><USER22> I don't mind a few Javascript here and there if it's really needed.

But the JS abominations that were created in recent years it's completely beyond me, ironically those are the same people who insist in killing JQuery because it's "old & bloated" and "we don't need it anymore" but those people only use Chrome.

It's tragically funny.

<comment><USER23> Abominations everywhere... The bloated JS site is the replacement for Flash.

</comment></comment><comment><USER24> Ironically, the largest element of the website is the poorly optimized, almost 400kb hero image. After running it through [https://tinyjpg.com/](https://tinyjpg.com/) I got it down to 75kb.

<comment><USER25> Nice to see someone who cares about their job! :)

</comment></comment><comment><USER26> >The more code you have, the less agile you are. Code is a liability, not an asset. It's like tar. JavaScript libraries are getting bigger all the time and I don't think that many people are critically evaluating the actual need for them. People frequently measure JavaScript in KB or MB as if it is just a download cost. But it's not. You also have to wait for the CPU to parse/execute it. It all adds up.

I have mixed feelings about that first line. A lot of JavaScript is there to provide features and "flexibility" that otherwise would not be there....

It's hard to have this conversation as the usual statements about pages loading "too much" javascript are true-ish generally. But there are plenty of web apps that use framekworks that do great things with "too much" javascript. Yet the assumption seems to be there's a huge amount of "too much" and it's all bad and so it's discussed globally and good tools and ideas are kinda washed over with a sort of javascript paranoia.

Meanwhile a lot of these articles present personal pages or fairly limited functionality (often who have javascript on their page...). I find them interesting and fun to read from a technical perspective, but some of the implications seem to pine for the days where the web was simpler (I miss those days too in some ways) but where functionality would also be lost.

This is very much a case where i don't disagree with any given tidbit, but I do with the implications and application, if that makes sense.

Hacker News is an interesting place and while I'm kinda a n00b when it comes to web development it feels like it is a very "server side" world on HN and discussions about the front end are sometimes a bit skewed.

<comment><USER27> I have noscript that disables scripts by default. I can't read forbes, but I don't miss it, there's a lot of other internets that I can read. Should I even try to read forbes?

<comment><USER26> I mean it's Forbes so probably not a big loss.

I feel like the folks running with no javascript already made their call, and that's their call.

If you're developing a web app that "does a lot" (I'm just going to say that rather than get into individual things) It's pretty hard to do without javascript. But if it's a site just serving up text and pics, yeah you don't "need" it.

</comment></comment></comment><comment><USER28> Previous discussion here (article was originally posted on dev.to): [https://news.ycombinator.com/item?id=19367149](https://news.ycombinator.com/item?id=19367149)

</comment><comment><USER29> It is refreshing to see a push towards better user experience by reducing JavaScript overhead. I imagine that many development groups building massive client-side SPA's have convinced themselves and others that the "developer convenience" it provides is worth the cost to the users.

Ironically, there are massive improvements to be made by rewinding back to the "DHTML" days of delivering most of the content traditionally and progressively enhancing with a little JS. Except we have much better JS in the browsers and don't even need things like JQuery any more.

Back-end frameworks like Rails and Symfony really help as well, by separating concerns (such as models, controllers, and templates) and keeping the code clean that produces the bulk of the app.

</comment><comment><USER30> Nice! It's all about use case - for example, creating an invoice on a mobile device with spotty connectivity will not work.

However, the approach of starting like you have, and adding JS only if explicitly required is great.

</comment><comment><USER31> Nice. I always try to follow the rule don't do it in code when it can be done in markup (and/or css).

<comment><USER25> The reason why this is preferential is probably due to the fact that markup and CSS are declarative while JS is procedural

</comment></comment><comment><USER32> > ...encourage those who reach for a SPA for every project to give it a second > thought.

Every time this subject comes up I always get a sense of "These hipster kids are bad programmers and their react apps are killing the web" from the anti-JS crowd.

To me, this feels like the developer equivalent of blaming immigrants and poor people for systemic economic issues.

Directing your ire at the "Show HN: Look at my React app" or the kid at your meetup, or even your issue tracker, is an easier target, but not the correct one.

People reach for SPAs because:

1\. Unified development experience for interactivity provides very good developer ergonomics.

2\. Dirt-cheap, stupid-simple, five-nines reliable hosting as static assets on S3 or equivalent.

So long as these developer-quality-of-life advantages exist, people will choose them, especially for independent projects. Yes, there are downsides with bloat on initial-load, yes there are web apps that would be better served as server-generated HTML.

The "bloat" problem is mostly coming from content-heavy sites from media companies that keep injecting tons of various scripts for ads, tracking, and other BS. These organizations have no excuse, and should definitely not be using an SPA if they are, but they will keep doing it so long as the economic incentives of these scripts persist.

Edit: PS, I fully support articles like this and welcome discussion on better ways to build web apps. Hopefully we'll figure out a way to have the best of both worlds. Some attempts have existed but are nascent or die quickly before they can mature. Its a difficult problem.

</comment><comment><USER33> Bravo. Does anybody know of an energy-efficieny criterion or so to drive the 201x's webapp abominations out of existence going forward?

<comment><USER34> It sounds like your comment was meant to be snarky, but it is an interesting question. When you push the CPU processing of the UX from the mobile device back down to the server, the energy consumption certainly moves. Does it decrease, though?

Because if all JS were to go away tomorrow, and all CPU processing happened server-side, what would that change in server resource requirements?

<comment><USER35> You're assumption that it'd move server side is incorrect. It would simply disappear. When you use a javascript library the browser has to process and load all the functions in the library, even the functions that aren't used. This wastes memory and processing cycles on the client computer.

<comment><USER34> > When you use a javascript library the browser has to process and load all > the functions in the library.

That simply isn't true. Your device does load a library (usually minified), and parses the JS to be sure it is runnable. But it doesn't run every function just because it is loaded in memory. Even if it did, it happens on app load, once... then runs functions on-demand. And the size of the load can be mitigated with appropriate use of tree-shakable libraries. But without JS, the server regenerates an entire page, every time you do something, which takes some resources. It sends it over the wires, which takes some small amount of resources. The mobile device loads an entire page again.

I do agree there is wasted processing in both scenarios. But that waste doesn't just disappear when you do server-side work.

</comment></comment></comment></comment><comment><USER36> LOL this site does not even render with JavaScript disabled.

</comment><comment><USER37> Has anyone heard of [https://purecss.io/](https://purecss.io/) ??? Example: [https://purecss.io/layouts/side-menu/](https://purecss.io/layouts/side-menu/)

<comment><USER38> This example uses some JavaScript

<comment><USER37> Did you see the JS?

</comment></comment></comment><comment><USER39> I just want to say your about page is fantastic! Your Privacy section is short and to the point. Also love how up front you are on how the site is sustainable.

</comment><comment><USER40> It is hugely ironic that this page is just a loading spinner if you don't have JavaScript enabled, so I have no idea what it says.

</comment><comment><USER41> "Slimvoice - A Webapp Without JavaScript..."

"using as little JavaScript as possible"

Without, and as little as possible are mutually exclusive.

</comment><comment><USER42> I built front ends for industry for 14 years without JavaScipt. Nuclear power plants, battle ships, manufacturing plants, electric grids, air traffic control systems.

Pre-browser - ah, those were the days ;)

</comment><comment><USER43> Ironically, the link only works with Javascript enabled.

</comment><comment><USER44> Just wanna say that using Blender to create your illustrations (very in these days) is genius! Never would've crossed my mind!

</comment><comment><USER45> And here I found out about detail and summary tags. Brilliant !

And next I find out it's not compatible with MS browsers. Sad.

</comment><comment><USER46> All of this is presented on a site where my browser downloaded a full megabyte of JavaScript. Lovely :-)

</comment><comment><USER47> well, that website doesn't work without javascript

</comment><comment><USER48> This is brilliant!!!

</comment><comment><USER49> Unless you have at least 20 developers for Frontend alone, don't even bother with SPA applications. I assure that the result will be much worse than a regular web app with server side rendering and some AJAX. The only good SPA applications I've seen were developed by huge companies like Microsoft or Google and smaller companies don't have the resources for that.

<comment><USER50> I'm deploying a simple SPA I wrote as a sole developer for a client later this week, and the clients have been thrilled with it so far. I've written less code than in other traditional webapps, the app is responsive and works well, and I know that sudden changes in server infrastructure (they're on-prem hosted and looking at moving to a Windows/IIS environment) aren't going to require a full-on rewrite.

I think that's probably the sweet spot for SPAs though honestly - small scope internal apps (served over relatively quick intranet connections) with access to minimal client infrastructure (all you need is a web browser).</comment></comment>


PHP vs Node js... Let's be honest: Node.js couldn't kill PHP. Why? - <AUTHOR> https://belitsoft.com/php-development-services/php7-vs-nodejs#1 <comment><USER2> #1 reason the article doesn't mention: It's incredibly cheap to host PHP. Hosting companies push WordPress and other PHP-based hosting heavily and make it super easy for anyone to get a live site going with PHP.

Last time I launched a node app, it took me a full day of messing about in AWS. Last time I launched a PHP app, it took me less than a half hour at Siteground.

<comment><USER3> TBH, PHP is viable for pretty much exactly as long as Wordpress survives and uses it. If that changed, I wouldn't fancy PHPs chances.

<comment><USER4> I disagree. I've been using PHP for about eleven years now, even since the bad old days of PHP3, and I have never used, and generally advise against using, wordpress. PHP will be around long after wordpress.

I do concede that if PHP went away, WP would somehow survive, like some kind of post-nuclear cockroach.

<comment><USER5> I'm in the same boat. I cranked a lot of things out with CodeIgniter back in the day. Expression Engine is superior to WordPress but if you like either I'd suggest Craft CMS now and moving forward. For general apps, I use Laravel or Lumen. And React PHP for scraping. And don't forget The League [1]. Lots of great PHP stuff out there.

[1] [https://thephpleague.com](https://thephpleague.com)

</comment></comment></comment></comment><comment><USER6> Node was not built to kill or replace PHP, so why should it? I mean even C++ didn't kill or replace C. Both languages can coexist, I like em both.

</comment><comment><USER7> I maintain a mountain of PHP. What attracts me to JavaScript is its syntax:

PHP:

        $fruit = array('apple', 'banana', 'orange');

        $fruit_colors = array(
            'apple' => 'red',
            'banana' => 'yellow',
            'orange' => 'orange'
        );

JavaScript:

        var fruits = [ 'apple', 'banana', 'orange' ],

            fruit_colors = {
                apple: 'red',
                banana: 'yellow',
                oranage: 'orange'
            };

That's like 20,000 fewer keystrokes and much easier to read. My favorite new feature in PHP is the short array syntax.

Even those less minimalistic than me, I think the draw to Node is the language, the consistency of having the same language front and back.

Much ado is made about which one is faster. But I would say roughly 99% of web apps are CRUD apps, with a few users per hour, and the bottleneck would be the database anyway.

For me what PHP has going for it is my familiarity with it. Plus, despite all the nitpicking articles, it is rock solid, especially compared to Node. And compared to Node, PHP is a hyper-organized library of everything you need, just an arm-length away.

<comment><USER8> A few months ago I was tasked with porting an internally used Node.js script to PHP 5.6. The code made heavy use of nested async callbacks and other patterns frequently only seen in Javascript codebases. I thought I'd have to rewrite most of it from scratch, but the PHP code ended up nearly identical to the original Javascript. Line-for-line, ignoring minor syntactical differences (like the $ in vars), these two ~400 line scripts ended up being 98% identical.

Anonymous functions, closures, async calls, syntax short-hands... PHP has it all.

</comment></comment><comment><USER9> PHP uses an imperative programming model and has a very clear URL->source file mapping. This means you can look at the URL, find the source file, start at the top and trace your way to the problem.

Node (and Rails, and Java and lots of others) use a declarative router. The app boots. Shit happens. Routes exist. Middleware is involved. There's no way to know what code is implicated in a given URL.

If you're a pro and you can afford to spend a year or so learning framework internals while not getting much done, you develop a sixth sense for where in the codebase an error is likely to be, but you need to spend many weeks and months scratching your head to get there.

PHP is much more beginner friendly in this way.

<comment><USER10> When's the last time PHP has been used in this way? Don't people use frameworks these days such as symfony, silex and laravel etc? And then point the web server to the entry point like with any other language?

<comment><USER11> >Don't people use frameworks these days such as symfony, silex and laravel etc

People _should_ , Composer (with PSR autoloading) and nikic's FastRoute get you most of the way to a really nice, lightweight meta-framework barring anything else, for practically nothing. There really is no excuse for the "URL points to a file" model to be a thing anymore.

But a lot of legacy PHP code doesn't do that, and likely a lot of newbie code doesn't, because they follow old tutorials, and that model is faster and simpler.

Not even Wordpress uses routing AFAIK.

<comment><USER12> Honest/naive question: why not? Plenty of mvp or weekend projects can get by easily with url=page. If it's faster and simpler, what's wrong with doing it? Surely there's room for both on the intetnet.

<comment><USER11> Having a router allows you to not have all of your files be web accessible, by using a single point of entry and a whitelist for all possible paths. Most projects which map PHP files to URLs have everything in the web root.

If it's just a small brochure site with a few pages then it's no problem, but forums and larger projects built like this can leak information and expose vulnerabilities when PHP files which weren't meant to be directly accessed are, such as pages that perform SQL queries expecting variables in context that don't exist when accessed directly, or old config files, text files, open directories, etc.

But "url=page" is still basically routing using the query string, and IMHO so is access control using .htaccess. Any system where URLs are validated and where they don't directly point to files on the server counts.

<comment><USER7> > Having a router allows you to not have all of your files be web accessible

Having a router may make it easier, but it's not the only way.

You can just put your libraries, passwords, etc., in some directory outside the document root.

        /var/www/example.com/public
        /var/www/example.com/lib

Then you use "include" to get them.

<comment><USER11> Having worked on projects with includes within includes within includes, and dealing with global variables defined in one file, used in another and reused elsewhere, it's definitely not the _best_ way and it seems to destroy encapsulation.

If you can keep it under control, though, of course it's no different than includes in C/C++ (it probably literally is a wrapper around the macros.) But modern PHP prefers using autoloaders, so you never actually have to use include statements to begin with. You could just as well define those directories and include them through a Composer setting.

<comment><USER7> > includes within includes . . . global variables

Yeah, that's a pain. You have to exercise a little discipline. Of course none of my code has that ;)

With hand-typed routing, can't you accidentally define two routes that overlap, so some URLs could match both? The only reason it goes to one and not the other is something random like the order the routes are defined in the file? Like if you defined this route:

      /a/b/c

Then you slept, added a bunch of code, came back in three months and put this in:

      /a/*/c

Now you have two routes that match the same URL. And maybe they're separated by several lines of code, so that the mistake is hard to spot.

You can't do that with a filesystem, put two files in the same place.

<comment><USER11> > The only reason it goes to one and not the other is something random like > the order the routes are defined in the file?

To be fair, that's not random, that's pretty explicit. And if you're optimizing for speed, short circuiting at the first match is a good idea.

But if you're using a router, chances are you're passing the segments as arguments to some function or method anyway, so route /a/*/c and /a/b/c should both wind up returning the same content if the second segment in both cases is 'b'.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I can't take this article seriously when it shows a survey at the top claiming to show a stack overflow developer survey for back-end technologies that lists Javascript at 54% happiness, and then further down it lists nodeJS at 14% happiness. I guess the other 41% were using io.js.

Apparently people are also happier using angular on the back-end. Which makes no sense. Also, pretty sure WP still runs PHP on the back-end. So much inaccuracy here.

</comment><comment><USER14> I have successfully run node.js applications on a hosting account which supported fast cgi for Rails applications.

Unlike normal node.js applications, the process is started and managed by the provider's web server and applications can be uploaded using a standard FTP application.

Here's a similar library: [https://www.npmjs.com/package/node- fastcgi](https://www.npmjs.com/package/node-fastcgi)

<comment><AUTHOR> Lucky with the provider?

<comment><USER14> This was a couple of years ago, but the provider was Bluehost. While I had shell access and a compiler, I only used it to compile the node binary and make the main js file executable with a hashbang.

</comment></comment></comment><comment><USER15> Due to the ubiquity and ease of hosting PHP, and the current shift to full- stack JavaScript frameworks, I predict a long transition period where various "bridges" will be made to interface between the two. Mainly I'm thinking of PHP-side exposing content via REST APIs, with a more modern frontend written all in JS.

<comment><USER16> Where I work we use PHP 7.0/7.1 with the Laravel framework and Vue.js as the front end. Works well for us!

<comment><USER15> I'm curious, how do you reconcile server- and client-side rendering to be the same? Specifically, I'm thinking about initial page load/reload and route transitions. Do you share templates/partials between PHP and JavaScript?

</comment></comment></comment><comment><USER17> 'complement' not 'compliment'

<comment><AUTHOR> thank you

</comment></comment><comment><USER18> There's still people working on Visual Basic 6 as well. That doesn't mean there are no viable alternatives.

<comment><USER19> Faced VB6 professionally, there are viable alternatives, but end users don't buy your software because of what technology you made it with, or originally made it with. They buy it if it works and does what they need. It comes down to viable transitions and the resources needed to make it happen.

Indeed from the last 6 years, companies are more willing to try out new technologies, like node, or even docker! But only places that can truly develop decoupled from the technology already used can jump on board for these things. The transition cost for adding other technology when decoupled is magnitudes lower than migrating an existing functioning production proven product.

I have my own opinion on NodeJS, but I give it credit for the tooling it has outside of production server uses.

<comment><USER18> You can imply node.js is not a viable production server solution. But you should rather be more explicit why. I am curious about your perspective.

PHP as a project includes a templating engine, a scripting language, and a lot of native code built without a modern approach.

node is a more scoped project. Doesn't implement its own scripting language, and doesn't include a templating engine and a lot of the stuff PHP does. It focus on doing a single thing well. The native part of it is libuv, which uses a consistent approach: non-blocking asynchronous I/O.

Many other projects also build on top of libuv and v8, and any improvements coming from those integrations ultimately benefit node.

In comparison, PHP is one large project encompassing everything. As a result, I won't expect PHP to move as fast. It's a larger project with lots of backward compatibility concerns to take care of.

I know that PHP has known large deployments but none of those run on the reference implementation. node.js does have large deployments running on its default implementation.

<comment><USER19> This perspective is only from my limited experiences with Node in writing and interacting with existing node software.

Node is great if you want shared state, there is no overhead to access state introduced by many users of your system. Making a game server of sorts seems like a good fit. It is also running on a proven technology which is battle tested by millions of users independently each day.

But, with the cost of trivial access to shared state, there is no isolation. A metaphor from the Erlang community is that it's tolerable to crash a one on one phone call, but not the entire switch and everyone connected through it. I have experienced existing software with space leaks which need to be restarted every week to remain operational in production with tolerable latency and resource footprint. It doesn't seem sane to me. (The example here is a channel pub sub server)

Indeed PHP for large deployments requires tuning or alternative implementations (e.g. HipHop) to be reliable and fast at scale. But one aspect PHP does that node does not is assume isolation. Isolation is not a guarantee, but if one page crashes, most of the time others are not directly impacted. If on PHP processes runs out of memory, same story. If one tries to starve the scheduler, it will eventually time out and be killed.

Your point on it having a legacy of many integrated parts is very true, and I share your conclusion on not expecting it to move fast.

Many developers are coming to the shared perspective that simple software should have simple extensible cores and it is okay to have multiple implementations for a class of features (e.g. templating). This model of independent reusable parts is where we will see fast moving technology grow.

<comment><USER18> First of all, what you seem to be criticizing are server frameworks such as express, rather than node. node does not impose a paradigm for how requests are handled in a web server. It only provides the building blocks for a web server framework. In theory it is possible to create a library that forks the process for each request, if so you prefer. I personally think that might bit a be inefficient.

Then, there are ways to mitigate the problems you describe. I know this first hand as someone who has been behind substantially large deployments.

While leaking resources like memory, file and connection handles is a problem, there are ways to find them and fix them. While a bit of discipline and rigor you can be safe. But a lot of people in the node community are usually disregard anything that cannot be sold and usually end up creating problems they cannot get out from. And usually make those problems worse by adding workarounds the problems they created.

With a little bit of good practices, unit testing, profiling, load testing, code reviewing, etc... something that you can achieve by still being able to have work/life balance, by thinking like an engineer instead of discarding every software engineering book you read at school, by paying attention to what you do and not allowing excessive complexity, you should be in a comfortable position to fix a bug related to leaks.

The problem are imprudent people that want to boost their careers by pushing features that do not implement non-functional requirements to get the favor of product stakeholders. That approach may work on frontend, may work on some contexts, but not on backend node software. That's the easiest way to have a cascading failure of servers on 100% CPU/100% memory usage beyond repair.

Usually those people come in one flavor: people that think that because they know JavaScript, they can write server software. That's not it. To write server software you need to know network protocols, operating systems, memory management, algorithms, databases, distributed systems, etc.

</comment></comment></comment></comment></comment><comment><USER20> Asyncronous thats the difference. Nodejs its asyncronous, thats powerfull but its a nigthmare to control it in a crud database api. We try to change from php to nodejs in 2016 but async was the difference.

</comment><comment><USER21> Why the clickbait? Use the right tool for the job.</comment>


Perlsecret - Perl secret operators and constants - <AUTHOR> http://search.cpan.org/~book/perlsecret-1.001/lib/perlsecret.pod#NAME <comment><USER2> This fails to mention the most useful part of the "baby cart":

      "Greetings @{[ get_planet() ]}lings, we come in peace!"

Evaluating functions directly inside of a string. It's sort of alluded to with "@{[ keys %hash ]}", but in doesn't come right out and say it.

<comment><USER3> You get the wrong context when you do that. Try it with, say, localtime and see what happens. String interpolation is more obvious, and only one character more in normal formatting, one character less in golf:

        "Greetings " . get_planet() . "lings, we come in peace!"

As it says, the whole point of the baby cart is to force list interpolation. If you don't specifically want that, don't do it.

<comment><USER2> Depends on what you're doing. In a small string, there isn't much difference. It's more useful when doing other things:

      my $message = <<"HEREDOC";
      Greetings @{[ get_planet() ]}lings,

      We come in peace.

      Sincerely,
      Your New @{[ get_invaders() ]} Overlords
      HEREDOC

Sure you can jam them into variables first, or use sprintf, but it's a matter of preference so long as you know what you're doing.

<comment><USER3> You can also use [http://search.cpan.org/dist/Interpolation/lib/Interpolation....](http://search.cpan.org/dist/Interpolation/lib/Interpolation.pm) for this problem. But if you've got a lot of text, I prefer to bite the bullet and graduate to a proper templating system.

However my point still stands. You need to be aware that it does not simply interpolate the function output in, it also switches you from scalar to list context. (IMO context is the worst idea in Perl, but it is here to stay so you need to know about it.)

</comment></comment></comment></comment><comment><USER4> Peteris Krumins wrote about some of these operators some years ago: <http://www.catonmat.net/blog/secret-perl-operators>.

</comment><comment><USER5> As someone who loves obfuscated Perl...thanks! These are some great tricks.

<comment><USER6> From someone who loves Perl, please do not use it in production :)

Although, it is really interesting find!

<comment><USER7> While I generally agree that the discretion must be observed when working on production code, I don't think the author is advocating these to be of wide use.

These are very useful when you play Perl Golf, and can be pretty powerful in the hands of an expert player (sadly, my dreams of becoming one has remained just that.)

The author of this document was a regular in Perl Golf tournaments and also in the Fun With Perl mailing list, which was a precursor and launchpad for several of these tournaments.

For those interested, here is a series of articles about "The Lighter Side of Perl Culture": <http://www.perlmonks.org/?node_id=410774>

See also, "Perlgolf History" at <http://terje2.frox25.no- ip.org/perlgolf_history_070109.pdf> (not sure if this link is still alive.)

<comment><USER8> Whoa!!!!, thanks for that pdf. Who ever compiled it has just done an awesome job!

<comment><USER7> If I remember correctly, that would be "mtve" [1] (who sometimes went by a slightly longer "mtveurope"). If I had to pick the top three all-time Perl golfers, he would be one of them.

[1] <http://www.perlmonks.com/index.pl?node_id=143426>

</comment></comment></comment></comment></comment><comment><USER9> Part of the reason I've stopped writing Perl apps, the operator noise is getting out of hand.

<comment><USER10> Could you give examples? All of the recent Perl improvements have introduced operators that seem extremely useful to me and _reduce_ noise.</comment></comment>


Show HN: Hi HN, please checkout my new product,XBdash, and give feedback:) - <AUTHOR> https://www.xbdash.com/ <comment><AUTHOR> Hey guys, just to give you a little information on the project: About a year ago, me and one cofounder, who I worked with completely remotely, created this application because of our connection to the community and desire to fill a need as well as reward our fellow gamers. UX is very important to us and I would love some feedback from all you wonderful people on what could be done to improve it:) Please check us out and, if you are an xbox gamer, check out our contest page for a chance to win free games. We plan on giving our prizes every month to reward our users for their gaming achievements.</comment>


How Tonido can help Opera to triumph browser wars-an Open Invitation - <AUTHOR> http://www.codelathe.com/blog/index.php/2009/06/16/how-tonido-can-help-opera-browser-to-triumph-browser-wars-an-open-invitation-to-hakon-wium-lie/

<comment><USER2> Actually Tonido is the real under dog, but glad to see Tonido's concept is catching on. I wonder how many people are already using Tonido.</comment>


Show HN: Automated Rails development with Prelang - <AUTHOR> http://prelang.com

<comment><USER2> Here's my feedback, as the developer of the Rails Composer tool [[https://github.com/RailsApps/rails- composer](https://github.com/RailsApps/rails-composer)].

I got started with "automated Rails development" (as you call it) using Michael Bleigh's RailsWizard. He built it at RailsRumble 2010 as a website that generates Rails apps. I forked it as Rails Composer when the project was abandoned, and developed it further, purely as a command-line tool. It's been the most popular project I've worked on in the Rails community, and also more work than I ever expected.

I've had a huge community supporting Rails Composer as an open source project so I get a reliable stream of issue reports and pull requests. And I've built a business model to fund the project, by asking supporters to pay $19/mo, and offering my in-depth Rails tutorials as a reward for subscribers. That's the RailsApps project [[http://railsapps.github.io/](http://railsapps.github.io/)].

Rails Composer is popular because developers really like a tool to build starter apps, and it's a lot of work because changes to Rails and gems constantly introduce entropy. I think you'll face a similar challenge with Prelang, maintaining the product as gems change. Developers want an automated Rails development tool because a good starter app will give them a reference implementation, code that is properly configured and guaranteed to work with the latest versions of all the popular gems. You'll have to keep checking and tweaking as gems and Rails versions change. That job will be easier if you limit the starter app to use only the most popular stack and a small set of popular gems, as you've done so far. You'll also need to monetize the project to be able to maintain it (I doubt it can succeed as a spare-time project). As a gauge of time required, I work fulltime on RailsApps, splitting my time between developing Rails Composer and writing the tutorials for the project's supporters.

Erik, I hope you do well with Prelang. You've created a beautiful interface, the project is ambitious, and judging by Rails Composer, developers will want it.

<comment><AUTHOR> Thank you for the kind words and continued support/feedback, Daniel. I'm guessing we'll keep bumping into each other for a while. :)

I definitely hear you on the Gem volatility and agree on monetization. Eventually, I'd like to have a team working full time on the builder in addition to user-contributed features. Surely, it's a headache to think about hundreds of features past what Prelang has now but I believe it's doable with the proper architecture.

All the best.

</comment></comment><comment><USER3> This looks pretty neat. Looking forward to you getting the disabled features ironed out.

Some notes:

* Project generation with most of the features and a couple models is taking a really long time. I'm sure it's a background job, and I could walk away if I wanted to, but it'd be nice to know that the system would email me to let me know when it was done

* Sometimes UI widgets flicker when switching between sections. I'm guessing a lot of those styles are being added with Javascript, not CSS? You might consider switching to a CSS framework that gives you a good look and feel, but doesn't have to call some JS function to apply styles.

* The auto-capitalization on model names, and auto-lowercasization (?) on field names, was a nice touch, and made me feel happy about the product.

* It would be really cool if users could write and submit plugins / hooks. I'd be interested in background jobs that weren't DelayedJob, and deployments that weren't Heroku, for instance.

* I'm guessing that "public repos only" is a temporary feature, because GitHub doesn't have a way to authorize an app to write only to certain private repos, correct? Because most of my work is on private repos, and I can't see my organization using something like this without the ability to create projects (even scaffolds) privately

* A feature for Vagrant would be nice :-)

I'll be watching this! We've currently got several people switching from ColdFusion to Rails; they're good programmers, but they don't know the ecosystem or the conventions. This gives them a really good starting place. Thanks for sharing.

Edit: Also, this is the first time I've seen app/views/elements/, and I'm kinda pissed I haven't thought of using a different directory for partial layouts before. Now I've got some app/views/layouts/ directories to clean up...

<comment><AUTHOR> Really appreciate the detailed feedback.

* Email on generation is a good idea. Also, I don't have a Gem cache system yet which will help.

* Flickering is because some of the inputs have to compute a lot of values @ Backbone model layer. Definitely opportunity for optimization.

* Thanks :)

* A lot of users have asked for user contributed features. The problem is it's hard to extract an API from my generation system but I hope to in the future.

* Very doable. I just haven't written private repo support in because I'd have to deal a lot of auth/selection issues which isn't a priority right now.

* Vagrant would be great.

For a lot of these, I just don't have time yet but all candidates for the future.

Thanks again.

<comment><USER4> Re the auth issues, why not let people clone / download a zip direct from you, skipping the github auth.

<comment><USER5> presumably each step is being done as a git commit, so there'd need to be a git install done locally for creation, then zipping, then cleanup afterwards. I don't think it's unreasonable, but I'm guessing there's some 'post to github' gem that's being used directly right now and this other option would require more work.

</comment></comment></comment></comment><comment><USER6> I love it. Adds an awesome GUI to features that I love in RailsComposer. Would love the ability to add sidekiq, postgres, rails_12factor & sass

</comment><comment><USER7> This is a fantastic tool, really well implemented. Will definitely be following along how this develops in the future.

</comment><comment><USER8> This is really cool. Have you guys considered Heroku integration? One-click generation + deployment could be a really slick MVP tool (although I worry about how it would affect client expectations were they to ever find out about it. :)

<comment><AUTHOR> Thanks! A deploy process like that is coming relatively soon... I've been working on it today in fact. I'm glad you think that would be valuable.

<comment><USER9> I know of at least 3 people who would kill for this feature. Imagine generating a starting point and have it deployed immediately. Wow. Gamechanger!

</comment></comment></comment><comment><USER10> This is truly an innovative addition to the Rails ecosystem. I'm learning Rails and Prelang offers a great way to read code that's written with best practices in mind. All the best!

</comment><comment><USER11> The demo video looks fantastic. Great work you guys.

</comment><comment><USER9> This is really interesting! I created a simple app to CRUD Cities and Countries and it works as you expect it to. Code is also what I would have written given the simple spec.

Uses the latest Rails and clean code generation. Well done!

If you're curious see here: [https://github.com/sergiotapia/prelangtest](https://github.com/sergiotapia/prelangtest)

I'll use to launch my next project because Facebook+Email authentication is a pain in the ass to implement.

</comment><comment><USER12> Is this something I can download onto my own machine and run, or I need to do it through the website?

<comment><AUTHOR> It's all through the web.

</comment></comment><comment><USER13> good work, known of this for awhile and been impressed.

came across this one today which is trying to doing something similar also

[http://www.drystorm.co](http://www.drystorm.co)

</comment><comment><USER14> This looks like a really great tool. It's a shame Github doesn't have more fine grained permissions though - I'd love to give it read/write access to repos it creates, but it requiring global read/write access means I'll probably never use it.

</comment><comment><USER15> This looks great! I like how this one concentrates on the back-end features more than the views. It just generates all the backend/routing and lets you put in the special view logic yourself. Good way to not get distracted trying to master a WYSWIG.

</comment><comment><USER16> Great work!

mongoid support would be highly appreciated :)

</comment><comment><USER17> Cool idea, but I immediately left when I saw the only background process option was DelayedJob. With greatly advanced options like Resque and Sidekiq, I fail to see a need for DJ personally.

<comment><USER18> At my job, the lack of high reliability/availability options for Redis was why we chose DelayedJob. This may have changed since we made that decision, but at the time there was no consensus on a solution in the Redis community.

</comment></comment><comment><USER19> I only watched the presentation video and I'm being nitpicky but by convention git commit messages should be present tense.

<comment><AUTHOR> Ah, you're right. Thanks.

</comment></comment><comment><USER20> I have been thinking about something like this for about a year now...you've done an excellent job! Good luck!

</comment><comment><USER21> We're taking "Show HN" out of this title because the software isn't ready to be tried out.

Please read the new Show HN guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html). Landing pages and email signups are explicitly excluded. But when your work is ready for people to play with, please come back and do a Show HN then!

<comment><AUTHOR> I'm deploying with the email gate removed now. If I don't hear back, I'll just make a new "Show HN" post.

<comment><USER21> Happy to put Show HN back in the title.

</comment></comment></comment><comment><USER22> This is why I love Ruby. It's got all the built-in language features that allow one to perform this sort of abstraction, and a large-enough user base so that powerful ideas like this will eventually be implemented. I couldn't imagine anything like this existing in even Python.

<comment><USER23> [http://www.web2py.com/](http://www.web2py.com/)

[https://www.youtube.com/watch?v=k7lE-R16H4c](https://www.youtube.com/watch?v=k7lE-R16H4c)

<comment><USER22> Yeah, not even close.</comment></comment></comment>


Working alone is better than working as a team. - <AUTHOR>

Hi all,
I have been working on a project as a part of team for sometime now. We are not getting anywhere. And we are not able to pinpoint one person or one thing that is not working.
So I look forward to hearing from you why teamwork seldom works.
Thanks. <comment><USER2> Strange conclusion: teamwork doesn't work because your team doesn't work?

Did you even consider the second option: your team sucks.

Sorry to state that in such a plain way, but I've seen many teams doing great work. Matter of organisation and responsibility.

</comment><comment><USER3> I disagree with the statement. However, you need a good team to work well as a team, and when you're at the stage of trying to pinpoint faults, the team already failed.

That doesn't mean that all teams suck, though. The one I work with certainly doesn't, and I'm more productive as part of this team than I ever was alone.

<comment><AUTHOR> I am trying to pin faults on anybody. I am trying to introspect why the team is not working. I have been part of many teams both successful ones and ones like this. I feel I have learnt more, finished projects faster, felt more content with the quality of output, and acknowledged for going the extra mile on projects that I have worked alone and then in a team environment.

In the team environment, the quality of output is always compromised. I always end up feeling I could have done more to fix the project. And I am dissatisfied and pretty pissed at lack of accountability and aloofness of the team.

I am sorry if I have offended anyone but this is how I feel every working hour I work in a team.

<comment><USER3> That only means that even if you were in successful teams, they weren't good teams.

</comment></comment></comment><comment><USER4> The communication overhead for a team of x developers is on the order of x!.

Or something like that.

edit: (x-1)!

edit 2: of course there are other factors, that's just one piece of it.</comment>


Reduce your JavaScript bundle size by 77% - <AUTHOR> https://medium.com/@kelion/reduce-your-javascript-bundle-size-by-77-6fa5024680ca <comment><USER2> Wow, there's some really angry comments about this.

How about we see this as an opportunity to learn something new about how browsers work and cool new compression formats that are supported by major browsers?

</comment><comment><USER3> how about not shipping kilobytes of javascript?

</comment><comment><USER4> How about stop misusing a web browser as a "platform"?</comment>


Stanford To Offer Free CS and Robotics Courses - <AUTHOR> http://www.deviceguru.com/2008/09/17/stanford-frees-cs-robotics-courses/ <comment><USER2> I have been blogging about free education

for more than 2 years now. I have collected

hundreds of video courses from universities

around the world on my blog:

<http://freescienceonline.blogspot.com>

</comment><comment><USER3> _The courses are nearly identical to what's offered to enrolled Stanford students, according to the University. However, those taking courses through SEE are not eligible to receive Stanford credit for them._

Are traditional universities the way education can be made freely available?

<comment><USER4> I'd say yes. Traditional universities are the best equipped to make this curriculum freely available, and the web is making it easier and easier to do so. As a side note, I think Omnisio would be _fantastic_ as a way for students to annotate lecture videos, and ask each other questions.

MIT has taken the lead in a huge way with OpenCourseWare (ocw.mit.edu), and even without other schools following, that is a sizeable corpus of educational material for the avid student.

<comment><USER3> I agree on the 'best equipped' note. They have the knowledge, resources, materials & experience necessary but. They'd potentially be their own undoing.

The problem is conflict of interests.

<comment><USER4> It depends. I don't think anyone sees OCW as a substitute for going to school at MIT.

I'd also argue that universities serve other roles beyond education. Universities are gatekeepers, and your degree has signaling value that free online classes never would give you. Further, the exchange of ideas & friendships developed on a real college campus are nearly impossible to duplicate when delivering free educational content online.

<comment><USER3> _It depends. I don't think anyone sees OCW as a substitute for going to school at MIT._

That's the whole point. If it were successful, it would be (a substitute). What you are saying is that it isn't a problem, because it's' not too successful.

 _I'd also argue that universities serve other roles beyond education._

Education is what pins it all together. Imagine a future where degrees are not University centred, courses are available online & testing/evaluation is gets solved separately from the institutions. For one thing, filtering is not necessary. There's infinite room in every degree so if any filtering is done, it needs to be done as part of the testing/evaluation. Universities are a shell in this world. Parents are not likely to cough up the $$ they do currently, for students to make friends.

<comment><USER4> _If it were successful, it would be (a substitute)._

I disagree with that definition of success. OCW is very successful -- its goal is fundamentally different from the degree-granting part of MIT.

Success for OCW means that everyone who wants to access university-level content can do it for free. If MIT wants to charge tuition for the "premium" version where you live on campus, can ask questions of the professors, get to know your classmates, get a degree, etc, then they certainly have the right to. That is a scarce resource, and can command a price like many other scarce resources people pay for.

<comment><USER3> _I disagree with that definition of success._

Fair enough, but I hope it's not just a matter of semantics. My definition of the success for making educational materials available is making _education_ available. The absolute goal would be 'the best education.' I admit, this is probably not the goal of this particular project.

Universities have an inherent interest in maintaining a big enough gap between free & premium education.

It seems to me that you're objections are base on an assumption that education cannot be acquired outside of institutions with an equivalent quality or ease. No chance. Universities don't have to worry about that, so no conflict.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> > Each course comprises downloadable video lectures, handouts, assignments, > exams, and transcripts.

This isn't all that much different from a textbook, is it? The free aspect is cool but so is Wikipedia.

Being able to ask questions to someone who thoroughly understands a subject would probably make a bigger impact on a person's education.

<comment><USER4> I think you're missing the point. Of course being able to ask questions would make a much bigger impact. That's why people go to school. This is not meant to replace that.

> "This isn't all that much different from a textbook, is it?"

1) Video. 2) Textbooks aren't free. 3) Wikipedia isn't organized into bite- sized lectures, and doesn't include ways to evaluate yourself. Wikipedia is a quick reference, not a comprehensive guide.

</comment></comment><comment><USER6> Wow how awesome isn't this? Major props to MIT and Stanford for pushing making knowledge available to everyone.

A lot of universities don't even offer courses like this and here you get it for free.

</comment><comment><USER7> I'd like 2 things to come out of this

1.) Some kind of lab support. I could buy a kit and go along and build what ever simultaneously with the class I'm following.

2.) an automated way of seeing how well I'm doing. A test giver/grading.

</comment><comment><USER8> Has anyone gotten the programs for CS106A to run under Eclipse in Linux or gotten the special Stanford version of Eclipse to run in Linux x64?

</comment><comment><USER9> it would be nice t have a torrent of all the lectures for a given course + materials together.</comment>


Ask HN: Best way to apply for entry-level roles? - <AUTHOR> Hello all!
I'm a recent grad with a degree in CS and I was wondering if HN could help me with some career advice.
Specifically, I've been having some trouble in figuring out the optimal strategy for applying to entry-level dev jobs.
In particular, is it better to apply only to specific kinds of jobs (front-end, back-end, mobile, etc.) or to just apply to every kind of software development role out there?
In other words, should I focus my job search to particular subfields of software development or is it better to cast a wide net?
Given that I don't have much work experience, I would greatly appreciate any advice from the folks on HN.
Thanks! <comment><USER2> My school had a job board that allowed for easy submissions of resumes (kinda like linkedin). Read the description of what they're looking for, and if it sounds cool you should go for it. Also, I had multiple versions of my resume that showed what classes I took that'd pertain to the job I was applying for. Like if it was a web job, I'd put a few classes that'd be related toward that. Good luck!</comment>


Americans were never excited about space exploration.  - <AUTHOR> http://si.academia.edu/RogerLaunius/Papers/93299/_Public_Opinion_Polls_and_Perceptions_of_US_Human_Spaceflight

<comment><USER2> This is an interesting study, but I found the HN title to be misleading. Here are the bullets from the concluding paragraph:

* The American public has long held generally positive attitudes toward the space program, but is not very familiar with its details.

* Over the history of the space age, an average of more than 60 percent of those polled rated the job done by NASA as either ''excellent'' or ''good.''

* Most Americans have shown support for space exploration and view it as important over the years, but also believe that federal money could be better spent on other programs.

* Most are also in favor of NASA as an organization, but are relatively unfamiliar with the majority of its activities and objectives.

* These polls also suggest historically close relationships between public perceptions of NASA and spaceflight depictions in popular culture, especially film. These images from popular culture, coupledwith real-world accomplishments in spaceflight, work together to create powerful visions affecting the public consciousness.

</comment><comment><USER3> What a superb paper! thanks for posting this, I learned a good deal from it. I was _astonished_ by figure 15, showing that although NASA,s budget has historically been about 1% of the total federal budget, the general public simply has _no idea_ , with 15%+ of the public (in the 1990s) thinking that NASA consumes 50% or more of total federal spending. WTF.

</comment><comment><USER4> It's a shame the data only seems to be available up to 1997 for the study. For those curious how recent private space initiatives have impacted these numbers, here are a couple more recent data points I could find:

[http://www.gallup.com/poll/121736/majority-americans-say- spa...](http://www.gallup.com/poll/121736/majority-americans-say-space- program-costs-justified.aspx)

[http://www.people-press.org/2011/07/05/majority-sees-u-s- lea...](http://www.people-press.org/2011/07/05/majority-sees-u-s-leadership- in-space-as-essential/)

[http://www.rasmussenreports.com/public_content/lifestyle/gen...](http://www.rasmussenreports.com/public_content/lifestyle/general_lifestyle/july_2011/50_say_space_shuttle_program_worth_what_it_cost_taxpayers)</comment>


Latest developments in the kernel ASLR district - <AUTHOR> https://blog.netbsd.org/tnf/entry/the_strongest_kaslr_ever <comment><USER2> Splitting the ELF sections into multiple chunks is such a good idea.

<comment><USER3> It'll probably have a performance hit if you have to use functions from other chunks (need an extra lookup in the table to find them) but if the linker is intelligent enough you could avoid a lot of that by putting stuff that calls each together.</comment></comment>


The great divide - <AUTHOR> https://css-tricks.com/the-great-divide/ <comment><USER2> I'm gonna put here a timid «I call bs on this».

First of all: HTML+CSS is indeed pretty complex. When you care for A11y, Responsiveness, Performance, Maintenability, complexity rises as a cartesian product.

But if you introduce interactions, the complexities rise by orders of magnitude.

To keep up with those complexities, you need to have a strong engineering background in concurrent/event-driven programming. Because that's what a UI is.

So a HTML+CSS developer is all good till they need to add a dropdown, or any interactive component. Then you either know how to manage that complexity, or you're gonna introduce technical dept to the project (or just pass responsibility).

In reality, what I saw, is that developers focused on front-end usually can perfectly learn on the spot what they need to keep their HTML+CSS accessible or responsive. When they have a knowledge gap is usually for past disinterest.

On the other hand, HTML+CSS developers usually have a hard limit when talking about interaction.

So, when I'm searching for developers, I look for the skill super-set, because I can make a HTML+CSS dev out of a FE dev, not the opposite.

<comment><USER3> I think you're right that being _really_ good at HTML/CSS/design is hard AND being really good at writing complicated UI code in JS is hard. They're both hard problems (or can be!). Where I disagree is that moving from an expertise in one to another is asymmetric (JS -> HTML/CSS [easy], HTML/CSS -> JS [hard]). I think it just depends on a person's interests. Some people really only care about the complicated logic so they'll stick to the JS side of things. Some really only care about design and visual aspect so they'll stick to HTML/CSS. Some people can do both very well. And of course there's a million permutations in between. What matters the most I think is whether a person's interested. If a person is interested they'll learn anything eventually. That and likely they'll learn it better than someone who's not interested who's had more time/experience.

I think when you're going to hire someone you should try and screen for interest in the things you need them to do. That and screen for a proven ability to learn things quickly (cognitive ability). That or you take a calculated risk when hiring.

<comment><USER2> My comment a little bit rushed. What I meant is not that an HTML+CSS dev _cannot_ move to the other side, but that the frontend developers I saw in the last ten years falled in the one of the two categories. Those willing to move to UI/app development already did — or are vocal about wanting to do it.

Totally quote on hiring.

</comment></comment></comment><comment><USER4> It's insane to me that CSS and web layout et. al. has become so complex that it's being described as _engineering_.

This seems to further be a confusion between _design_ \-- that is, the blank- slate, unfettered artistic approach to a user interface -- and _design_ as in the architecture of the software that makes it possible for the art to function in a usable way.

Those are two quite different skillsets and I can't imagine there are very many developers who are very strong at both.

<comment><USER5> It only makes sense that its become so complicated though. With millions of websites and different use cases something simple would never suffice. So many people need to use it in so many different ways (compared to 20 years ago) that it was forced to become complicated.

</comment></comment><comment><USER6> Tech recruiter here. From all software engineering profiles, frontend is indeed the hardest to match because the variety of skills is so big. On the one end you have JQuery people who are stuck in 2002, on the other hand you have people like Dan Abramov.

<comment><USER7> and on the other hand you have engineers who stopped caring about the technologies and started prioritizing performance, reliability, resilience, etc.

It took me 5 years to realize that "bleeding edge" != "best practice".

<comment><USER8> Gatsby uses GraphQL and React to generate a static website. I muttered angrily at it everytime some data was not available in the page because I forgot to update the GraphQL query.

It is just a static website for crying out loud.

But once I got around it, it gave me a score of 100 in performance and 80 in SEO just out of the box. Images are resized and inlined if need be; critical CSS is rendered first; the plugins added niceties like default anchor link in Github. And I could use React components to organize everything, which is a much more ergonomic way of doing reusable markup compared to server-side things like Rails partials.

I would've needed to spend weeks if I had to get here from scratch. Gatsby is bleeding edge and it does best practices - including performance better than most other static site generators. I think the web is only moving forward - there is cambrian explosion of new untested and often ill-thought ideas, but the good ones will survive in the long run.

<comment><USER7> Hmmm... interesting. We are using something similar ([https://nextjs.org/](https://nextjs.org/)) on our marketing site and our performance is a single digits on lighthouse.

<comment><USER9> By default Next.js scores 100/100 on performance and best practices eg [https://nextjs-3q3i4heaj.now.sh/](https://nextjs-3q3i4heaj.now.sh/) (SEO / Accessibility are not 100 as I didn't add meta tags in this example, but are very trivial to add.)

In case of Invision it seems like images / render blocking css that was added outside of Next.js are the main culprit. I've reached out to Jon Wheeler who works on the marketing site to make him aware.

</comment></comment></comment></comment></comment><comment><USER10> Can't agree more with this. Nowadays, it's hard to tell what anyone wants from a front end developer any more, and there have definitely been a few jobs I've interviewed for where they wanted one type while the description was seemingly tailored to the other.

I'd also this is why Gutenberg isn't a great idea for WordPress, and why it feels the software's going the wrong direction. It's trying to aim at the Airbnb/Netflix/Facebook/Google crowd writing SPAs in React and what not, whereas its actual audience are the traditional web developers, agencies and deisgners using standard HTML, CSS and a bit of JavaScript and PHP.

Also a few interesting articles linked there that need posting here individually...

</comment><comment><USER11> It seems like traditional craftspeople (e.g. woodworking) worked directly with the medium they designed for. AFAIK industrial designers are heavily involved in creating/production their products.

As a developer turned designer I can't understand how anyone can design for the web and not know how to write HTML and CSS.

There's always going to be grey area but I don't think you should need an CS/engineering degree to build a UI.

</comment><comment><USER12> Surely someone with HTML+CSS skills and a strong focus on layout, user experience and accessibility counts more as a "designer" than a "developer/engineer"? Something akin to the old term "web designer", who might have dabbled in Javascript but worked mostly with HTML+CSS.

In contrast, the terms "developer" and "engineer" definitely have a stronger implication of programming being a major element of the job. Though nowadays on React-using sites, designers might have to work with JSX and JS directly, causing an even greater crossover of the roles.

<comment><USER13> I've seen designer used mostly to reference UI designers who primarily work in non-code.

</comment></comment><comment><USER14> It seems to me that everyone is trying to normalize terminology and job titles instead of normalizing skills and disciplines. Why not read a book or follow a tutorial? Anyone can learn CSS from zero to expert in a week. Instead we spend time giving ourselves a new title that is just the right mix of accurate and ego-stroking.

<comment><USER15> "Anyone can learn CSS from zero to expert in a week"

I've never seen anybody pick it up that fast. Even the best students coming out of multi-month frontend bootcamps aren't at an expert level.

<comment><USER14> They do not teach CSS at any bootcamps as far as I know. It is considered too easy to waste time on in a bootcamp.

<comment><USER16> > Anyone can learn CSS from zero to expert in a week.

Maybe the (highest level of) basics, but as someone who's been in the industry 21 years and manages all hiring for front-end, the one area of front-end that everyone seems to think is easy but also one of the rarest skills to find on the market is someone who actually understands the finer points of CSS, like why one would use "font-display: swap" in the context of performance, the performance implications of complex CSS on mobile devices, CSS methodology rationale, accessibility implications of using X vs Y, best way of delivering CSS to accelerate the "Start Render" metric, etc.

</comment></comment></comment></comment><comment><USER17> I am wondering whether this is also a problem in game development or not. In game development to create a game often you need an even more broad skillset in your organization than in web frontend developemnt. Can frontend development learn from game development when defining the roles?

<comment><USER18> UI is roughly gamedev's equivalent of the HTML/CSS part of "front-end development", and within my experience, UI is one of the more common places for games to have problems.

</comment></comment><comment><USER19> Seems like people just want someone to do everything for cheap to me.

</comment><comment><USER20> What's the argument to call designers developers?</comment>


Metrics for social games - <AUTHOR> http://www.slideshare.net/justinsmith/metrics-for-social-games-by-david-king-and-siqi-chen

<comment><USER2> What program did they use for their metrics/graphs?</comment>