One of the most truly fascinating things I learned from my father was how early 1980s word processors were designed for the magazine he worked for. The different ways to handle fonts, screen placement, and how to include data from a local database.
It was truly an awakening to the hidden wonders of the world.
I'm surprised she didn't mention Marijn in the "thank yous" at the end - without him giving away his time building ProseMirror they would have nothing to build upon.
I've invested in Mobiledoc (mostly because it was for two ember apps) and it's mostly been fine, but is there any reason why I shouldn't be moving to ProseMirror? Seems to be a lot more powerful and have things like collaborative editing and track changes as well.
ProseMirror requires a certain willingness to work with strict data flow and immutable data structures, and to cobble together a loose set of small modules before you have something user-friendly, but if you can handle that I think it's a safe bet at this point. (Disclaimer: I wrote it, and am heavily biased.)
Just my experience: I had a rough time with ProseMirror trying to use it before it was released. It didn't use modern JS modules for a long time, the source code was a mess as far as I could tell, and JavaScript variable errors would surface with every version.
Maybe the author has overcome these issues, but I'd be inclined to go with a different editor. Also, ProseMirror's architecture is extremely close to DraftJS, which I've had much fewer issues with.
We used ProseMirror in the past few months to build a rich text collaborative editor. We were able to get started and get a collaborative editor up and running in ~1 hour. This was a big deal for us, we'd tried to implement a good collab editing experience multiple times and each time we felt like the editor was the sticking point in creating a good experience. ProseMirror treats collab editing as a first class use case and makes it really easy.
We then spent 2-3 weeks getting all of the formatting, tooltips and key mappings to handle some basic formatting (bold, italics, underline, bullet lists, numbers). Eventually, once there are more examples on the web of more complex formatting for the community I think it will become much easier to use.
It's the first editor I've used that felt like it made sense at a conceptual level but implementing "simple features" can feel very hard at times. I don't think that's a knock on the library though. There's a lot to learn and understand and it just took us a lot of time to get it all.
This was my experience as well, quick to pick up but harder to master with more complex specs and commands even if seemingly simple. Understanding the concepts and the design patterns used in the examples goes a long way, it is a powerful framework.
Yeah thanks for dropping some deeply outdated impressions in here. (Also not even fair—the code was never a mess and at the time it wasn't clear how ES modules would be used so using CommonJS was a completely reasonable choice.)
Just wanted to offer some feedback. Prosemirror's docs are woefully incomplete. The way controls are added is extremely confusing. Why do we need some node module called "prose-mirror-example-setup" ?
I know I'd personally prefer being able to add all the markup and style for the editor, and then just use prosemirror underneath the hood for state management.
Another thing that I found quite difficult, was programmatically inserting images at the cursor.
Finally, storing state as markdown has turned out to be a nightmare. Not really your fault, but perhaps something you should be aware of.
I agree the docs are obtuse, and implementing features is hard, but document state is not saved as markdown. The whole point of PM is to separate content from prsentation.
Impressions matter, no matter how outdated they are.
I also don't think the concept of fairness applies since I'm accounting the details of my personal experience and the conclusions I personally drew from it. Some of those are subjective (code quality) while others are purely objective (I got a lot of errors). What I infer from that may be entirely different from what you do, but that does not make your characterization of things more fair than mine.
Does a review of Windows 3.1 give you any idea at all of how applicable Windows 10 would be to solving a given problem? At best, you’ve stated a bunch of nonsense for people to filter out once they eventually realise you’re talking about a version which bears little similarity to the current state of things.
Cool, but it's yet another case of re-engineering the same thing. (edit: its not entirely new).
Splitting editors into an abstracted structure for finer control over data and presentation is something that's been done for a decade now in various text editors. Medium and Basecamp started similar projects and there's Mobiledoc which is trying to standardize the format. It'd be nice if all this effort focused on a single project so we could all just get a decent editor instead of different versions with various states of functionality.
This is talking about using ProseMirror to build some more features into their CMS, but it sounds like more of just a use of ProseMirror rather than a new editor entirely.
Collaboration isn't a requirement for me. I would definitely go with quill instead if it were. They put a lot of thought into making the delta format natural for operational transforms: https://quilljs.com/docs/delta/
Your document state is always represented by a list of deltas. Two people trying to change the same document would just have their individual list of ops "rebased" together using OT before being concatenated into the existing list of ops, forming a new document that is still just a list of ops.
Quill has a great API, it seems like they really thought things through and designed it (what's a good word for the opposite of ad-hoc?). Even the lower-level bits are available with a clean API if you should ever need them (e.g. it's super simple to use the underlying OT and diff/merge functions on whatever text you want)
Going with your own format has some advantages, but using a well known popular format also has advantages. I did look into ProseMirrors and other editors but due to the formatting I ended up making my own. Where I've gone the painful route of having HTML nodes instead of a JSON tree. My reasoning is that I always want to end up with HTML anyway, and this also allows switching back and forth between editing HTML and WYSIWYG-mode. And use existing source control (Git/Mercurial) for versioning. The biggest pain is that browsers like to mess with the white space, and different browsers want to format the HTML in their own way. The next step would be to implement my own html/CSS renderer/wysiwyg-editor using the canvas. When researching I found some proprietary tools that did that. I wish the contentEditable would get more love from the browser vendors, because that's what most web editors use.
If you're looking for a traditional editor then Froala is worth every penny. It has 10x the features of all these more modern versions and still outputs solid HTML.
> Splitting editors into an abstracted structure for finer control over data and presentation is something that's been done for a decade now in various text editors.
Sounds like Latex which has been around much longer.
Can we leave the Slashdot-quality trolling about licensing back in the previous millennium where it belongs?
There are, of course, successful projects licensed under the GPL and AGPL (Linux comes to mind), many of which have for-profit businesses; there are plenty of people with different priorities about what "REAL freedom" is. And calling the licenses that match their priorities "herpes licenses" is unlikely to convince them.
Trolling aside, the freedom allowed to not show all of your cards that MIT/MSD/Apache allows is better for business, and if the app is essential to their business then they will contribute fixes back upstream. An example is Juniper and their myriad contributions to FreeBSD. This allows Juniper to pull down upstream updates without it being a complete goat-rope to integrate with their own secret sauce code; if Juniper were using Linux instead of FreeBSD then anyone could demand full source code and sell knock-off solutions based on Juniper's work and the result would be less actual development of the technology (for lack of profit motive).
That shows that it is better for some businesses, which no one disputes. For other businesses, the compulsion for others to share their work results in a better product, and tbeir profit motives are more aligned with a better product in an absolute sense than being better than competitors, and so being compelled to release source is a worthwhile tradeoff for everyone else doing so too.
I'm choosing an editor for my project right now. Can someone compare ProseMirror to Slate and Quill? What is the difference, which one is better? What do I need to know to choose one?
I've used a lot of quill in the past couple of years. It has some tricky bits, but seems similar in a lot of ways to ProseMirror - separate internal representation of data that gets rendered into HTML, delta-based state changes, etc. At this point, I use quill out of momentum - it was the only game in town when I started working with rich text, and now I know how it works. I also like it enough that I've never felt the need to go find something else; it's always done what I want.
I think to fully experience all three of those editors, you should build the following: something that generates a rich text input using the editor, updates a data store (can be just in-memory if you want), and then re-presents the rich text in a read-only format.
With Quill in particular, there's two ways to approach the second part - you could dump the data into another instance of the quill editor, but one flagged as read-only, and let quill handle rendering out all the elements. I don't do that, myself, as it's a bit heavy and relies on the DOM to be present to create the end result (meaning rendering rich text into emails on the server side can be tricky). Instead I use a library (that I wrote) that converts the quill representation into an HTML string that can be later injected into whatever place it needs to go.
In general, I think that's where the one of the important pain points is for any major modern text editor exist - converting the internal data representation into a canonicalized HTML string. This gets further complicated by your framework - it's easy enough to inject an HTML string, and angular 1 lets you even compile that so you can have custom elements there, but angular 2 has no such facility (compiling; you can still inject). So rendering custom elements into angular 2 is feasible but quite tricky.
You'll need to figure out how to handle custom elements too, like at-mentions and so on; those are really domain-specific. How I handle at-mentions in quill (with a pop-up autocomplete) depends on the structure of the overall system as well as the framework I'm in - angular 1, 2 and react all suggest different approaches for this.
Anyway, this is all a long response that means "it depends". Each editor has its own strengths and weaknesses that are exposed by the specific data and presentation needs of your project and the other frameworks in play. But building an atmention or other custom element and converting from the internal data structure to HTML is a good test of functions for all of those.
Prosemirror and Slate both great projects but lack of community interest. They are basically framework for creating WYSIWYG, until they release full featured editor built on it, i dont think it will become popular.
Personally tried both, working with Slate feels much smoother, plugin system easier than prosemirror in my opinion.
And, there is ckeditor5-beta. You might wanna check out.
If you just need a WYSIWYG editor on a web page, and it's a single one, I've used tinyMCE.
On projects where I've had to load up multiple instances, I've had to move away form it as it kept reloading stylesheets and js files for each editor on the page.
Now I usually use quilljs, which works really well for some basic markup.
I've been watching this product for a while: https://www.nuclino.com/ it seems they too have built something really impressive on top of ProseMirror (it's a lot like Quip/Paper but more interesting). ProseMirror really feels like the only editor on top of which you can build an entire user experience and app.
So, we had this product (or the larger one anyway) demoed for my work and our takeaway was that only really large organisations could possibly use it. It needs to many human hands between writing an article and getting it published. We want to move to something more automated, and this system would have been a serious setback.
This isn't even a test editor. It's closer to a web publishing tool. The article also didn't talk about the normal text editor challenges like the way the text is stored in memory and modified.
I carry the personal view that when someone says "text editor" they are implicitly implying plain text. As such the leading paragraph of the article makes me twinge a little when "text editor" is used rather than "word processor".
The article then continues on to describe the editor which sounds very much like a WYSIWYG editor. Indeed ProseMirror[1] homepage says the following.
ProseMirror tries to bridge the gap between Markdown text editing and
classical WYSIWYG editors.
It does this by implementing a WYSIWYG-style editing interface for
documents more constrained and structured than plain HTML
So whilst I've made a point of it reading oddly (and I would have thought this would also be the view of most others on HN) I am not trying to disparage the authors use of the term "text editor". But rather I am curious as to why such nomenclature happened to be used here as I seldom see it outside of descriptions of things such as Vim and Emacs.
That seems a bit too pedantic of an argument for this article. The very first paragraph implicitly states its definition of text editor:
If you’re like most people in America, you use a text editor nearly every day. Whether it’s your basic Apple Notes, or something more advanced like Google Docs, Microsoft Word or Medium, our text editors allow us to record and render our important thoughts and information, enabling us to tell stories in the most engaging ways.
Also, it could be argued that all word processors are also text editors but with added features. The fact that they allow the presentation to be edited does not mean that they stop allowing text to be edited.
Not sure why you're getting downvoted. This appears to be an evolution of WYSIWYG tools to me, which I wouldn't categorize as a text editor either — more like a word processor.
FWIW ProseMirror does not bill itself as a text editor:
> An ideal content editor ... bridg[ing] the gap between Markdown text editing and classical WYSIWYG editors.
> It does this by implementing a WYSIWYG-style editing interface for documents more constrained and structured than plain HTML...
I just downvoted you, and I don't write for the Times. Unfortunately...
The reason this specific thread is being downvoted is that it started with nitpicking over useless semantics, and then actually managed to get worse by complaining about downvotes. Then, it got worse yet again by offering a conspiracy theory for those downvotes, instead of assuming the obvious: nobody cares.
And then it got even worse with some guy who couldn't leave well enough alone and felt compelled to point out nitpicking by nitpicking and then making a wrong assumption! Quick! Somebody on the internet is wrong!
And true to form, I'm going to be 'that guy' who says: I care. I too felt weird about the author using the term 'text editor', I too needed a sense of nitpicking comradery that I found with others pulling apart the semantics.
It's not that off-topic and we're safely in our own little thread here, so instead of being a jerk and downvoting, just collapse the thread.
You sure this is only for web? I got the impression that a story authored with Oak could just as easily be vectored to the web, newsprint, or magazine. Clearly video and audio content don't apply to the latter two but I can see where Oak-authored content is sucked into the print layout app(s) and more metadata (fonts? formatting?) applied that are only relevant for the dead-tree versions.
Agreed. It feels odd to read an article from a developer who doesn't know the terminology. Vim is a text editor because it edits strictly text content and not other media or presentation. Oak is a 'desktop' publishing app if not a CMS; it's purpose is to handle multimedia and presentation, as well as document review.
(At least that's how I understand text editors; maybe I'm the ignorant one.)
Why are they gifs instead of mp4s? Yikes. Also, since they are screenshots without a lot of movement, they really should compress better than that even as gifs.
>While it may seem strange for us, a publisher, to post on Medium rather than our own platform, we are here for a simple reason: the community. Medium is where so many of our people are, so much of the product, design and development community, so we wanted to be here too.
Organizations use Medium instead of their own platforms to try to create a sort of social signalling--like, "this is not the usual old-school BS you'd expect from us--this is cool design or tech content."
I've had this vague sense all year that someone gave it a term and wrote a post on it and I read it, but it never reached the level of consciousness where I'd actually look it up. Thanks for pointing the way.
> Maybe because they're using Medium, and Medium doesn't have that option.
> Why the biggest newspaper in America can't run their own hosted blog is a bigger question.
Kind of ironic given that the post is about building their custom web-based text editor... I wonder if they use it to draft their posts for Medium too.
I'm sure they could run a hosted blog, it's probably a deliberate decision by their tech team to seem cool and hip by posting on Medium, because that's the in thing right now for developer blogs.
(Note: I'm not dissing them, I know a very talented developer who works there and says he has a great team)
> because that's the in thing right now for developer blogs.
Which is bizarre. The comments section of tech blogs are a great place to discuss and ask questions, and the support for comments on Medium is abismal, looks like they deliberately made it suck.
Maybe it was a decision to not have to run and maintain unnecessary shit when they have enough to deal with with their primary products when third parties have already invented that wheel.
What I find amazing is that it's that large despite only being two bits of color depth, and it's extremely short and low framerate. Where the hell did all that filesize come from?
Looks like they cut the size down some. I am seeing 10.7 MB for the GIF.
There are several reasons for why the GIF is so large that all contribute to the size. The GIF's resolution is quite large for a GIF, at 1004px by 788px, this is larger then they display it on the page. And the GIF is pretty long at 336 frames.
Since GIFs on like just about every video format except MJPEG has no interframe compression. So each frame only has to average 32 KB to make up that 10 MB (336 * 32.6KB = 10.7 MB).
This is an example of how extremely good our modern video codecs are.
There's something wrong with your iPad or safari itself. My 2 year old phone has no problems keeping up. It is incredibly stupid to have a 69 MB gif though.
If you're looking for a backend role, we're also hiring in New York Times Data Engineering--application engineers, data engineers, and database reliability engineers:
I'm an engineer on our CMS team and as Albert mentioned we're currently seeking both back-end and front-end team members. We're not opposed to hiring skilled developers that don't have deep experience the specific language or frameworks we use. There's also always the option of joining the back-end and transitioning over time to a more front-end role. If you're interested, I'm happy to answer any questions or connect you to the hiring manager.
We do have news employees in bureaus around the world but I'm not sure what the the exact policy is for tech employees. I'll see if I can find someone with the answer for you
As someone who has worked on the integration of off the shelf CMS and as well as built in house ones, I question this statement.
There’s a lot of value in building tools that fit the domain and workflow perfectly well. It’s expensive in the short term but in the long term saves a lot of time and money.
It takes a 'team' to provide any sort of professional level of support for an organization of their size. If the one-person "CMS/tech wizard" decides to stop working, or die, or get sick, or take an extra 4 hours to be with their family, the entirety of the NYT operations should just say "oh well, we'll just wait around for a while until we find our next one person to be our tech saviour"?
A word of unsolicited advice: Someone who thinks "I am a Python developer" is generally less useful to a team than someone who thinks "I am a developer who is good at Python."
Not all languages are created equal. While yes a developer with years of experience in python may have lots of transferable skills to other languages, my team arent going to hire someone for a mid level/senior position without a good knowledge of c++
C++ is somewhat of an outlier due to the sheer size of the spec(and getting bigger all the time). Not everyone will use the same subset of features either, which complicates things.
That said, aren't you using C++ as a proxy for other needed skills though? Many Python programmers are not exposed to concepts like vtables, or they do not know how a linker works(or why it is even needed). Heck, many won't have done manual memory allocation or manipulated pointers.
Even though most people won’t use everything, all c++ programmers will need to understand RAII, manual memory management, lifetimes, effects of inheritance and some* undefined behaviour. We’d probably take people with C experience, and maybe Some D or Rust, but really for a mid level C++ job we wouldn’t accept much less than C.
Funny that you mention linkers, as they’re a bit of a minefield. Lots of the behaviour of linkers is platform (and implementation) dependent, I.e. are you building a shared library or an exe on windows or linux, and there are different gotchas for all of them. We wouldn’t expect people to know al of those things, but it definitely helps when it comes up, and you don’t have the same problem (ODR violations come to mibd) in many other languages...
I like your way of putting it, but I think those concepts (RAII etc) are fairly easily learned by a competent developer in any language. Most languages have analogous concepts if you use them long enough.
A shop that says it requires years of experience in a particular language is probably making their own hiring situation more difficult than they need to.
C++ for example is definitely a sharp language that takes some time to adjust to, and experience in C will help.
However: I think any competent programmer with a few years of experience would be able to gain basic proficiency in a month or two and probably daily-level-mastery in 6-12 months.
I say this as someone who had 10+ years in Java and only passive experience in C. I've managed to become mostly proficient in C++14 in about a month of full-time learning. After 10+ years of programming, I can pretty quickly adapt to the C++ way of thinking about things. I don't think I'm alone in this style of learning a language, and many hiring teams seem to agree.
No language is inherently "better" than another. They are each useful for specific cases, and understanding more languages means understanding their contextual strengths and weaknesses.
In most hiring settings this isn't true though. Language-specific skills actually do matter, for all but entry-level positions at massive tech companies. It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever. Could I get up to speed in those languages in due time? Sure. But if you were on a hiring committee, hiring for a team that works mostly with Java (or whatever) would you rather hire me or the version of me that's had the same amount of experience but with Java?
> It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever.
It should be.
Picking up language X is very easy for most values of X (more esoteric ones excluded). After you know a few (and the more diverse the set, the less new concepts you'll see), picking up a new one is quick. If it is something like Go, it's a weekend's worth.
Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time. If you are a solo developer, or if the entire team is ramping up at the same time, then it is bad.
But a new, experienced team member, with zero knowledge in the most used language in the team? Sure, why not? They may even bring new skills to an otherwise homogeneous group.
I always let the interviewee pick the language during my interviews. Usually it is something like Javascript or Python. Sometimes it is Bash. I keep waiting for the day someone will offer to do it in Scheme, Haskell, Elixir, Prolog, D, Rust, even Ada. Pseudocode is actually fine too, unless I have a reason to think the individual lacks programming experience.
Whatever you do, DO NOT brand yourself as a X developer, if X is a programming language. I can understand specializations like machine learning. But languages? It's a mere tool, and you need more than one in your toolbox.
> But a new, experienced team member, with zero knowledge in the most used language in the team? Sure, why not?
It really depends on how much time you have to wait for a new hire to ramp up before they are useful. If you need immediate help, then hiring someone who doesn't even have experience with your programming language is a complete non-starter. If, on the other hand, you are hiring for the long term and can afford to pay a ~3-month tax for a good engineer for (hopefully) several years, then you are correct and the ramp-up cost becomes pretty insignificant. But don't make the mistake of thinking that this is an exception to the rule—what languages you know absolutely does matter to any company needing to get work done now.
> Picking up language X is very easy for most values of X
I disagree. If you know Y and you're learning X, it depends much more on the value of Y. If Y is Lisp you will be quite successful at learning any X. If Y is something like C or assembly language, then you will not (it's always easy to spot the C guy who just started using Python etc.)
In my experience it is like learning a spoken language. If you know a language in the same family then learning the new language is relatively easier (e.g, Java -> Scala, Lisp -> F#). I also think the ease of learning a language is proportional to the ratio of expressiveness of the language you are coming from to the expressiveness of the language you are going to (e.g., Lisp to F# might have a much easier time than F# to Lisp).
>Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time.
Yeah. As in years. This stuff also changes all the time so requires perpetual learning.
>But languages? It's a mere tool, and you need more than one in your toolbox.
It's not a mere tool and languages are more than just trivially learned syntax. They are the umbrella under which a panoply of tools, approaches, ideas, priorities and culture aggregate.
Sure, you specialization isn't necessarily always the optimal approach and sure there are benefits to the cross fertilization of ideas across community lines. However, being a jack of all programming languages, master of none probably means you'll suck more than a specialist at a lot of stuff.
Moreover, some ecosystems plain suck and avoidance is the sign of a good programmer. Statistically, you're probably a worse programmer if you've used a lot of PHP and better if you've learned rust/F#.
Language-specific skills actually do matter, for all but entry-level positions at massive tech companies.
Absolutely, which is why I didn't stop at "I am a developer". That "who is good at Python" bit is definitely important.
However, seeing yourself as a "Python developer" rather than "a developer who is good at Python" makes it look like you see every problem as something you'll solve using Python. That's bad. That will put a lot of companies off hiring you (companies that believe in a 'best tool for the job' approach anyway, and those are the ones you probably want to work for).
>However, seeing yourself as a "Python developer" rather than "a developer who is good at Python" makes it look like you see every problem as something you'll solve using Python. That's bad.
If a company didn't hire me because they idiotically interpreted "I am a python developer" to mean "I would try to build a rendering engine in python" then I'd say that's probably a bullet dodged.
I'd interpret it as "I don't build rendering engines but I build other stuff for which python is a good fit", but maybe that's just me being weird.
The trope about great programmers being people who reverse binary trees in their sleep and being able to swap ecosystems at the drop of a hat needs to die. Great programmers specialise.
Being able to interpret around your words does not make your words inherently better.
You aren't honestly trying to sift out clueless prospective employers out by their ability to parse a title, are you?
The advice here is to put focus on ability to write software, and experience using python as a tool to do so, rather than implying that your ability is limited to python.
What parent was trying to explain is that an individual is not defined by a specific subset of his/her experience.
Just as fluency in Spanish does not make me Hispanic, experience in python does not make me a "python developer". That title puts focus in the wrong place.
It depends on whether you're taking the perspective "if someone offered me this job, would I take it?" or "if I applied to this job, would they hire me?".
An excellent profiler for perl, NYTProf [0], came out of New York Times. It's still actively developed and still kicks ass - outputs easy to grok flame graphs that you can click around on to zero into any statement. More than just finding bottlenecks, I find it useful to understand workings of new codebases...
A desire to stay relevant. Print publishers often get criticized for being behind the curve, but a few like NYT and BBC have invested heavily in the technology of their business. Not sure how much it's paid off, but my impression is they aren't struggling as much as some.
I hope they manage to find the right combination to stay around, I loathe the dystopian future where Buzzfeed and Breitbart are the only news outlets.
The NYT fortunately seems to be transitioning moderately well to digital at this point. They seem to have the wind at their back now. There was a period of time, spanning a decade or so, where it was very questionable if they'd make it or could survive on digital.
Their stock is at an 11 year high. Sales are growing again. Profitability looks set to surpass where they were several years ago. If it weren't for some stray costs & adjustments in Q4, they might have hit $100m+ in profit in 2017, the highest since 2010. Their balance sheet is solid, long-term debt is modest ($250m), and they have plenty of cash ($490m). Overall, it should be a good decade coming up for the NYT.
Their news coverage is pretty strongly slanted to the left. Just because I tend to agree with them doesn't mean I think they are really that much better than Breitbart in terms of providing objective reporting.
In any event, what I meant was that I don't want a future where we only have sources of "news" that serve to reinforce our pre-existing beliefs, with everybody siloed into their own particular little bubbles.
It's a good melting pot for people who are passionate about writing, design, and ideas.
Kind of like how all of the best programmers have some kind of log or blog that they post in. While this could very well be some form of survivor bias, I think that just having to put effort into articulating your thoughts in a coherent way now and then improves other parts of your thinking.
I'd say it's desperation. The traditional business model of newspapers has been upended, and the ad driven model isn't really working out that well either. So instead of doubling down and riding it to the ground, some outlets are actually innovating and making cool stuff and throwing it against the wall to see what happens.
The BBC is state funded, through the TV Licence, for use within the United Kingdom, elsewhere it is funded on a commercial basis. The web site differs between domestic (no adverts) and international (adverts).
BBC Studios is the commercial arm of the BBC for licencing and distributing media outside of the United Kingdom.
The author does not say "work in a text editor", only "use". Considering she's including text editors on mobile devices, which the majority of America will utilize today, that's not a particularly bold statement.
> Where everywhere is some subset of browsers in the wild and often not that consistently anywhere.
Yes, but it's easier to download a version of the browser that works. The alternative is for the developer to build native apps for each OS they want to support. In my experience, it's easier to build cross-browser than it is to build cross-platform.
Because professional writers are not professional coders. Markdown covers the basic text markups but does not define how to format all these embedded media a modern newspaper has. Just to give an example: Inspect the syntax of wikipedia, which is the MediaWiki wikitext (https://www.mediawiki.org/wiki/Wikitext) language. It is simple and therefore Wikipedia pages are rather simple. I expect the NYtimes to have higher aims in markup.
I myself am surprised they don't just use markdown. Git is another story.
> writers are not professional coders.
But I have heard of writers clinging to old versions of WordPerfect, which were not WYSIWYG. They preferred the keyboard shortcuts to clicking around with the mouse.
Furthermore if you're just writing the text of the article, you don't even need markdown, just a textarea. They used to do these on typewriters after all. Newspaper articles traditionally lacked anything but plain text. No bold, italics, or subheadings.
> Markdown covers the basic text markups
> but does not define how to format all these embedded media
> a modern newspaper has
Traditionally the jobs were separate --- and I assume they still are. There are the reporters, who research and write the text of the article. Then there is the layout team who lay it out, decorate it, etc. I can see how markdown would be no good for them. They would want a graphical user interface.
> Traditionally the jobs were separate --- and I assume they still are.
Is this really a good assumption? Journalists are making complex documents with central interactive features and lots of data visualization. It seems a lot like classic waterfall thinking to assume that reporters could perfectly envision that and toss it over the wall for a separate team.
2. Most reporters were journalism majors, which teaches research, interviewing, and writing. Graphic design is a separate discipline. It is possible for one person to be good at both, but rare.
3. Companies tend to cut up work, especially big companies, like the New York Times.
4. Complex articles like this one, https://www.washingtonpost.com/graphics/2018/entertainment/v..., aren't tossed over the wall. But that doesn't mean that one person did it all either. I'm sure there was back and forth between the writer and designers, and likely an editor oversaw it all.
git isn't great for quickly writing and editing text. In response to breaking news, it isn't unusual to have two people making changes to the same paragraph at the same time. That's a recipe for messy merge conflict in git.
On the graphics desk we know how to use git— we use it for js/css—but still write words in google docs.
Whew, what a gross way to over-engineer a text editor. If the NYTimes structured themselves like a dev team, they could use common sense tools to get much better results.
Why is the journalist responsible for how it's presented? Wouldn't it make more sense to have some kind of product manager or designer handle this? And why is the journalist responsible for programming the look and feel of the their article? Why not have a front end dev do that?
The journalist doesn't only write an article, he also structures and plans how the story is going to be presented because that's also part of the job. Hiring another person in-between the article and the journalist is like hiring an extra person to only hammer a nail when there is a construction worker to do that job already.
They develop the underlying technology to let journalists do what they want without needing to hire more employees.
In industries that still make money--even ones with better software-chops than the New York Times--writing/researching an article, and presenting it, are still separate jobs--and for good reason! They require orthogonal skillsets and a decent amount of time and hands-on experience if you want a professional result.
I don't think the distinction is as artificial as all that. It wasn't even possible for writers to decide on presentation until DTP came onto the scene. They just typed up their articles and then the person doing paste-up created the presentation.
A lot of tech people don't get this. You see this in web design, where they think HTML and CSS are separate domains. They think CSS is just pretty effects.
My wife was, and all of her friends still are, journalists. They constantly worry and complain about all of the tasks that were once the domain of trained professionals--photographers, editors, designers--being put on the journalist due to budgetary constraints.
It was truly an awakening to the hidden wonders of the world.