D3 4.0 is modular. Instead of one library, D3 is now many small libraries that are designed to work together. You can pick and choose which parts to use as you see fit.

The default bundle combines about thirty of these microlibraries.

The default UMD bundle is now anonymous.

To the consternation of some users, 3.x employed Unicode variable names such as λ, φ, τ and π for a concise representation of mathematical operations. A downside of this approach was that a SyntaxError would occur if you loaded the non-minified D3 using ISO-8859-1 instead of UTF-8. 3.x also used Unicode string literals, such as the SI-prefix µ for 1e-6. 4.0 uses only ASCII variable names and ASCII string literals (see rollup-plugin-ascii), avoiding encoding problems.

No d3 global is exported if AMD or CommonJS is detected.

The non-minified default bundle is no longer mangled, making it more readable and preserving inline comments.

Microlibraries are easier to understand, develop and test. They make it easier for new people to get involved and contribute. They reduce the distinction between a “core module” and a “plugin”, and increase the pace of development in D3 features.

Small files are nice, but modularity is also about making D3 more fun.

D3 now passes events directly to listeners, replacing the d3.event global and bringing D3 inline with vanilla JavaScript and most other frameworks.

It is unrelated to the technology company AMD and the processors it makes.

This is a copy of the "AMD" document in the repo, kept here to maintain historical links. If this document differs from the one in the repo, the repo version is the correct one.

Normally you should not register a named module, but instead register as an anonymous module: define(function () {}); This allows users of your code to rename your library to a name suitable for their project layout. It also allows them to map your module to a dependency name that is used by other libraries.

For instance, Zepto.js can be mapped to fulfill the module duty for the 'jquery' module ID. There is a notable exception that does register as a named module: jQuery.

This allows those other dependencies to share the same module instance.

Because it requires less code to do the same thing as other programming languages projects can be developed faster

An Oligopoly of a few large, mature firms that compete with each other through free market checks and balances (think Detroit auto manufacturers), or

Occasionally, like with search engines, #2 occurs because the incumbents gain massive economies of scale (classic Microeconomics), where by virtue of their being large, the cost to produce each incremental good or service at scale becomes much lower.

The slightly more dangerous scenario where the market has a winner-take-all effect, where one firm or organization ends up controlling over 70% of the market.

When markets are new and “hot”, they often follow that frenzy of dozens — if not hundreds — of entrants trying to grab market share from each other.

Inevitably, most of these new entrants get wiped out over a decade or two and their market share goes down into the single digits (often zero). The end result is that the market often resembles one of two possible situations:

A MicroJS library is a small JavaScript library with a single purpose; you’ve already seen me use a variation of this phrase several times in this article

These applications load faster and foster a good modular development approach.

Another important MicroJS attribute is independence. Ember, Backbone—even Bootstrap to a degree–have hard dependencies on other libraries. For example, all three rely on jQuery. A good MicroJS library stands by itself with no dependencies. There are exceptions to the rule, but in general, any dependency is another small MicrojJS library.

Micro-frameworks are definitely the pocketknives of the JavaScript library world: short, sweet, to the point. And at 5k and under, micro-frameworks are very very portable. A micro-framework does one thing and one thing only — and does it well. No cruft, no featuritis, no feature creep, no excess anywhere.

Self answer: 4d00bdf it seems to be to prevent shifting lines in source maps.

Maybe it would be simple to always add that line, and always shift the source maps by 1.

This semi-colon is added to prevent changing the code behaviour (the famous line ending with parentheses, etc) Most people will use a JS minifier If they don't, a single extra character is unlikely to change much If I'm right about all the above: Why don't we simply always add a semi-colon regardless of what the file ends with?

yeah I discovered too late that #310 exists and does that

If a UTF8-encoded Ruby string contains unicode characters, then indexing into that string becomes O(N). This can lead to very bad performance in string_end_with_semicolon?, as it would have to scan through the whole buffer for every single file. This commit fixes it to use UTF32 if there are any non-ascii characters in the files.

Sure, you have a few extra newlines and semicolons, but the minifier will remove them anyway so no harm.

What is the point of avoiding the semicolon in concat_javascript_sources

   (intermediate value)(...) is not a function
       at something.source.js:1

   ({
     // other.js
   })()
   (function() {
     // something.js
   })();

And we shave off 6 or so seconds, that is huge.

And no need to walk backwards through all these strings which is surprisingly inefficient in Ruby.

Essentially after any edit of any js file if we reload /qunit it takes us about 10 seconds for the page to render.

Since the common problem with concatenating JavaScript files is the lack of semicolons, automatically adding one (that, like Sam said, will then be removed by the minifier if it's unnecessary) seems on the surface to be a perfectly fine speed optimization.

reducing it down to one call significantly speeds up the operation.

Granted it's a toy example using StringIO

I feel like the walk in string_end_with_semicolon? is unnecessarily expensive when having an extra semicolon doesn't invalidate any JavaScript syntax.

I was debugging our painfully slow reload times in Discourse when running qunit.

ECMAScript is a programming language itself, specified in the document ECMA-262. In other words, ECMA-262 is the specification of the programming language ECMAScript. JavaScript is an implementation of ECMAScript which conforms to the ECMAScript specification. JavaScript implementations can also provide additional features not described in the specification.

The ECMAScript standard does not include any input/output (I/O), such as networking, storage, or graphics facilities. In practice, the web browser or other runtime system provides JavaScript APIs for I/O.

So I was wondering: do you have any examples of broken source maps caused by this approach? I don't use source maps so it'd be nice to have something to start from.

if we can fix source maps, unconditionally adding ";\n" would be a better solution

Unfortunately, given how widely used concat_javascript_sources is, this required changing a lot of tests. It would be nice if we could remove some of the duplication in these tests (so that similar changes would not require updating this many tests), but that can come in another PR.

I wondered if we could change the way semicolon addition works to simply append a semicolon on the last line of the JS file and omit the extra newline.

Inserting on the same line seems fine

Any news on this one?

Thanks for posing that question @SamSaffron

They also lacked a lot of the features users wanted, e.g. more options for searching games and wishlist notifications.

In recent years, Steam also added the features and options that its users were asking for.

P.S. regarding the most obvious question: I have deleted all user information from the database and will not be able to satisfy requests for an export of your collected data - most notably your wishlists.

Of course, this decision was not made easy. But it was made easier when I looked at the steadily declining visitor count, probably caused by better offerings from other websites that also compare prices to other stores than only Steam. At some point one starts to ask themselves if this is still all worth the trouble. And sometimes you just have to let go.

SteamPrices.com has always just been a hobby of mine. It was a nice playground to test and improve my programming skills and I wanted to apply all best practices that I learned. We had a complete website relaunch in 2015 where I added a mobile friendly responsive design and accessibility. But as all hobbies go, you have to find the time and motivation to stick with it. Both were lacking in the last three years and the website went into some sort of slumber. Most tasks always were fully automated and worked without me doing something. When Steam changed their website design and code, I came back to the project to fix the apparent issues. Some issues from the early days were never fully solved and probably never would have, i.e. wrong price information during a sale for games that are part of a cheaper bundle or package. Additionally, defending against people that tried to gather price information from SteamPrices.com instead of Steam was always feeling like an uphill battle.

There was a need for websites like SteamPrices.com but this has changed in my opinion. More and more features became obsolete and I countered it with meta-analysis like Price Tracker and Publisher comparison, but the website statistics show that these features were not being used a lot - in the end, they were not in spirit of the initial website idea and goal: compare prices from different Steam regions.

Of course user expectations for titles are the most important thing. You don’t want to sell a tiny game at AAA price, because you won’t sell many copies and you’ll make your gamers feel ripped off.

Of course, most of your sales won’t come at the full price, but your original price is a starting point and can only go lower. So choose wisely.

This thread is more than 5 months old. It is very likely that it does not need any further discussion and thus bumping it serves no purpose. If you feel it is necessary to make a new reply, you can still do so though. I am aware that this thread is rather old but I still want to make a reply.

If you think that for every problem there is a simple and easy solution, either you don't understand what is a problem or you don't understand what is a solution.

"You will not argue with, comment on or question the actions/authority/ or comments of the Paradox staff (Administrators, Moderators, etc.) in a public forum. Should you wish to do so you are directed to contact the Paradox staff via PM"

should be in the base game, not as a DLC.

Good bit of content, but very little of it. 10€ for leviathans is a salty price for what it offers, if this was part of the Utopia DLC it's asking price of 20€ would have been easier to justify. Worth getting just to have more content in the game but paradox is really stretching by asking money for this little. Could/should have been a free update really.

I didn't mind 20 bucks because Paradox is one of the most linux-friendly companies out there

"i dont use this specific thing so this whole pack is irrelevant to me"

I'd suggest there ought to be config to disable source maps specifically, and specifically for either CSS or JS (not alwasy both), without turning off debug mode. As you note, debug mode does all sorts of different things that you might want with or without source maps.

I don't understand why this isn't being considered a bigger deal by maintainrs/the community. Don't most Rails developers use SCSS? It's included by default in a new Rails app. Along with sprockets 4. I am mystified how anyone is managing to debug CSS in Rails at all these days, that this issue is being ignored makes sprockets seem like abandonware to me, or makes me wonder if nobody else is using sprockets 4, or what!

Meh... as I said earlier, I think using Webpack is the recommended way now. Another issue is there is no way to generate source maps in production.

I am finally getting usable source maps for SCSS, wow!

I don't myself understand what's going on, it clearly has something to do with source maps, but may also have to do with other sprockets changes.

sprockets 4 makes Chrome browser identification of SCSS css lines _worse_

But maybe few are still using sprockets at all, for JS or (S)CSS anymore? Hard to say.

But yeah, I'm not sure how you would determine which was the "recommended way" really. I don't see anything in Rails docs saying either way.

But last I have seen comments from DHH, he considered webpack(er) recommended for JS, but Sprockets still the preferred solution for (S)CSS.

I don't really understand what's going on. Clearly source maps have something to do with it -- a source map feature that doesn't handle SCSS very well, apparently.

If I can't do something to change the sprockets 4 debugging experience I am seeing, I am going to probably downgrade back to sprockets 3. I am finding it impossible to develop CSS the ways I am used to.

Is there a PR to... something? sassc-rails? That would make the patch not necessary? (I don't know if there's any good way to monkey-patch that in, I think you have to fork? So some change seems required...) Should the defaults be different somehow? This is very difficult to figure out.

I am not sure this whole ecosystem currently has much maintainers unfortunately. :( Pick your reaction

Is there a PR to... something? sassc-rails?

I'm not sure about all consequences of my change and this is very complex.

# This behavior can be disabled with: # # environment.unregister_postprocessor 'application/javascript', Sprockets::SafetyColons

For JS developers who are colonfobic

putting a line break before the directive in the Gem (not suitable because I don't own the gem)

I've been able to find three alternatives ahead of the bugfix

I confirm that since version 4.0.0 of sprockets, a single line directive is breaking the source maps and the javascript debugging system by consequence.

There's not a way to do it at the moment without enabling all debug features.

I don't get it. Can someone please explain? I've upgraded my Rails project to Sprockets 4, just to get source maps in production. Instead I got sourcemaps in development?

You'll still get the correct backtrace, and can use that to view your own sources locally though.

Goal: Give bug trackers like bugsnag access to sprockets generated source maps.

Note: The above rake task executes after the default rake assets:precompile runs, it doesn't replace the default rails task

Any update on this?

Sorry to bump this but we're also in the same situation

we want source maps in production (like DHH)

I totally understand that there may be a majority still considering this a bad practice and thus keeping it disabled by default in production seem ok. But there could at least be an option to enable it for people who want to, no?

After waiting years for sprockets to support this we were very happy to see that sprockets 4 officially added support (thanks ), but then when trying to upgrade we noticed there's actually no way to use it in production... (without brittle hacks mentioned above).

Now that source maps in production by default seems to be the official Rails position, can we expect some movement on this?

If you don't mind putting the sourcemap url in the minified JS

minified_url: MINIFIED_URL_PATH, source_map: HTTP::FormData::File.new(LOCAL_SOURCEMAP_PATH)

//= link application.js.map

While I understand orgs wanting not to expose their unminified source, it's security through obscurity (meaning it's not adding any real security).

The only place I can find it is in the sprockets-rails gem. javascript_include_tag calls this: def find_debug_asset(path) if asset = find_asset(path, pipeline: :debug) raise_unless_precompiled_asset asset.logical_path.sub('.debug', '') asset end end

If I'm understanding correctly, this means that Sprockets only adds sourceMappingURL when assets are dynamically compiled.

I'd be happy to open a PR for this, but I'm not sure exactly what code needs to change. default_source_map.rb and source_map_utils.rb seem like candidates, but I'd appreciate guidance

It seems I'm in the minority, and Sprockets seems to already pretty far along in the beta process, so at most we should add a configuration option to enable it for static compilation.

modifying my build process to send the source map to my error logging service, Rollbar

Sprockets 4: The effect of config.assets.debug does not match the rails documentation.

This appears to be an undocumented breaking change. For example, the word "debug" does not appear in the sprockets 4 changelog.

I'm getting mixed signals

I don't even know how to tell if they're working 100%, I'm getting mixed signals ..

Should it only contain link* calls?

When should I use link, vs dir, vs. tree?

but I still have no idea if I'm writing this new file correctly.

The docs say: "When using Rails and Sprockets in development mode, no assets are concatenated."

concatenation still occurs.

If the bug is still there I think that it is better if it is open so others can find it if they run into the same issue.

Closing this because it's obviously not going to get fixed and it's cluttering my open issues

To achieve this, we created a small Compressor which wraps the Uglifier compressor and links the source maps so they are written to disk.

Here's the four case: foo.js Load/Require dependencies Concatenate dependencies foo.js.map Load foo.js Currently grabs metadata[:map] from asset to build an asset, need to move that generation somewhere else to accomplish de-coupling map generation foo.debug.js Load foo.js Load foo.js.map Add comment to end of foo.js with path to foo.js.map foo.source.js The raw file on disk, the map file will need to point to source files.

Now I just need to figure out how to decouple this ball of mud

The way we do it currently is by calling load from inside of load, via different "pipelines" and processors which is quite elegant and completely impossible to work with.

Certainly appreciate the work you've done!

If I can find some time, maybe I can help pitch in somehow.

I'm kinda stuck at the moment, going around in circles. Everything is really heavily coupled. I would like to get to the point where no load is called from within processors, but i'm not sure if that's possible. Currently the API and the caching strategies are fighting me at every step of the way. I have a branch where i'm hacking through some refactoring, no light at the end of the tunnel yet though :(

That should work, but it's a non-trivial change.

For the $$$ question, nothing comes to mind. These problems i'm hitting up against are larger than a contractor could solve in a few hours of work (which would be hundreds/thousands of dollars).

Right now major changes require a deep and broad understanding of the codebase and how things get done.

If a company really wanted to invest, I would prefer they dedicated an employee for X hours a week for Y months than money.

Money could be good if it is spent to provide some of the above things. Money on it's own is hard because then it means I would have to spend time book-keeping and managing instead of programming.

Triaging issues, reproducing bugs, fixing reported bugs are all helpful.

Yeah, can we pay money to make this go faster? Serious question.

I think that's fine, but I also don't particularly care about @mikeycgto's desire to not have the linking comment be present in the minified JS.

Progress is slow though. I want to change how assets are loaded, the current implementation of "pipelines" is challenging to work with.

Our team is also looking into generating source maps in production/staging for error reporting (via Airbrake).

I want source map in prod too (for error tracking, same as @vincentwoo)

Could you explain your use case in a bit more detail? How are you using source maps without source map comments? Are you uploading them to a bug tracker?

richard.schneeman+no-recruiters@gmail.com

Married to Ruby, literally.

Puma core. Sprockets Core. Top 50 Rails contributors. Married to Ruby, literally.

Sentry supports un-minifying JavaScript via Source Maps. This lets you view source code context obtained from stack traces in their original untransformed form, which is particularly useful for debugging minified code (e.g. UglifyJS), or transpiled code from a higher-level language (e.g. TypeScript, ES6).

Abbreviations used in bookkeeping

The term taxon was first used in 1926 by Adolf Meyer-Abich for animal groups, as a backformation from the word Taxonomy

Accounting or Accountancy is the measurement, processing, and communication of financial and non financial information about economic entities[1][2] such as businesses and corporations. Accounting, which has been called the "language of business",[3] measures the results of an organization's economic activities and conveys this information to a variety of users, including investors, creditors, management, and regulators.

The terms "accounting" and "financial reporting" are often used as synonyms.

The recording of financial transactions, so that summaries of the financials may be presented in financial reports, is known as bookkeeping, of which double-entry bookkeeping is the most common system.

still compiles everything into single CSS/JS files

Reopening #162

Yes, it's true that it returns a single file, but with the more robust caching in 4.0 it works well enough in my experience.

The semantic has changed a bit as far as I understand. You need to select a pipeline in debug mode.

In order to move forwards with this issue I'll need an example app that reproduces the behavior (https://www.codetriage.com/example_app).

let me know if you've got more issues (by opening a new issue)

it's super hard to test master because i have no idea which gems need to be updated. is there a guide on how to take a rails 4.2 project to master sprockets without everything mysteriously exploding? ill try to make a repro case but its hard to tell where to even start

There's no release of sprockets 4 so there's nothing to revert. Master branch is a WIP. I would recommend using Sprockets 3.

Source maps are on my radar, but i'm playing catchup. See: #124 (comment) for a rundown of where we are right now. Source maps are a pretty big project, it's not li

I'm trying to get official time at work to dedicate to source maps, and haven't made much progress there.

But we're definitely sticking with the source map idea rather than the current (Rails 3/4) behavior of including all JS and CSS files separately while in development?

Still broken, @cannikin. Nobody's on board to investigate, much less fix it. Please do dig in

Any updates on this one? It makes debugging JS and CSS in the web inspector next to impossible when you can't get any help finding the offending code in your own source files.

Cross-posted to https://stackoverflow.com/questions/58632880/error-while-fetching-an-original-source-in-new-rails-app-sprockets-4-firefox, in hopes of reaching more people.

Sprockets 4.0 treats the ".js.erb" as the extension now. There's no mime type registered to that extension. You need to do: register_mime_type 'application/javascript+ruby', extensions: ['.js.erb']

Opal is a Ruby to JavaScript source-to-source compiler. It comes packed with the Ruby corelib you know and love. It is both fast as a runtime and small in its footprint.

Notice that the HTML elements (BUTTON, DIV, etc.) are in CAPS. We know this is bending the standard Ruby style rules slightly, but we think it reads better this way.

n this example, we are calling a function on FaaStRuby which is a new serverless platform built for Ruby developers.

we used `backticks` to jump into native Javascript to use moment.js

Hyperstack gives you full access to the entire universe of JavaScript libraries and components directly within your Ruby code.Everything you can do in JavaScript is simple to do in Ruby; this includes passing parameters between Ruby and JavaScript and even passing Ruby methods as JavaScript callbacks.There is no need to learn JavaScript, all you need to understand is how to bridge between JS and Ruby.

Think JavaScript is your only option for the front-end? Think again. Hyperstack is a Ruby DSL, compiled by Opal, bundled by Webpack, powered by React.

multi-paradigm: functional, imperative

I decided a couple of months ago to look for a way to work on faastRuby full time. Today is October 1st, 2019, and I am excited to announce that I am bringing faastRuby into Shopify. As I start this next chapter, I will be taking down all faastRuby servers. 

I decided a couple of months ago to look for a way to work on faastRuby full time. Today is October 1st, 2019, and I am excited to announce that I am bringing faastRuby into Shopify.

What happens to my functions? I encourage you to migrate your workloads to OpenFaaS.

On the “lows” side, I’d say the worst thing was the impact of not being present enough for my family. I was working a full-time job and doing faastRuby on nights and weekends. Here I want to give a big shout out to my wife. She supported me through this and didn’t cut my head off in the process.

One day last August 2018, I stumbled upon an online petition that sparked my curiosity - We Want Serverless Ruby. At that time, none of the major cloud providers had first-class support for Ruby in their serverless products. There were ~1400 devs signing that petition, and I wondered if there was something about Ruby that made it unsuitable for FaaS. I decided to roll the sleeves and start building what would be the first PoC of faastRuby.

The core of OpenFaaS is an independent open-source project originally created by Alex Ellis in 2016. It is now being built and shaped by a growing community of contributors and end-users.

OpenFaaS is hosted by OpenFaaS Ltd (registration: 11076587), a company which also offers commercial services, homepage sponsorships, and support.

OpenFaaS® makes it easy for developers to deploy event-driven functions and microservices to Kubernetes without repetitive, boiler-plate coding.

Emscripten is an LLVM/Clang-based compiler that compiles C and C++ source code to WebAssembly

The Unity, Godot, and Unreal game engines provide an export option to HTML5, utilizing Emscripten.

Examples include Closure Compiler, CoffeeScript, Dart, Haxe, TypeScript and Emscripten.

A source-to-source translator, source-to-source compiler (S2S compiler), transcompiler, or transpiler[1] is a type of translator that takes the source code of a program written in a programming language as its input and produces an equivalent source code in the same or a different programming language.

Better yet, send them a link to this page to help them understand why and how to make an example app: