The localization project I use as an example here was definitely one of my top 3 hardest projects of all time (and that was years ago). It was not a particularly difficult technical challenge, it was difficult because it touched every single aspect of the codebase. The project took me and a coworker 3 months to build out the infrastructure for, then another 3 months of actually rewriting everything to use it, and explaining to every single other developer about why we made the decisions we made in order to teach them the different ways they were going to have to write code from now on. Social challenges of the workplace are hard; we're not always looking for technical difficulty.
Off topic but: this is some good nostalgia here. I was that other coworker. Some of the best pair programming I've ever done. It was fun working closely with Nick.
It's definitely hard. There was certainly no clear cut solution to any of the problems I included on the card in the picture. We evaluated 8 or 10 different solutions for out of the box stuff, found things we liked and didn't like about all of them and eventually decided it was best to build our own. At each step there was a lot of debate because we knew this would probably be used beyond just the Careers project and be used in the Q&A project as well (separate at the time), so it wasn't just worrying about my team's concerns, but everyone's. We won some debates, we lost some debates, it was very hard.
I've done localization conversion projects a few times so I can relate. There's never one way to translate everything (e.g. page content, URLs, database content, images, forms), there's usually several translation methods to evaluate, you have to trawl your whole codebase to tag text for translation, translating routes/URLs tends to break all code that doesn't expect those names to change, new developers have to be taught to develop new content with translations in mind, you have to schedule allowing content to be translated along with time to get it translated to get everything done on time and you need a new workflow for how translatable text is delivered, translated, reviewed and deployed.
Thanks for posting this. One thing I didn't write about is the objectiveness of interviews (felt like a different topic). Just about any question can be okay as long as it follows a few simple rules. 1) if you ask a question, you should have an expectation of what you're looking for as a result in some quantifiable way and 2) how does that result affect your decision to hire or not. The worst interviewers usually don't have an answer for #1 there and they probably decided to hire you or not very soon after you opened your mouth for the first time. This article fails to state why each of these questions is valuable and what you should be looking for as a result of asking any of them. With the addition of that, it would be a much better article.
We (at Stack Overflow) have a new documentation product coming down the pipe with an emphasis on examples and I thought it would be awesome if we could expand our stack snippets feature to languages beyond javascript. A reproducible example right there on the webpage. In researching existing solutions, nothing was satisfying, and then I had the idea to just use asm.js and write an MSIL interpreter. I spoke with some people familiar with asm.js and decided that it wasn't particularly difficult, but it had a ton of limitations from js file sizes to ways to get all of the libraries people ask about uploaded, and of course regular breaking changes in the browser. Wasm seemed like it could help with some of the issues being a formal web specification with representatives from multiple browsers.
Other than that, I can see a lot of uses for it, from small neural nets in the browser to high performance applications like photo editing, and of course gaming. It might not be for all applications, but it certainly has a spot.
Great writeup. I am a big proponent of the idea of webassembly as I believe many are. The browser is one of the greatest apps, and it is easy to look past many of its flaws because it provides a universal environment to develop for. I have always been a harsh critic of the balkanization apps provide when they are unneccessarily trying to extend functionality already provided by the browser and live natively on my device providing virtually nothing but more access to "my" resources.
That said, while I don't love writing apps in an old IBM GML and pulling in heaps of scripts to get the functionality I need, it is easy and well understood (which is why it has proliferated). If we are to change this, I think an entirely new paradigm would be easier to use and embrace than something like wasm because the browser has a lot of access to resources and this has a fairly narrow use-case relative to it's complexity.
I could be wrong, as this technology is super nascent and people as intelligent and synonomous with the web like BRendan Eich are openly supporting it, I just don't see it being embraced at the sort of tipping point neccessary to proliferate.
It will be very hard to build a community of people doing things like you have here: providing great resources and tutorials and a community of code base to build on. A new standard or tech must be 10x better than the current one and I do not feel this is.
Also you can't trivially copy/debug a web component built using web assembly(so far) and play with it which is kinda a death sentence for any tech on the web unless it's championed as being a killer tool for some usecases-which this doesn't seem to be so far
WebAssembly will eventually have access to the same APIs as JavaScript does now. Then it's just a matter of using an ES2016->wasm compiler rather than an ES2016->ES5 compiler.
That's fair. Originally asm.js was named capsule.js but that was taken and didn't really mean what it was. We could also call it modules but there is another very related spec out there for that as well. What would you call it instead?
Java hit a jackpot calling such a thing a jar, a word that is both shorthand for "Java archive" and a noun describing a container. That suggests looking at words such as 'bottle', 'box', 'cask', 'pot' (nice word, but its connotations do not make it a winner), 'cup', 'amphora', 'pithos' (not well-known enough, and typically unmovable), 'crate' (taken by rust), or 'vase' but I can't find a nice alternative interpretation as an abbreviation ('Jug' has a 'j' that could mean JavaScript, but I think we would be looking for something with a W for 'web' or I for 'internet') or even something that sounds good ('crate' is growing on me, but already taken by rust. That shows that other terms might grow to become acceptable, too. Maybe 'jug' could be such a word?)
It's interesting that the discussion in this thread centers around what to call modules, components, and packaging units. It's like saying that JVM bytecode is a way to author JARs, when it's actually the other way around: JARs are a way to package classes packaging JVM bytecode, which is a compilation target for various languages. WASM is similarly a compilation target for code; whether it's a module of code or a capsule of code or a script tag of code isn't really the point, and "source code" remains an uncountable noun (http://www.edufind.com/english-grammar/countable-and-uncount...). And that it's supposed to be browser-agnostic is cool, but surely the bigger picture is that it's source-language-agnostic.
Initially my thought was to compare it to the first compiler, back in the days when punch cards were the interface, but I decided against any history lessons that go that far back. In that analogy, the byte code is the machine, and now we all need to be writing compilers for it. This is why so many languages compile to javascript, it's the assembly of the web (not my trademark), in the browser world at least. If you want this code to run in that browser, you gotta pay the penalty of cross compilation inefficiency.
I actually think being browser agnostic is more important; it is sort of the reason we're even looking at wasm replacing asm.js in the first place. asm.js is still javascript, even though it gets handled differently under the covers. Having a second option of language supported by all major browsers is a huge deal, especially one with static typing.
As for the naming thing, a little bit of bikeshedding is healthy from time to time.
We've been calling them modules, but I'm not certain that's what we'll end up with.
Also, there's a reason the description is a bit fuzzy on the WebAssembly landing page. It's not just a binary format (in fact, we didn't have a binary format for a while after we started). I like to think that it's a specification of execution semantics that can be expressed in many different formats (text, binary, AST, etc.). Not sure that's the easiest way to explain it though.
I had the exact same problem when I first started. Someone once told me "what we can throw away to solve this problem", so I kept removing parts until I got here which I think is currently the easiest way to get started.
Ultimately you should be able to use your C compiler and generate wasm files directly, rather than go through asm.js.
There is an experimental backend of LLVM that you can try, but it will require building LLVM from source currently. Emscripten has an option to do this automatically, I believe.
You can also write the AST format by hand, which IMO is much easier to do than writing asm.js by hand, just more verbose. I wouldn't advise anyone do this, as the format has been changing over time.
Finally, there is work on specifying a true "text format" that is meant to be used with view-source and directly maps to the binary format. You can see some proposals if you look at the pull requests in the design repo. When a proposal is accepted and we implement the tooling, you will be able to generate a binary directly from this format, which will be much nicer.
I'm familiar with the LLVM direct to wasm tool, but I was unable to get it working using the steps from the emscripten docs. The binaryen toolchain is pretty easy to digest, but I've been using the emsdk almost exclusively for the convenience. Once you have to rework part of it from source, I just don't know enough about it to debug it yet.
Thanks for the info on where to find outstanding proposals.
The last 10 minutes where you ask questions is a bad time to waste asking someone to judge your 3 year plan when they just met you. Most of these questions are better asked when you fail an interview and request feedback as to why.
I specifically state when I perform interviews that I will not answer the question "How well would you say I did in this interview?" The interview isn't over yet, and that's impossible to answer.
You should really spend this time to see how much you would want to work at the company. Ask about their processes, the things that would absolutely turn you off to a company or the things that would absolutely turn you on to a company and make you forget about all their other bullshit. Ask about the problems they are trying to solve. Ask about how smart the other people are who you'll be working with.
Don't waste time in the interview checking if you passed. You'll know very soon anyway and there is always the chance to get this feedback afterward.
> Don't waste time in the interview checking if you passed. You'll know very soon anyway and there is always the chance to get this feedback afterward.
I think that would be a mistake. If the interviewer isn't able to answer those questions satisfactorily, it might be a sign that the hiree isn't a good fit. Nobody wants to change jobs to something that doesn't work out.
Let me start by saying I am the most vocal person about semantic HTML at my company, but it really depends on your purpose, and I'm not sure you are realizing you are taking a hard line. Also, I would have preferred you used the 90% of your words to give better examples of how to do things better than overstating how OOCSS and BEM are wrong. Well developed solutions are always better than just explaining what's wrong unless there is no solution and the existing proposals are wholly unsatisfactory.
Take a step back and realize that there is at least one more way of doing this. Why not have the presentation be the specification, and we can just build the html to conform to the that specification instead (via the use of helpers and all other commonly accepted forms of duplication reduction). Your post basically declares this Doing It Wrong™, but I imagine that's just because you'd rather see better looking html than you would see better looking css.
You have the semantic issues well thought out, however you are flat out declaring data semantics are more important than presentation semantics. For most projects, the HTML is only used in a browser, and isn't the source of truth for the application, i.e. it is inherently coupled with the presentation. They might as well be one and the same because this is it's only purpose in the world. Leading from that, the only issue is maintainability, and here is where your ideas aren't fully developed.
As will all separation of concerns, your solution (the one about breaking news) also adds a layer of misdirection. Sure I don't have to change the html to change the presentation, but now I have figure out where that part of the presentation is modified. My CTO and designer (2 people I have a lot of respect for) were the people who eventually changed my mind on this. They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds. It took probably 3 or 4 weeks for me to relent on this before I accepted, but it is much easier for everyone (think of the new hires as you pointed out!) if they don't have to know tons of info about the domain, but just look for the offending element and make a simple change in place rather than have to unravel the css toolkit to find where my button was made blue instead of green. Additionally, they know this change is only affecting this one element they were told to change. On our team, that is better maintainability because that is how real changes are specified. In your case, by the time this spec makes it's way to the developer, it needs to have traveled through people who know that part of the web page is a breaking news container and translated from whatever the original complaint was or the developer will likely have another problem to figure out before he can even begin changing what will likely end up being a single css rule.
Loose coupling is simply about defining avenues of change, and it only improves maintainability when it enables making changes easier. This has been extrapolated to mean "does this have to change or not", which is over thinking it a bit. In my example, I made a typical update by changing exactly one thing in exactly one place, without having to traverse any levels of misdirection. Just figuring out how to make one thing not have to change doesn't make it more maintainable.
When we're talking about web pages, it's also important to realize that we're typically not changing just the presentation of static data; we're adding and removing features to figure out what makes this page more useful. The HTML is typically going to change anyway when we're modifying the page, which again leans in favor of a common set of CSS selectors to build against (in terms of avenues of change).
As I said, I'm probably the most outspoken person at my office when it comes to semantic HTML, but it's only when I'm describing actual data, i.e. the parts you read. These parts tend to change very little and can be generated and stored in their already rendered state. The parts that do change more often gain a lot from the benefits of OOCSS and BEM techniques.
> I would have preferred you used the 90% of your words to give better examples of how to do things better than overstating how OOCSS and BEM are wrong
This is definitely something I'd like to do as well, but I wanted to focus on the areas I found problematic first and foremost. I may post a follow-up based on the feedback I've received.
> Why not have the presentation be the specification, and we can just build the html to conform to the that specification instead
As I said, I don't believe this is an appropriate approach for a medium which has no absolute, definitive interpretation. A website isn't how it looks, because how it looks will differ depending on how you access it. The only absolute truth when talking about websites is the semantic purpose of the markup underlying it, because purpose is universal: a navigation element is a navigation element regardless of whether it's being displayed on a TV, a desktop browser, a smartphone, or being read out by a screen reader.
> I imagine that's just because you'd rather see better looking html than you would see better looking css.
I'm actually interested in both :)
> You have the semantic issues well thought out, however you are flat out declaring data semantics are more important than presentation semantics.
What are ‘presentation semantics’? I think this is a corruption of the concept of semantics. Semantics are what a thing is, or means, or does; not how it is presented
> My CTO and designer (2 people I have a lot of respect for) were the people who eventually changed my mind on this. They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds.
Changing how you structure the CSS in your application based on the whims of people whose area of expertise isn't CSS sounds like a nightmare scenario to me. If you're bootstrapping with a small team I can understand wanting to have everyone being able to contribute, but you should also be able to recognise what the limitations of their skills are. In the example you give, I would be using my web developer tools / inspector etc. to find out the origin of the erroneous property. If you're using a preprocessor there are source maps that can help with identifying how a rule was built. I certainly wouldn't conclude it's easier to use a presentational class name just so that my CTO could understand the code.
> What are ‘presentation semantics’? I think this is a corruption of the concept of semantics. Semantics are what a thing is, or means, or does; not how it is presented
Semantics just means to give something meaning. Presentation semantics (http://en.wikipedia.org/wiki/Presentation_semantics) are just marking up the data to declare your intent for how you would like it to be presented.
> As I said, I don't believe this is an appropriate approach for a medium which has no absolute, definitive interpretation. A website isn't how it looks, because how it looks will differ depending on how you access it. The only absolute truth when talking about websites is the semantic purpose of the markup underlying it, because purpose is universal: a navigation element is a navigation element regardless of whether it's being displayed on a TV, a desktop browser, a smartphone, or being read out by a screen reader.
A HTML document is just text. Technically adding links, particularly navigation, is just presentation markup. As you said, it's up to the interpreter to make sense of that markup. The basis of your argument is that presentational markup is bad though, so I'm left unconvinced here.
> Changing how you structure the CSS in your application based on the whims of people whose area of expertise isn't CSS sounds like a nightmare scenario to me. If you're bootstrapping with a small team I can understand wanting to have everyone being able to contribute, but you should also be able to recognise what the limitations of their skills are. In the example you give, I would be using my web developer tools / inspector etc. to find out the origin of the erroneous property. If you're using a preprocessor there are source maps that can help with identifying how a rule was built. I certainly wouldn't conclude it's easier to use a presentational class name just so that my CTO could understand the code.
I'm concluding that presentational class names are easier to fix for the regular small changes that come down the pipe in our project. Even if you're regularly making big presentational changes to your entire site, then you'd need something a little more abstract, like using a class to declare an element as a button instead of the direct color it should be, but like I'm said, the argument against presentation markup is still unconvincing in the face of simple maintenance.
"A HTML document is just text. Technically adding links, particularly navigation, is just presentation markup."
HTML is HyperText markup language. Hypertext is about links and references to other documents. Links are a first class citizen of a hypertext document. That's about function, not presentation.
I'm starting to see a pattern here about "presentational CSS class names": considering the superficial presentation layer and not the underlying meaning that links consistent design elements. There's a language to design, and it's a hell of a lot more than "this button should be green".
"They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds."
There's a whole series of unasked questions going on there:
* Why is the button blue - what led to that conclusion?
* Why is green the right colour?
* What about the other buttons, are they all the right colour? If so, why. If not, why?
* Why does the style guide for the site not specify this properly? (You have a style guide, right? Your CTO and designer did present you with an up-to-date, style guide, right?)
Asking these questions leads you to the semantic understanding of why buttons are supposed to exhibit specific characteristics. It's the WHY that's important, not the WHAT.
CSS excels when there's a requirement for consistency in design, and there's a style guide. When your requirements are a superficial "this button must be green" and you don't stop to ask why, then you've already sacrificed the semantic aspects of the documents you are supposed to be vocal about.
Also, how difficult is it to find what stylerule is causing the button to be blue. Right click on the button, click "Inspect this element in Firebug", in the CSS Inspector find the CSS rule that specifies the colour as blue. Look at the CSS selector itself - does it describe the semantic reason why the presentation is coloured blue? With that understanding of the semantic basis of the button being blue, you have an answer WHY the button is blue.
So now you need to understand why the button is supposed to be green. Get that explained to you, and now you have a good idea of the semantics you need to express, or reuse, a CSS rule that will cause the button to be rendered in Green.
This is where semantic class names win hands down, it tells you the WHY of styles. Without the WHY you don't have a basis for explaining why the button is blue, and no clear inkling of why now it should be green. And absolutely no idea which other buttons on the site are the wrong colour.
And that's about as far away as you can be from a consistent style guide, and presentational accuracy. If everything is ad-hoc, then nothing is consistent.
Sure there are a few questions with highly voted up answers because they are widely useful, but there is certainly the minority of high rep earners. Even the new people who are gaining lots of rep are doing it by answering hundreds of questions.
Were they actively making changes to the project and running custom builds? If not then they just had nothing to contribute to the project and there is certainly nothing to feel disgusted about.
Even if they were making local changes, I personally couldn't fault them, really; they're playing by the rules.
If they want to give up the intangible benefits they would get from sharing those changes (at least the non-business-strategic ones), that's disheartening, but I wouldn't lose any sleep over it.
