Ask HN: Is big-endian dead? - <AUTHOR> Are there any big-endian chips still in production outside the embedded or specialty market?
Even MIPS and PPC now support a little-endian mode and are usually deployed that way. ARM is nearly always LE or deployed that way, and RISC-V is LE.
Edit: bonus factoid:
Little-endian is slightly more confusing for humans but may be objectively better for machines. On a little-endian machine integer size casts are free -- e.g. casting a uint64_t to uint32_t just means reading the first 4 bytes of it. On big-endian machines integer size casts require pointer math. <comment><USER3> As long as we use the traditional network protocols and socket API it's not "dead" dead. The other name for big-endian is "network order", after all.

As way to serialize data (wire / disk format) it's becoming more common. FlatBuffers and Cap'n'Proto are the popular ones. They reduce (completely eliminate?) byte shuffling when de-serializing.

In one instance I was reading a spec for an industry-specific protocol. At first I was looking at it and thinking "What the... they are padding stuff in a strange way, and using little-endian for the data". Then it suddenly dawned on me, that they've designed the spec to be whatever GCC on x86-64 Linux machine would do to layout C the structures in memory.

So someone very lazy could just define a struct and cast into it as data comes from the wire. Someone one a big endian machine, would have to do a lot more legwork to get the thing working. But given that there aren't many of those around, it was deemed an acceptable tradeoff.

<comment><USER4> Using the x86-64 C struct layout as the serialization format is increasingly common in financial trading protocols. Skipping all the bit twiddling has a huge performance impact at high message rates. I once compared two feeds covering the same basic data, where the major difference was one had a complicated serialization and one was C struct layout. The former needed two 16 core servers just to process I/O and deserialize the messages; the latter used 1 core on a single server.

<comment><USER5> "The former needed two 16 core servers just to process I/O and deserialize the messages; the latter used 1 core on a single server."

I'm genuinely curious; what was the 'former' protocol? Was it encoded using FAST or zlib or something?

<comment><USER6> I would guess FIX/FAST. For a concrete example, have a read of the specifications for Eurex's market data protocols:

[http://www.eurexchange.com/exchange- en/technology/t7/system-...](http://www.eurexchange.com/exchange- en/technology/t7/system- documentation/release6/Release-6.0/3088824?frag=3088828)

Specifically, compare the Enhanced Market Data Interface protocol (described in "T7 Market and Reference Data Interfaces") and the Enhanced Order Book Interface protocol. EMDI is FAST, a morass of tags, stop bits, presence bitmaps, and who knows what else (i don't). EOBI is structs.

</comment></comment></comment></comment><comment><USER7> Big endian is dead on the client. WebGL exposes endianness and happened at a time when almost all systems running browsers are little-endian. This makes the big-endian provisions of the spec a dead letter. Web devs don't need to test on big-endian systems and would have a hard time finding big-endian systems to test with even if they wanted to. It's safe to assume, therefore, that there's a mass of Web content that only works if the browser exposes little-endian behavior to JS. It's not performance-wise competitive for a WebGL system to present little-endian behavior on big-endian hardware.

Therefore, it won't be feasible to try to re-introduce big endian to systems that need to be competitive at rendering the Web.

Big endian will stay alive for the time being on home routers and Sparc servers, and probably for a long time on IBM z systems.

The cost–benefit of software accommodating big-endian systems will look increasingly bad with legacy enterprise servers imposing a negative externality on everyone else. (E.g. refusal to consider bitcasts between SIMD vectors of the same bit width but different number of lanes as portable/safe operation in language design.)

<comment><USER8> You can not only assume it, but I can also say with certainty it exists. Emscripten hastened this by letting site owners compile little-endian code into little-endian asm.js. For example, the WhatsApp Web QR code generator won't run on a BE platform; it's an Emscriptenized blob of code backing it that assumes the typed array it stores into has LE orientation.

TenFourFox and Leopard Webkit both emulate little-endian typed arrays on BE Power Macs and transparently byteswap integers. This mostly works for sites that care and has almost no overhead in JITted code for 16 and 32-bit int, but Facebook managed to break some of our assumptions with floats (example: [https://github.com/classilla/tenfourfox/issues/453](https://github.com/classilla/tenfourfox/issues/453) \-- we don't byteswap floats because it's expensive and probably would break things expecting native endian on the DOM side). Fortunately, TenFourFox doesn't support WebGL, so we don't need to worry about that.

IMHO, this is a broken promise about how the Web was supposed to be platform- independent. I get the feeling the general attitude on this thread is that such platforms are unimportant, but that doesn't mean it's not a broken promise.

<comment><USER9> _IMHO, this is a broken promise about how the Web was supposed to be platform- independent. I get the feeling the general attitude on this thread is that such platforms are unimportant, but that doesn 't mean it's not a broken promise._

I'm pretty sure many other fundamental protocols of the Web don't work so well on a non-2's-complement, non-8-bit-byte machine either.

<comment><USER8> Ignoring whether asm.js is a fundamental protocol or not, the Web wasn't supposed to depend desperately on the byte orientation of the consumer. Surely you remember how it was supposed to lift information access above what type of computer you viewed it on.

WebGL's endian specification was the beginning of the end, after which folks started saying certain implementational details weren't worth caring about, and this just finishes it off. And that's not what was being sold in the beginning.

</comment></comment></comment></comment><comment><USER10> The "casting" advantage basically just hides bugs. Because it's often __not okay __to access just 16 or 8 bits of a 32 bit number; the value is being truncated and that could be a bug.

However, when the number's range is small enough, such code appears to work. Finding the bug is delayed until larger values occur, which is not until its deployed in the field or someone thinks of writing better test cases.

Anyway, if it is okay to truncate, the right thing to do (and ISO C conforming) is to access the underlying type as that type, and then cast the result, not to cast the pointer. I.e. rather than:

        int x = *(int *) ptr64; // breaks on BE; not kosher with ISO C aliasing rules

this:

        int x = (int) *ptr64;  // works on LE and BE

We don't even need the casting operator in the second example. So it's less syntax and clearer code to do the more portable thing.

If we want the bits for that int from some other part of the wider word, we can use shifting and masking.

<comment><USER11> I ran into a bug in that area a while back. Our development environment has a binding to Winsock32.dll for socket stuff, and as it turns out the bindings were written so long ago that many of the return values are specced to be 16-bit ints. As a result, our application would work fine almost all of the time, but fail mysteriously with "socket operation on non-socket" after about 8000 sockets have been opened. As I understand it 8000 is because file descriptors are a kind of bump-the-pointer scheme internally and pointers are 8 bytes wide on 64-bit platform.

</comment></comment><comment><USER12> Little endian is also better for multi-word addition/subtraction. Your first operand will be the low word, which your pointer conveniently already indexes. This was a classic trick in the days of 8 and 16 bit systems, and assembly code for modern modular crypto systems still uses it.

Really I think consensus is that the industry focus on big endian systems was actually a mistake. It prioritized programmer comfort in a regime where it never really mattered.

<comment><USER10> OTOH, big-endian is better for comparison; you can tell when one integer is larger than another by looking at as little as just one bit, from the most significant end.

<comment><USER13> In the worst case, comparison is still like subtraction.

<comment><USER10> Even if the whole datum is examined, comparison is more parallelizable; it doesn't require carry propagation.

</comment></comment></comment></comment><comment><USER14> I used to use IETF's network order (big-endian) for everything on disk or over the wire, but I switched to little-endian around 2008. If I ever have to port to a big-endian machine I'll deal with it then. I haven't regretted it yet.

<comment><AUTHOR> Big-endian is the canonical form for storage and the wire because back when the Internet was designed most "pro" machines were big-endian: Sparc, old MIPS, old PPC, DEC Alpha, etc. All these are dead or dying now.

It's easy enough to deal with BE files and protocols by just swapping bytes. I'm referring to hardware architectures. Are there still any big-endian chips out there? Does it still make sense to support big-endian chips in new code as long as that code is never intended for embedded or very old systems?

<comment><USER15> Small pedantic correction from a former Alpha kernel hacker: DEC Alpha was Big Endian only for some rare Cray systems. Everything else was Little Endian.

<comment><USER16> Many, many years ago I worked for Progeny, and we contracted with HP to help bring Debian to Itanium.

We quickly discovered that a fair bit of Linux software (or at least Debian packaging of same) only worked properly on 64-bit DEC Alpha because the architecture was Little Endian; 32-bit pointers would typically "just work(™)" because the code was grabbing the first 32 bits, and the other half of the pointer addresses was typically 0x0.

Since we were porting to Big Endian hardware (just now discovered Itanium was selectable, not sure why it was Big Endian in our case) we were getting a fair bit of null pointer exceptions.

Anyway, ancient history, but that was my only direct exposure to endian- madness, so it has stuck with me.

<comment><USER17> HP wanted to replace PA-RISC and that was big-endian. Intel of course wanted little-endian. That's why Itanium was selectable.

</comment></comment></comment></comment></comment><comment><USER18> We had this same thread 997 days ago: [https://news.ycombinator.com/item?id=9451284](https://news.ycombinator.com/item?id=9451284)

If big endian was effectively dead back then, I guess it's really dead now.

</comment><comment><USER19> Let's hope so because one of these is not better than the other but one is much better than two.

<comment><USER20> I was annoyed reading the RISC-V docs and seeing that they allow implementations to go either way. Sometimes it's better to just make a choice and tell people what it is.

</comment></comment><comment><USER21> I was once on a contract that involved porting satellite simulation software from SPARC/Solaris to x86/RHEL. The software was in Ada95, and it didn't take much to get it to compile on the new hardware. However, ground-to-vehicle comms (which our simulator had to handle as it needed to work with the real ground control software) took place using a packed binary format (wasting as little space as possible). Data fields frequently crossed byte boundaries (the first 10 bits are field X, the next 6 are field Y, etc.). Fun times rearranging and repacking bits.

Of course, dealing with all of the Endian issues had not been planned for and was not in the project schedule :/

<comment><USER22> Sounds like VMF. It's such a pain to debug when you can't even rely on marker strings being recognizable in dump output.

One time I had to make little- and big-endian machines talk nicely was for a message engine that ran on Intel/Linux. All the messages in the ICD were glorified packed structs that were native on the IBM/AIX side.

I used the ICD wire format as my storage format. I defined containers for all the primitive types with correct sizes and that swapped values on assignment and read (except for strings, of course). I added the appropriate pragmata to pack the underlying structs and locked down their sizes with static_asserts that would fail at compilation time until everything fit perfectly.

These classes gave me what looked like native structs on the Linux side, e.g.,

        msg.foo = 3;

or

        msg1.date = msg2.date + 1;

and the byte swapping happened transparently all around, both on the way in and on the way out. Yes, if latency had been a concern, this design may have been problematic. The Linux box faked messages on behalf of three other systems so we could command the AIX software into different modes with complex prerequisites. Changing a few fields per cycle, I could then dump the struct onto the wire.

A cool aspect to the story was it all worked correctly the first time out of the box even though I did not have access to the AIX box during implementation. When it came time to integrate with the AIX side, all that was left to do was some low-level socket stuff to hook up to the message flow.

I'd moved to a different project full-time and worked this message engine during evenings and weekends. We got the code unpacked, so I run make check like I had been so frequently.

"Wow, you had time to write unit tests and everything?" asked one of the guys from behind my shoulder.

A moment of Zen hit.

"I didn't have time _not_ to."

</comment></comment><comment><USER23> Little endian is genius. Not only because of size casts being "free" (because LE is compatible among "word" sizes -lower bits are at a known location-, while with BE you need to know the word size in order to locate the lower bits of the word), but also because of efficient bit I/O (using CPU registers as accumulators, and flushing with a word-size store), so variable size data can be encoded efficiently.

</comment><comment><USER24> Dealing with PCM audio streams (like WAV files) you sometimes find both. After all, there are thousands of codecs + media containers + multiple versions.

[https://en.wikipedia.org/wiki/FFmpeg#Supported_formats](https://en.wikipedia.org/wiki/FFmpeg#Supported_formats)

> When more than one byte is used to represent a PCM sample, the byte order > (big endian vs. little endian) must be known. Due to the widespread use of > little-endian Intel CPUs, little-endian PCM tends to be the most common byte > orientation.

[https://wiki.multimedia.cx/index.php/PCM](https://wiki.multimedia.cx/index.php/PCM)

</comment><comment><USER25> I'm presuming from your wording that you're already aware, but for the benefit of others, ARM is bi-endian and can be used in either of LE or BE modes. However, most "in the field" configurations deploying real-world operating systems use it in LE mode as that makes porting everything so much easier.

</comment><comment><USER26> > Little-endian is slightly more confusing for humans...

I think you meant to write "Little-endian is slightly more confusing for humans _who use left-to-right languages_ " as all the R-L languages also put the least significant digit on the right.

<comment><USER27> Not true. In arabic languages you write text R-L, but numbers are L-R.

<comment><USER28> Do you mean that you read a text from the right to the left, and when you meet a number you jump to is leftmost digit, then read it LR, then jump agzin to its left (where there is a space) and resume reading text?

<comment><USER29> If you think about it in left-to-right languages reading numbers requires backtracking because you have to see how many digits there are to know if you're reading units, thousands, millions, billions...

Take 12,345,567 for instance, if you want to read it aloud you first have to go all the way to the end to figure out that there are three groups of numbers, so the first one is million, then thousands, then units. If you were only given a truncated version of the number it's impossible to read it aloud. So in a way the arabic represents number actually makes some sense and it could be argue that _we_ write them backwards.

Furthermore IIRC from a discussion with an arabic friend (from the middle east, not sure if it's different in NA) the most formal way of reading numbers aloud is actually backwards (or little endian I guess) compared to the way we do in english. So _if I understood correctly_ for 1,234 you'd say "four and thirty and two hundred and a thousand" or something similar. Don't quote me on that though because I know almost nothing about the arabic language and this is from a discussion I've had many years ago.

</comment></comment></comment></comment><comment><USER30> I believe the chips that IBM uses in their current Z series mainframes are still big-endian.

</comment><comment><USER31> Eh, haswell added the movbe instructions. And I wouldn't be surprised if someone in the RISCV world added big endian instructions (they're nice for network processing).

And nearly every powerpc I've seen is big endian, FWIW.

<comment><USER32> Actually, Silverthorne (the first Atom CPU) added MOVBE.

<comment><USER25> It seems that Atom has become - ironically - a staging ground for new features that make their way much later to the desktop/mobile x86_64 architecture. Here's another: [https://neosmart.net/blog/2017/will-amds-ryzen-finally- bring...](https://neosmart.net/blog/2017/will-amds-ryzen-finally-bring-sha- extensions-to-intels-cpus/)

<comment><USER31> Those little cores get a lot more benefit out of special case instructions.

</comment></comment></comment></comment><comment><USER33> Im working for an Space Agency and we'r using SPARC for all our sats CPUs. Basically, Big-Endian.

<comment><USER34> I worked on a code base using the LEON (SPARC, big-endian) and also ARM in little-endian mode for space. The code was common for both endians. I followed the sage advice of Rob Pike on it: [https://commandcenter.blogspot.com/2012/04/byte-order- fallac...](https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html)

</comment></comment><comment><USER35>
      Little-endian is slightly more confusing for humans

I've heard this before, but the reason is that you view hex data and list numbers left-to-right as if they were letters. They are not.

0x12345678 stored big-endian, numbering bytes left-to-right:

      12 34 56 78

Looks good, but I think that this is actually more confusing, because when you number the bytes and bits you will see that the bytes are written left-to- right, while at the same time the bits are written right-to-left.

The solution is to show dumps with bytes numbered right-to-left. This is coherent with how we number bits, and also how we relatively position digits in any other number.

0x12345678 in little-endian, but written right-to-left:

      12 34 56 78

Now the numbering of the bytes is consistent with the numbering of bits. You can easy see that bits 0-7 of the bits interpreted as a 32-bit word belong in byte 0, while bits 16-23 belong in byte 2.

<comment><USER36> At least in Freescale's PowerPC documentation, it's convention to number the bits left-to-right in big-endian. So the most-significant bit is bit 0, which matches up with the most-significant big-endian byte being 0. See, for a random example, page 1101 of [https://www.nxp.com/docs/en/reference- manual/MPC8379ERM.pdf](https://www.nxp.com/docs/en/reference- manual/MPC8379ERM.pdf).

Personally I prefer the little-endian representation.

<comment><USER10> The documentation might have that numbering, but that makes no difference in programming on the PowerPC. When we take the value 1 and shift left by 1 bit, we get 2.

That the documentation thinks this is bit 7 going to bit 6 is immaterial.

Calling the MSB "bit 1" is a tip of the hat to serial communications. In serial communication and networking, it is predominant to transmit the MSB first.

If the documentation is about a wire format, then using that numbering is correct down to the data link layer and (modulo framing considerations and such), physical.

<comment><USER36> Oh, I'm aware it makes no difference internally; I picked that documentation because I am somewhat intimately familiar with it as I worked on a product with that CPU and did a lot of driver work. My only point was to the poster I was replying to, who wrote " _because when you number the bytes and bits you will see that the bytes are written left-to-right, while at the same time the bits are written right-to-left_ ". That assumes that bits are universally numbered starting with 0 at the LSB, which isn't true.

</comment></comment></comment></comment><comment><USER37> SPARC still exists, and is big-endian

<comment><USER38> SPARC 64 is bi-endian. It has big endian instruction format, but you can choose endianness both at the load-store level or at the memory page level.

</comment></comment><comment><USER39> Maybe in processors, but not in general.

Why? Because you can use lexicographic sorting with big-endian bytes.

</comment><comment><USER40> Funny I just asked a question about this on SO when I discovered that CBOR - <USER2> very recent protocol - uses network byte order (big endian). A confounding decision given that no machines today use it, and it just add extra byte swapping at both ends.

I can't explain it other than presumable there was some guy on the design committee who was like "but.... Unix... the 70s... network byte order... guys!" or something.

<comment><USER41> Having implemented CBOR [1], it's really only an issue for the x86, which _can_ do unaligned reads. On most other architectures (even little-endian ones like RISC-V) it's less an issue because you will either have to copy the bytes to be aligned, or just read byte-by-byte (sorry, octet-by-octet) and shift.

[1] [https://github.com/spc476/CBOR](https://github.com/spc476/CBOR)

</comment></comment><comment><USER42> Big-endian is the new 1's complement.

Like 6-bit bytes and octal, BCD, segments, and other such memories, it's simply a relief that we've moved on.

</comment><comment><USER43> I find the the terms big endian and little endian confusing, feels like they should be switched around.

So the one that ends big (most significant byte last) should be big endian and the one that ends little should be little endian. But it's actually the opposite. It makes it difficult to remember which is which.

<comment><USER9> Here's an alliterative mnemonic:

        Little endian puts the
        Least significant part at the
        Lowest address(offset)

</comment></comment><comment><USER44> > On a little-endian machine integer size casts are free -- e.g. casting a > uint64_t to uint32_t just means reading the first 4 bytes of it. On big- > endian machines integer size casts require pointer math.

Is it really that different? It matters on x86 if the value is in some register already, since there's no subdivision of the high part, but it shouldn't matter for memory. Most instructions support math in addressing, so whether `(char)*x` gets compiled to `[eax]` or `[eax+3]` seems not very different.

</comment><comment><USER45> The 24-bit virtual machine I'm working on is little endian. The 'processor' reads instructions and addressess in little endian and instructions are stored in memory in little endian. But when programming it, using assembly, values and addresses are written with the least significant byte on the furthest right to make it easier for people to understand. At least so far. I may change it if it ends up being confusing.

</comment><comment><USER46> While it has mostly gone out of favour, it really isn't due to some cosmic plan. Intel just won in the microprocessor architecture race, and they happened to be LE due to their evolution.

I still have PowerPC and MIPS machines that are BE, and which are occasionally handy for seeing if pointer math is being done wrong.

</comment><comment><USER47> Here is another point of view on the endianess issue: [https://commandcenter.blogspot.fr/2012/04/byte-order- fallacy...](https://commandcenter.blogspot.fr/2012/04/byte-order-fallacy.html)

</comment><comment><USER48> I think a couple of networking chips still use it.

<comment><USER49> I remember reading somewhere that BE was chosen for IP partly for routing efficiency. As you go from MSB to LSB in an IP address you narrow in on an increasingly specific network segment. That's probably not true anymore as smaller and smaller blocks of IPv4 addresses have been handed out (e.g. instead of a full class C).

<comment> Const-me > That's probably not true anymore

Right, and also because modern RAM is essentially a block device. You just can't access individual bytes anymore. E.g. on a typical modern PC with a dual-channel DDR, the block size is 128 bits = 16 bytes.

</comment></comment></comment><comment><USER50> I read and so far all arguments for little endian I see are because the CPUs adopted it so it is more efficient to keep data the same way.

What are the other benefits of little endian, because in terms of readability big endian makes most sense.

I could understand that having things in reverse could be somehow more efficient, but why do it reverse in groups of 8 bits instead having all bits reversed?

</comment><comment><USER51> Big Endian is still supported natively on POWER8/9

Intel added movBE (mov big endian) support in BM2 extension.

Networks are still Big Endian.

SPARC chips (and now RISC-V) are BIG Endian by default.

MIPS just became an independent company a few days ago and they have native Big Endian support.

Edit 1: I was wrong about Power8/9 LE/BE

<comment><USER18> _If you use Linux on POWER you 're forced to use Big Endian mode as the faster Little Endian mode (according to marketting) is reserved for IBM's operating systems._

That's not correct. Ubuntu is LE only and it looks like RHEL is also switching from BE to LE.

"The base RISC-V ISA has a little-endian memory system, but non-standard variants can provide a big-endian..."

SPARC and MIPS are dead.

<comment><USER52> MIPS last I looked was quite alive in the embedded space - you're right in that it is effectively dead everywhere else.

</comment></comment></comment><comment><USER53> little endian is only confusing for humans because we very inconsistently use RTL vs LTR semantics.

</comment><comment><USER13> Do some bignum libraries perhaps still use big endian, for whatever reason?

</comment><comment><USER54> Why not both? There was at least one chip that let you select your endian- ness. (The MIPS R4000).

See Wikipedia on Bi-endian machines: [https://en.wikipedia.org/wiki/Endianness#Bi- endian_hardware](https://en.wikipedia.org/wiki/Endianness#Bi-endian_hardware)

</comment><comment><USER55> If you work with some industrial machines via serial protocols it is very much alive.

</comment><comment><USER56> Does it matter? on x86 you can bswap if you need to convert.

</comment><comment><USER57> Yes.</comment>


JuliaCon 2019 Live Stream - <AUTHOR> https://www.youtube.com/user/JuliaLanguage <comment><AUTHOR> Schedule here: [https://pretalx.com/juliacon2019/schedule/](https://pretalx.com/juliacon2019/schedule/)

Each talk will have its own live stream on YouTube and you should be able to immediately watch the raw recording of past talks as well.</comment>


DDoS on FreeDNS and Default DNS v2 - <AUTHOR> http://status.namecheap.com/ Message in their customers dashboard.<p>"Dear Customers, We're experiencing a DDoS attack on our DNSv2 system at the moment - this means that any domains that are using DNSv2 or FreeDNS nameservers may experience intermittent availability issues. We are currently in the process of mitigating the attack and are working hard to ensure a quick resolution. We sincerely apologize for the inconvenience caused." <comment><USER3> Their customer support is based in Ukraine. I hope their employees will get trough these crazy times unhurt.

<comment><USER4> Looks like the datacenter is in Kharkiv, about 400km/300mi from the fighting in Kyiv/Kiev.

</comment></comment><comment><USER5> If you're affected, you can switch your domains to their DNSv1. Seems pretty quick for most people.

See the other thread here: [http://status.namecheap.com/?p=14846](http://status.namecheap.com/?p=14846)

<comment><USER6> Note that this works and is pretty easy, just like switching to any other DNS server it can take up to 24 hours for the changes to propagate everywhere.

</comment></comment><comment><AUTHOR> Message in their customers dashboard.

"Dear Customers,

We're experiencing a DDoS attack on our DNSv2 system at the moment - <USER2> means that any domains that are using DNSv2 or FreeDNS nameservers may experience intermittent availability issues. We are currently in the process of mitigating the attack and are working hard to ensure a quick resolution. We sincerely apologize for the inconvenience caused."

</comment><comment><USER7> Previously on the front page earlier today (with a broken link) and lots of comments from users and Namecheap staff:

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

</comment><comment><USER8> It seems like there have been some very large DDoS attacks recently. Can anybody point me to a link explaining what changed recently that these things suddenly popped up?

</comment><comment><USER9> If they have a DNS v1 and v2 system, why can't my records be on both? What's the point of having NS1 and NS2 point to the same network?

<comment><USER6> Fair question, but I'd imagine it's not worth spending time migrating users to a different system if the attacker can simply update the servers they're targeting to follow you there.</comment></comment>


Show HN: Create a personalized and optimized webpack configuration - <AUTHOR> http://web.jakoblind.no/webpack-config/ <comment><USER2> This is a cute tool, but the real solution to this problem is to avoid Webpack altogether.

Parcel accomplishes everything Webpack does with literally ~0~ configuration. If you make the switch, it will be the most productive 20 minutes of your life. (Yes, I am bitter over the MANY hours of my life I've wasted fiddling with Webpack.)

[https://parceljs.org/](https://parceljs.org/)

<comment><USER3> Parcel is great, but what you're saying is just not true.

Webpack's configuration gives it a great deal of flexibility for working with many different types of project.

</comment></comment><comment><USER4> Wouldn't it make more sense to have a sort of "Spring Boot" [1] approach for Webpack, whereby a dependency like React (or a "webpack-react-starter") can list the features it needs to have enabled and Webpack can then automatically enable features based on that?

Tooling like this seems a bit backward, in the sense that you're now creating a tool to create configuration for a tool that runs other tools that~~stack overflow

[1] [https://docs.spring.io/spring- boot/docs/current/reference/ht...](https://docs.spring.io/spring- boot/docs/current/reference/html/boot-features-developing-auto- configuration.html)

</comment><comment><USER5> Nice! Although you might want to update this for Webpack 4.

Like for example, `ModuleConcatenationPlugin` no longer goes in `config.plugins`. It's now a boolean flag `plugins.concatenateModules`

<comment><USER6> This is everything you need to know about front end development in one comment

</comment></comment><comment><USER7> Why file loader and not URL loader?

To be fair this question is coming from a guy with a 4 day old stack overflow question that essentially amounts to "how the fuck do I use URL loader?"

<comment><USER8> From file-loader's README:

>Instructs webpack to emit the required object as file and to return its public URL

From url-loader's README:

>The url-loader works like the file-loader, but can return a DataURL if the file is smaller than a byte limit.

They are interchangeable, do the same thing, but url-loader can generate a dataUrl if the file is small, like an png/svg icon, so you can save one request where the latency could be higher than the download time.

I think this feature should be built into file-loader and toggled via loader option.

<comment><USER7> Oh, I read the docs start to finish, I just can't get the DataURLs to work lol. You seem like you know what you're talking about, so if you wanna take a crack at it... [https://stackoverflow.com/questions/49934116/404s-on-some- im...](https://stackoverflow.com/questions/49934116/404s-on-some-images-from- webpack-url-loader)

</comment></comment></comment><comment><USER9> The fact that "lodash-webpack-plugin" and similar exists seems like a symptom of a larger problem. Why isn't tree shaking [1] good enough?

1\. [https://webpack.js.org/guides/tree- shaking/](https://webpack.js.org/guides/tree-shaking/)

</comment><comment><USER10> Great stuff!. Specially at the beginning, webpack is intimidating and can turn complex quickly. Wish I had this when I began. Another add-on I would recommend is the addition of the: \- target: 'node'

for those developer that are using webpack on the backend.

<comment><USER11> And encourage yarn instead of npm for both stability, sane defaults, and performance. :) Small detail though.

</comment></comment><comment><USER12> SASS (specifically SCSS) support would be good - AFAIK it's the most popular preprocessor and has been for a few years.

</comment><comment><USER13> This is pretty nice. It's funny how all this time on Gulp/Grunt/Npm and a billion others, and finally we have something that seems to be staying still...

Now for the feature requests:

* Generally I have webpack.common.js for the common between all environments and webpack.config.js for dev (so the configuration file is named the default thing) and webpack.prod.js for production.

* Typescript checkbox :)

</comment><comment><USER14> I was thinking about something similar. Making the webpack configuration accessible using a drag'n'drop editor, where you can define environments (prod, test, etc) and build configuration per environment using building blocks. JavaScript generation, JSON export (for imports), sharing, etc.

Never had the time to actually start it, though.

</comment><comment><USER15> This is great! Would be great to see an option for Typescript, and splitting vendor and application bundles.

</comment><comment><USER16> make = webpack, this tool = autotools

We are going around in a cycle!

<comment><USER17> The difference being that Make is actually usable.

For the silent down-voters: Tell me why the above statement is not true.

<comment><USER12> It's a punctuation heavy format with a bunch of shell code mixed in, which means projects go from using one language (Python, Ruby, JavaScript etc) to three (whatever they were using previously plus Make plus shell).

</comment></comment></comment><comment><USER18> Production mode already defines NODE_ENV. [1] Your usage of DefinePlugin is redundant in that case. Any reason why you are defining it twice?

[1]: [https://webpack.js.org/concepts/mode/](https://webpack.js.org/concepts/mode/)

I think for beginners it's great to see what production mode actually does under the hood, but it shouldn't end up in the final config.

<comment><USER19> Interesting. I was attempting to compile some bundles over the weekend and was noticing drastically larger chunk sizes. I realized this was because I had neglected to specify NODE_ENV=production, and my babel-loader was using my dev config (which leaves prop-types in the code). Based on your comment, and the above docs, I shouldn't be seeing what I'm seeing.

<comment><USER20> Are you using webpack 3? That change happened in February with webpack 4:

[https://github.com/webpack/webpack/releases/tag/v4.0.0](https://github.com/webpack/webpack/releases/tag/v4.0.0)

</comment></comment></comment><comment><USER17> Cool tool. Would be great if it was also able to load and manage sections of existing Webpack configs.

</comment><comment><USER21> Check out [https://github.com/sysgears/spinjs](https://github.com/sysgears/spinjs)

</comment><comment><USER22> Why do people import PNGs into their JavaScript? That seems pretty weird... Not a criticism of this tool, which seems quite nice.

<comment><USER23> It's a convenience thing. Once you get used to it, it works well. You define a loader in your webpack config, which then decides what to do with the PNG.

Usually, what happens if you require a PNG is that it passes via url-loader or file-loader, and optionally image-loader. This'd mean that you'd get a string (either a full URL or a base64-encoded inline image if it's small enough) that points to the image, which is optionally minified by image-loader.

If you require CSS or SASS, your webpack loaders will ensure the CSS is loaded.

<comment><USER22> No, I get what is trying to be achieved, I am just questioning why it is being done this way and not something much simpler... I would much prefer that my JavaScript bundler only bundles JavaScript. Converting a PNG into a JavaScript module through base64 should be pretty trivial, so I'd prefer to do that with another tool. I do something similar for inlining CSS in my own projects.

<comment><USER24> You can use one tool to optimize and base64 inline images and another to compile SCSS and inline it of course. But then you discover that you also want to optimize and inline images placed within css url() properties so you implement that feature in your build pipeline, then you discover... you get the point. Webpack gives you a flexible configurable and extensible way to handle any such case in any environment which is why everyone uses it for modern frontend development. I think questioning webpack is like questioning why people are using dependency injection frameworks in modern java.

<comment><USER22> And then you wind up spending multiple days trying to figure out how to do something that doesn't quite fit in with what other people have already done.

How many times do we have to learn the same lessons over and over? Small tools that compose together is _infinitely_ more flexible than any plugin based tool can possible be.

<comment><USER25> Importing PNGs to JS is about dependency-wrangling, not task-running.

That is, the point of using webpack isn't that it's the best way to optimize a bunch of PNGs. The point of webpack is that it can parse your dependency tree and figure out which PNGs are depended on by a given entry point. If you also want your PNGs optimized, you can do that with a webpack plugin or a separate tool, as you like - that's orthogonal to the matter of why it's useful to import PNGs into JS.

<comment><USER22> Yeah, sorry but I don't buy that. webpack outputs JavaScript bundles, not a dependency graph. Importing PNGs into JavaScript is only useful if you use a JavaScript AST to then do something with those imports.

<comment><USER25> I'm not selling it, and I don't follow what you're disagreeing with. Webpack _can_ output JS bundles, but it understands dependencies between non-JS assets as well, and will process any file in the dependency graph any way you like.

As such the point of requiring a PNG into JS (or CSS, or a Vue/React component, etc) is to tell webpack there's a dependency on it. Then that image will get pulled in to the build process for entry points that need it, and not otherwise.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> Scope Hoisting is already part of "production" mode now which enables this and other optimizations automatically.

</comment><comment><USER27> Another poster mentioned this, but I'll reiterate: "avoid Webpack altogether".

ES6 or UMD/AMD please. Please do not subject me to toolchain choices just to use a lib.

If you're a TypeScript or Babel user, you can share code between backend, web tier, and native code without Webpack or other complex build tools.

Webpack is unnecessary in most cases.

</comment><comment><USER28> If I had to give one Tipp about front-end development: transition the buildsystem to gradle and call webpack from there. Also npm can be managed with it.

Then you can slowly introduce kotlin code, which is way more productive.

In the end I found that writing everything in kotlin, using tachyons for CSS, the kotlin-minifier for code minification and closure-compiler for optimization is the most stable way to go.

JavaScript isn't a productive language. Having build-tools in JS just complicates everything.</comment>


The effect of passive heating on heat shock protein 70 and interleukin-6 - <AUTHOR> http://www.tandfonline.com/doi/full/10.1080/23328940.2017.1288688 <comment><USER2> Didn't realize heat shock proteins are so useful. This explains a lot for me, thx.</comment>