Meet Bun, a Speedy New JavaScript Runtime (bun.sh) 121
Bun is "a modern JavaScript runtime like Node or Deno," according to its newly-launched web site, "built from scratch to focus on three main things."
- Start fast (it has the edge in mind).
- New levels of performance (extending JavaScriptCore, the engine).
- Being a great and complete tool (bundler, transpiler, package manager).
Bun is designed as a drop-in replacement for your current JavaScript & TypeScript apps or scripts — on your local computer, server or on the edge. Bun natively implements hundreds of Node.js and Web APIs, including ~90% of Node-API functions (native modules), fs, path, Buffer and more. [And Bun also implements Node.js' module resolution algorithm, so you can use npm packages in bun.js]
The goal of Bun is to run most of the world's JavaScript outside of browsers, bringing performance and complexity enhancements to your future infrastructure, as well as developer productivity through better, simpler tooling.... Why is Bun fast? An enormous amount of time spent profiling, benchmarking and optimizing things. The answer is different for every part of Bun, but one general theme: [it's written in Zig.] Zig's low-level control over memory and lack of hidden control flow makes it much simpler to write fast software.
An infographic on the site claims its server-side rendering of React is more than three times faster than Node or Deno. And Bun.js can even automatically load environment variables from .env files, according to the site. No more require("dotenv").load()
Hackaday describes it as "a performant all-in-one approach," including "bundling, transpiling, module resolution, and a fantastic foreign-function interface." Many Javascript projects have a bundling and transpiling step that takes the source and packages it together in a more standard format. Typescript needs to be packaged into javascript, and modules need to be resolved. Bun bakes all this in. Typescript and JSX "just work." This dramatically simplifies many projects as much of the build infrastructure is part of Bun itself, lowering cognitive load when trying to understand a project... Some web-specific APIs, such as fetch and Websockets, are also built-in.
"What's even wilder is that Bun is written by one person, Jared Sumner," the article points out — adding that the all the code is available on GitHub under the MIT License ("excluding dependencies which have various licenses.")
- Start fast (it has the edge in mind).
- New levels of performance (extending JavaScriptCore, the engine).
- Being a great and complete tool (bundler, transpiler, package manager).
Bun is designed as a drop-in replacement for your current JavaScript & TypeScript apps or scripts — on your local computer, server or on the edge. Bun natively implements hundreds of Node.js and Web APIs, including ~90% of Node-API functions (native modules), fs, path, Buffer and more. [And Bun also implements Node.js' module resolution algorithm, so you can use npm packages in bun.js]
The goal of Bun is to run most of the world's JavaScript outside of browsers, bringing performance and complexity enhancements to your future infrastructure, as well as developer productivity through better, simpler tooling.... Why is Bun fast? An enormous amount of time spent profiling, benchmarking and optimizing things. The answer is different for every part of Bun, but one general theme: [it's written in Zig.] Zig's low-level control over memory and lack of hidden control flow makes it much simpler to write fast software.
An infographic on the site claims its server-side rendering of React is more than three times faster than Node or Deno. And Bun.js can even automatically load environment variables from .env files, according to the site. No more require("dotenv").load()
Hackaday describes it as "a performant all-in-one approach," including "bundling, transpiling, module resolution, and a fantastic foreign-function interface." Many Javascript projects have a bundling and transpiling step that takes the source and packages it together in a more standard format. Typescript needs to be packaged into javascript, and modules need to be resolved. Bun bakes all this in. Typescript and JSX "just work." This dramatically simplifies many projects as much of the build infrastructure is part of Bun itself, lowering cognitive load when trying to understand a project... Some web-specific APIs, such as fetch and Websockets, are also built-in.
"What's even wilder is that Bun is written by one person, Jared Sumner," the article points out — adding that the all the code is available on GitHub under the MIT License ("excluding dependencies which have various licenses.")
I have a better idea for a better future (Score:5, Insightful)
Kill Javascript.
We don't need mistaken engineers making the hateful pile of garbage more efficient.
Re: (Score:3, Funny)
Keep polishing that turd.
Re: I have a better idea for a better future (Score:5, Funny)
Re: I have a better idea for a better future (Score:5, Interesting)
No it didn't! Posting right now with Javascript disabled. Slashdot is an old and creaky site that still can't do unicode. But at least it still functions without Javascript!
Re: (Score:2)
Re: (Score:2)
Keep polishing that turd.
Outsource it to Japan? [wikipedia.org]
Hateful for you, maybe? (Score:5, Insightful)
Kill Javascript.
We don't need mistaken engineers making the hateful pile of garbage more efficient.
I recall a time when PHP received this type of irrational hatred - I guess it's a sort of elitist view that "these kids can't code".
I will totally agree that we're seeing younger developers making the mistakes that have already been solved, but isn't that just the nature of pretty much _everything_?
I will laugh at the so called "new ideas" that come to the fore, in the JavaScript ecosystem, only to find many were actually coined back in the 70's.
But the phrase you use here "mistaken engineers" is just all kinds of wrong - there's the elitism, there's the attitude that turns so many younger coders away.
Say what you want about JavaScript and the developers involved with it, one thing it _does_ get right, is inclusivity.
There's no snobbery, there's no nasty gray beards sarcastically pontificating in their ivory towers "RTFM".
Instead, it has an ecosystem of sharing, of inclusivity - yes, a "mistaken engineer" can pick it up and write some fucking awful code, but for that moment, they _feel_ like an engineer and it's a _great_ feeling - and why shouldn't it be?
What I've noticed over the years, as a gray beard myself, are other gray beards stepping in to lend JavaScript a hand - realising that, for good or bad, right now, it's an exciting place to be.
It's full of god-damn awful code, terrible ideas, terrible practices ... but heck, it moves at pace, it's the wild west and there's a LOT of cutting edge concepts on the back of it, that really weren't around "back in the day".
But heck, you just shout into the wind, because the reality is, this "pile of garbage" has been the hottest ticket in town for a very long time.
From where I'm sitting, having shifted to JavaScript, I've got a fuck ton of job opportunities open to me and it's been that way for the better part of a decade.
It may not be "pure" coding, it may not be the most efficient code, it may in fact be a whole pile of steaming turd, but you know what? - it's fun to work with and there's MILLIONS of developers working with it.
Don't like that? - your choice, your ivory tower. Suck it down.
Re:Hateful for you, maybe? (Score:5, Insightful)
As a mid-life greabeard that started my career on Z/OS / MVS writing JCL and running COBOL and SAS jobs, I like JavaScript. It doesn't have the obtuseness of C, the ultra-strict type-checking of Pascal, the verbosity of COBOL, class chaos of Java, the mind-bending notation of PostScript, nor the escapee from the loony bin mentality of SQL
I also like R & Python.
JavaScript is everywhere... browsers, client side and server side apps, scripting, PDF, IoT, phones and on and on. It has built-in facilities to do just about everything you need, and easily extendable if it's lacking some component. Math is handled in a manner that makes sense and reading code is fairly easy to do.
Could it be better? Sure. But, it could be A LOT worse.
I find it extremely impressive that Bun was written by a single individual. Very much like the early days of Linux (v0.01).. which was written entirely by Linus. Congrats, Jared, on an impressive feat!
One thing - anyone have any info on the security of Zig and Bun? E.g. By default, C is so insecure a papercut will kill you. Whereas Rust has some built-in immunity to commonly stupid mistakes that even seasoned C programmers still make.
Re:Hateful for you, maybe? (Score:5, Insightful)
As a mid-life greabeard that started my career on Z/OS / MVS writing JCL and running COBOL and SAS jobs, I like JavaScript. It doesn't have the obtuseness of C, the ultra-strict type-checking of Pascal, the verbosity of COBOL, class chaos of Java, the mind-bending notation of PostScript, nor the escapee from the loony bin mentality of SQL
I also like R & Python.
JavaScript is everywhere... browsers, client side and server side apps, scripting, PDF, IoT, phones and on and on. It has built-in facilities to do just about everything you need, and easily extendable if it's lacking some component. Math is handled in a manner that makes sense and reading code is fairly easy to do.
Could it be better? Sure. But, it could be A LOT worse.
I find it extremely impressive that Bun was written by a single individual. Very much like the early days of Linux (v0.01).. which was written entirely by Linus. Congrats, Jared, on an impressive feat!
One thing - anyone have any info on the security of Zig and Bun? E.g. By default, C is so insecure a papercut will kill you. Whereas Rust has some built-in immunity to commonly stupid mistakes that even seasoned C programmers still make.
Thank you.
There is some hope - and perhaps my wrongly modded status on this may reverse.
The best thing that happened to JavaScript in the last decade, was TypeScript.
It 100% turned it into a "grown-up" language.
JavaScript is fun - but hell, all code is fun - regardless of language - and only an idiot would say something like "kill " or " is garbage"
I rest my case.
Re: (Score:2)
There are plenty of other transpilers to JS, e.g.: Groovy, Smaltalk, Lisp, CoffeeScript etc.
Re: (Score:3)
The best thing that happened to JavaScript in the last decade, was TypeScript. It 100% turned it into a "grown-up" language.
TypeScript: The thing that convinced people who never met Smalltalk in their life that Javascript was a grown-up language.
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
JavaScript was influenced by Smalltalk? That's like saying that the iPhone was influenced by the Z3.
All OOP languages were influenced by Smalltalk just like all modern computers were influenced by the Z3.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
I'll disagree. TypeScript, like ES6, seems to misunderstand the language. There's this strange trend where people want to make JavaScript act like a completely different language, and so layer things on to it to try to make it look a little bit like what they want, then complain when it isn't. For what its worth, I think TypeScript's approach is probably the best way to do this, and it does try to stay out of the way of the language. It's the whole idea that I think is misguided. It really does seem lik
Re: (Score:2)
Re: (Score:1)
JavaScript was written in 8 days by a single individual. Not knocking the developer of Bun, just pointing that out.
Let there be light... (Score:2)
Re: (Score:2)
>There's no snobbery, there's no nasty gray beards sarcastically pontificating in their ivory towers "RTFM".
baahahahahahah lollllolololl... Are you serious? The amount of ridiculous snobbery, elitism, and neckbeardism in the Javascript world is frightening. It is absolutely not immune to anything you suggest.
Re:Hateful for you, maybe? (Score:5, Interesting)
I recall a time when PHP received this type of irrational hatred - I guess it's a sort of elitist view that "these kids can't code".
For quite some time, PHP deserved all the grief it was getting. It was a security nightmare. I remember, for quite a few years, it was rare to receive a SANS newsletter that didn't include a report on yet another major vulnerability in PHP. And it doesn't help your language's security reputation when you learn your crypt function is completely broken and the response is to debate whether or not to bother fixing it.
Fortunately those days are behind us; PHP is no longer a dumpster fire of a language. But I don't think the hatred it received "back in the day" was irrational at all.
Re: (Score:2)
It's not the security problem it once was, true. But the language itself is still has problems that cannot be corrected, lest they break backwards compatibility. For example, implicit string to number conversion in expressions, and the various forms of equality testing (triple equals!) that arose from that issue. Been years so I'm sure there are other examples. PHP served me well for a long time but I'm just as happy to not use it for anything anymore.
Re: (Score:2)
I am, perhaps unfortunately, heading the other direction - at least for web stuff. I've happily used perl for stuff like web scripts in the past, but the pressure from above lately is, when writing anything new for the web, to use a language a younger coder is likely to know - and perl is probably not it. Another other option would be python, but frankly I think speed's a concern there - plus there's no guarantee someone who's more web-centric than I am will actually know python.
Re: (Score:2)
Re: (Score:2)
PHP is server side, JavaScript is client side. You want to waste a bunch of CPU cycles and RAM on hardware YOU'RE paying for, be my guest. When you start hijacking MY hardware to power your shitty site, I'm not a happy camper.
Limits of web application interaction with user (Score:2)
Say you want to develop a web-based drawing program that runs entirely server-side. It could capture the user's clicks using the server-side image map mechanism, in which the client POSTs the coordinates to the server as values in a form and then the server responds with a document containing the new state of the drawing. However, HTML forms specify no way for a client to send a drag path, giving the user no way to draw a curve other than by click-click-clicking along the edge with a polyline tool, with a f
Re: (Score:2)
Instead, it has an ecosystem of sharing, of inclusivity - yes, a "mistaken engineer" can pick it up and write some fucking awful code, but for that moment, they _feel_ like an engineer and it's a _great_ feeling - and why shouldn't it be?
That "ecosystem of sharing"....we call that "Free Software". It has existed for decades and Javascript in no way invented it.
Re: (Score:3)
You have a huge choice of languages that compile to Javascript. It's not ideal but you can't really complain about JS being crap these days when you aren't required to use it.
Seems like the answer is clear (Score:1)
some of the biggest and most successful companies of all time, have embraced JavaScript and _made_ it work....Are they all wrong? Are they all "mistaken engineers"?
Doesn't a world rife with massive security breaches every week (or more like every day now) say yes to that question?
Because obviously something is massively wrong.
Re: (Score:2)
some of the biggest and most successful companies of all time, have embraced JavaScript and _made_ it work....Are they all wrong? Are they all "mistaken engineers"?
Doesn't a world rife with massive security breaches every week (or more like every day now) say yes to that question?
Because obviously something is massively wrong.
What?
So, JavaScript is responsible for all those security breaches?
I think someone needs to do a little homework here. ;)
Re: (Score:2)
Re: (Score:2)
Look here everyone, this man claims no Javascript based systems have ever been compromised!
Wanna bet about how many of those incidents are actually a fault of bad C++ code?
Re: Visible Confusion (Score:2)
One of the constants of the universe is that superkendal will come in to any conversation and say something very stupid.
Re: (Score:2)
By far the majority of hacks like that come from C and its very low level memory and string manipulation system. Yeah I get that CPUs are lower still and C is a useful abstraction over assembler but the elitist snobs who only program in C because higher level stuff is beneath them are not helping.
And before you whine that I am incompetent coder I have programmed a Haskell compiler 35 years ago and last week I wrote my own CPU on an FPGA and built a CAN bus tester from scratch in hardware. For the record mos
Re: (Score:1)
There is something to be said for patience, looking at newer generations fumble and learn.
But engineering is about solving problems then moving on and solving newer, more advanced problems, leaving solutions behind. Even across generations. What we're seeing with the hordes of great unwashed trying their hands at php and javascript is more of a regression: Lots of fumbling and badly reinventing already-solved problems (and not even their solutions). So we're seeing lots of regression. And that's not engine
Re: (Score:2, Funny)
Kill Javascript.
Yes please. At this point I'd support anything to prevent us having to put up with Rosco P. Coltrane's stupid posts.
Re: (Score:2)
Can you be more specific about what makes Javascript so bad?
Is it because it runs in a browser, or is it because it's not designed as a "functional" language, or something else?
Like any programming language, Javascript has its flaws. Which of these flaws makes Javascript specifically stand out as a language to be hated?
Re:I have a better idea for a better future (Score:5, Informative)
There's a pretty good book by Douglas Crockford called JavaScript: The Good Parts that makes a pretty good case for exactly what is wrong with JavaScrip. Crockford's approach is that there are certain "features" of the language that you simply must never, never use, and then you'll be OK.
Re: (Score:3)
This is a good book on Javascript's good and bad parts. Quoting Chapter 1, "Analyzing Javascript":
JavaScript is built on some very good ideas and a few very bad ones.
The very good ideas include functions, loose typing, dynamic objects, and an expressive object literal notation. The bad ideas include a programming model based on global variables.
JavaScript's functions are first class objects with (mostly) lexical scoping. JavaScript is the first lambda language to go mainstream. Deep down, JavaScript has more in common with Lisp and Scheme than with Java. It is Lisp in C's clothing. This makes JavaScript a remarkably powerful language.
This does not come across as a language that should be "killed" but a good language that has some flaws. I'd categorize every major language this way.
Re: (Score:2)
Re: (Score:1)
WARNING: I've never actually written a program in JavaScript.
I don't like JavaScript because it explicitly won't do what I want to do. For good reasons. I want to read and write disk files. A language that won't do that is useless for my purposes. A language that will...I don't want that running on my system without KNOWING that I trust the folks who wrote the code. (Maybe not trust perfectly, but still, trust.)
IIUC, JavaScript manages to have the worst of both worlds. The basic language can't handle
Re: (Score:3)
So your beef isn't with Javascript then, it's with the environment in which Javascript runs. It would be terrible indeed if we were to let random Javascript from random web sites have access to our local file system. This is not a Javascript limitation, it's a browser security limitation.
This is similar to building embedded apps that run on task-specific hardware like microwave ovens. In these applications (typically C) you also don't have access to a file system, because there isn't one. The language itsel
Re: (Score:2)
FWIW, Javascript can't access the local filesystem without user interaction, and even then only in a very limited way.
There is localstorage, but that's managed by the browser and restricted too.
Re: (Score:2)
You are an idiot.
With JavaScrip you can write and read files just like in any other language.
No idea why you think otherwise, idiot.
Re: (Score:2)
They don't actually know because they've never taken the time to learn the language. I expect you'll mostly get complaints related to implicit coercion or some non-specific complaints about the type system, which they also don't understand.
is it because it's not designed as a "functional" language
On the contrary, JavaScript was originally supposed to be a Lisp variant. (In many ways, it still is.) It wasn't until someone higher up found out what Lisp was that he had to change course. The requirement, if I remember the story, was that whatever he made should look
Re: (Score:2)
Yeah, I should have said it's not a *pure* functional language. But I agree with your points about nonspecific complaints.
I admit, Javascript took me longer to learn than many of the other 25 or so I've used in my career. But Now that I'm to the point where I don't have to Google everything, I'm rather enjoying it. You do have to understand good software design, it doesn't hold your hand in that regard. But I often discover that it has functionality built in, that I was expecting to have to write myself.
Re: (Score:2)
he only thing really missing [in Javascript] is tail call optimization,
That is not really a feature of the language, but of the compiler/Jit.
E.g. Safari does do tail call optimization, Chrome/V8 and Firefox do not. No idea about the Node.js compiler.
Re: (Score:2)
It is absolutely a language feature. I have no idea what bizarre criteria you're using to draw that line, but you're very wrong here.
Re: (Score:2)
it is not a language feater.
How the funk can the language decide if the compiler is doing tail recursion optimization or not?
TRO means: you reuse the stackframe from the first call, instead of allocing a new one. It also means, you jump back o the entry point of your function with a JUMP INSTRUCTION, as in opposed to no optimization, whre you do a JUMPS SUBROUTINE.
Every language can have TRO, if the compiler writer chooses to implement it.
Re: (Score:2)
Sigh... Every language feature must necessarily be implemented by an interpreter or compiler. This isn't complicated.
You might as well say that there are no language features because "how the funk can the language decide if the compiler is doing ___ or not?"
You're drawing a pointless line here.
Every language can have TRO, if the compiler writer chooses to implement it.
I'm going to blow your tiny little mind: Every language can have any feature if the compiler writer chooses to implement it.
You're way out of your league here.
Re: (Score:2)
Sorry,
the one who is why out of the league is you.
Either the compiler does TRO or it does not.
Has nothing to do with the language.
It is as simple as that. Or why do some Javascript implementations have it and some not? Hu?
Is there a secret specification in Javascript that says: you shaltst never do TRO?
Re: (Score:2)
Get a clue dude.
How would you do tail recursion in Forth? I can't wait to make fun of you when you give an obviously ignorant answer.
Re: (Score:2)
Forth is an "assembly like language".
I guess some pops and pushes would do it.
Sorry, finding a simple example where it might not be easy, does not make your claim that you can not do TRO in Java, JavaScript or C or C++ in any way valid.
Re: (Score:2)
Forth is an "assembly like language".
Wow, you really have no clue.
Re: (Score:2)
I have a damn clue.
What is your stupid problem?
All languages that get compiled to a reall assembly language can have a compiler that does Tail Recursion Optimization.
Forth is an assembly like language, what else would it be?
If you think other wise make an argument, but it seems it was late at your place.
Re: (Score:2)
I have a damn clue.
Obviously not!
Forth is an assembly like language, what else would it be?
Forth is nothing like an assembly language. Not even a little bit. Get a clue, dude.
If you think other wise make an argument
What's to argue? You might as well have said that the moon is a kind of fish. Forth is not an assembly language. It is nothing like an assembly language. They are not similar in any way.
You are not qualified to have this discussion. I think I'm done wasting my time with you.
Re: (Score:2)
Forth is nothing like an assembly language. Not even a little bit. Get a clue, dude.
I programmed in Forth till roughly 1987.
So I can grantee you: it is an assembly like language.
It has not even a loop or a function construct ...
Perhaps you are mixing up the name with something else.
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
It has not even a loop or a function construct ...
What do you think : is for anyway? Ugh... Why am I wasting my time with an obvious liar? You clearly haven't used forth.
Had you actually used Forth, instead of lying about it, you'd know that do...loop are among the standard words.
Should you have found yourself with a minimalist Forth lacking those words, one of the first things you'd have done is implement conditionals and loops. Such a task is trivial, after all. In fact, it's a basic exercise I would expect anyone learning forth to have done anyway.
Re: (Score:2)
I programmes in Forth from 1984 to 1987.
No idea about you. I gave you the Forth link on wikipedia. You probably did not read the link?
I assume you are mixing the language up with something that sounds similar.
Forth is very obviously nothing like an assembly language, you pathetic liar. Get a clue.
As every instruction build in in forth is a an assembly instruction - sorry no idea what you are talking about.
Or what is push, dup, pop etc. supposed to mean?
Btw, I take the liberty to quote a dictionary entrance
Re: (Score:2)
This is getting pathetic. Look, you've been called out. You clearly know nothing about forth. Stop lying about it and get informed. It's pointless to lie when we both know you're lying.
I assume you are mixing the language up with something that sounds similar.
Nope. See, not only have I used forth, I've written forth implementations. You, however, don't seem to know anything about the language even though you claim to have years of experience in it.
As every instruction build in in forth is a an assembly instruction
Nope. Not even close. For example, : is a very important forth word. There is no assembly instruction equivalent for that word
Re: (Score:2)
Sorry,
Narcc, I linked you the wiki page.
Either you mean a different Forth than the rest of the world or you are completely out of your mind.
Forth is the lowest level language one can imagine above assembly. Even my Macro assembler that came bundled with my 1980 UCSD Pascal is higher level.
Forth is a high-level language. Your first clue should have been the fact that forth programs are generally portable between machines with different processors. I can write a forth program that will run unmodified on a for
Re: (Score:2)
I linked you the wiki page.
Your illiteracy is not my problem. Get an adult to help you read your own link.
This is getting boring.
You've clearly demonstrated that you don't understand assembly language and that you don't understand Forth. You are not qualified for this discussion.
You are also, apparently, too stupid to be educated, but I'll try one more time anyway.
For the last time: Forth is nothing like an assembly language. Assembly languages have a 1:1 correspondence with machine code. That's the whole point. Assembly langu
Re: (Score:2)
You've clearly demonstrated that you don't understand assembly language and that you don't understand Forth.
I understand both. Actually something like 10 different assembly languages/processors.
The one who does not understand, is you.
Forth is an assembly like language, there is nothing to discuss about.
OMG, you are so fucking stupid it hurts. Forth absolutely has procedures, you moron.
Forth has no procedures. It has user defined opcodes, which are looked up in a dictionary, and work like subroutines. That
Re: (Score:2)
Forth is an assembly like language, there is nothing to discuss about.
Wow, you're still going with that obvious nonsense? You've been proven wrong about this over and over again. Your own stupid link proves your wrong. This is beyond pathetic. Forth is not an assembly language, shit-for-brains. It's a high-level programming language. Get a fucking clue, you moron.
Learn to read, dumbass [forth.com]:
Forth is a high-level programming language
That's from Forth, Inc., a company cofounded by Chuck Moore, the guy who invented the language. Do you think you know better than they do? Get real, you fucking idiot.
Let's look at mor
Re: (Score:2)
Re: (Score:1)
What would you replace it with?
Re: (Score:2)
In theory, it would be possible to replace many (not all) script-driven web applications that run on the client side with static or server-side-generated documents and HTML form-driven web applications. It would be possible to replace other script-driven web applications with a native helper application, distributed as source code under a free software license, that each end user downloads, builds, installs, and uses. In case the user is using a platform to which the native helper application is not ported,
Re: (Score:1)
That seems like a much higher bar to entry and incredibly insecure. Sure, open source is reviewable but you're average user doesn't have that capability. I remember the days of Flash, Java applets, ActiveX and it wasn't good on the security front. Realistically, any replacement for javascript would need to fill the same role Javascript does, especially including at least cross-platform, sandboxed, and client-side.
Re: (Score:2)
It took me nearly 20 minutes to load this page to type this comment.
Let Javascript die. Clients viewing your page shouldn't have to bog down their machine with your virus-laden "frameworks" that take forever to download and render while eating up 100% CPU.
It takes two buns to make an ass. (Score:5, Funny)
The singular name implies that it's half-assed.
Re: (Score:3, Funny)
No, it's just half-baked -- pop that bun back in the oven.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
This is a pretty silly comment, because I guarantee that just about any assembly language YOU write is not going to have the performance of assembly language output by an optimizing compiler.
Re: (Score:2)
Depends on the processor.
You hardly find a C compiler that compiles reasonable fast code for 6502 e.g.
llvm-mos (Score:2)
Also true of 8080 family 8-bit processors. SDCC [sourceforge.net] is a compiler targeting 8-bit processors, such as Zilog Z80 and Sharp SM83. (SM83 is the CPU core in the Game Boy and Game Boy Color system on chip.) As reported in "Choosing tools for Game Boy development" [gbdev.io], SDCC produces noticeably less efficient code for these architectures than an intermediate assembly language programmer would. The Master System and Game Boy homebrew communities would be very interested to see what published compiler beats SDCC.
However, th
Re: (Score:2)
the compiler you're probably thinking of. :P
Na, I was thinking about Atztec C
Love you slashdot... (Score:5, Funny)
Someone typing "kill javascript" and calling it "hateful", gets modded up as Insightful, whilst someone actually trying to be realistic and open, gets modded down as flamebait.
God damn, I must be new around here, right?
Well, no, but I do live in hope that maybe one day, some sense may prevail.
Re: (Score:2)
This place has probably 100 regular users and 10,000 sock puppets to get mod points.
Re:Love you slashdot... (Score:5, Funny)
Re: (Score:3, Informative)
Yes, you are new around here ;)
Re: (Score:2)
Do I need to get off your lawn?
Re: (Score:2)
Re: (Score:2)
I don't know. It clearly isn't going to happen, but the last time I looked into it, it was totally insecure against remote code substitution exploits. (I.e., the code calls a library, but the one that's delivered isn't quite the one that was asked for.) Have they implemented code signing?
I'm not in a position to criticize it, because after I looked at it I decided not to use it, and that was over a decade ago. But at the time that I looked, those comments, while excessively emotional, would appear to ha
Re: (Score:2)
To be fair, most other languages aren't secure against remote code substitution either, but that's probably because their designers assumed no programmer would ever be stupid enough to load untrusted code from someone else's computer at run time. Whereas in most JavaScript frameworks these days, it seems to be the only way to get anything done ;-)
It will be fast for 2 weeks (Score:3)
Re: (Score:2)
You speak in pejorative terms, but the underlying point is not wrong.
Any new technology that is designed well should run faster than older technology. This is in part because the older technology has been called upon to do many more things. Once the new technology grows in maturity until it too can support all those additional functions, it too will be slower.
They call it BUN? Bun! Ha ha ha ha ha ha! (Score:2)
I suppose that's a lot shorter than calling it "buttocks" but, it seems to tell you something about how the developers feel about it. They probably also considered "moon" but! Oh, yes, they could have called it "butt".
Bun! They called it BUN! Man... I wonder if they share what they're smoking BUT, it's almost certainly "crack". Hoot!
It's Javascript, or ECMA (Score:2)
Granted, it's been 20 years now. But the bad taste still lives. I've actually turned down jobs where there was a hint
What's with all the paid advertisements? (Score:2)
There was the obvious advertisement for MS Office yesterday, now this, which is basically just a copy pasta version of a press release. Did I miss a memo or something and the former red banner for paid stories is a thing of the past now?
Did anyone get bun --help to work? (Score:2)
Tried the listed install:
Re: (Score:2)
That's just regular Linux distro incompatibility. The npm error looks like it was built for a Linux distro with a RHEL-style OpenSSL. I don't know exactly what's causing the bun issue. But it's all Open Source, man - just recompile it locally.
Something Something Pig Lipstick. (Score:2)
I'm sure someone can come up with a better scripting language that is NOT javascript, instead of spending so much time and effort trying desperately to make something performant that's inherently... Not..
Looking for another captive audience (Score:2)
Being a great and complete tool (bundler, transpiler, package manager).
How's that decentralization of the Internet going, huh?
Everyone is trying to make all-in-one solutions and establish their own store, distro, or repository these days. I've wasted way too many hours of my life fighting with custom package managers, weird build environments, and all that "authentication" bullshit. Screw it. Web 3.0 can bite me.
Where's the embedding? (Score:2)
What I really want is a usable and feature-complete JavaScript engine for embedding.
Re: (Score:3)
"On the edge" means what, to these kids?
I know what it means in networking, but those are switches, and no javascript on them.
With respect to server hardware, it means distributing compute resources at or near the location where the data is being generated, not in a centralized data center or the "cloud". For whatever reason, it seems to be a trendy concept. Commonly, that means there is more limited horsepower is available for working on any one task.
Re: Somebody explain please (Score:2)
Re: (Score:2)
Just about every dimension of development has an edge where development is happening. Probably Snobol doesn't anymore, but Smalltalk does. That JavaScript would is totally expectable and appropriate.
Just because the area you're looking at has an edge, doesn't imply that other areas don't. Think of it as a bacterial culture in an n-dimensional petri dish.
CDN-side code (Score:3)
My first guess is that this use of "edge" refers to Cloudflare, CloudFront, and other caching proxies, which may have a limited ability to run some server-side transformation of the resources retrieved from the origin server.