Hi Dominic, thanks for open sourcing the library. I have quite a few questions though:
1. Marijn has built an awesome open source richtext library (https://prosemirror.net/) which has a huge plugin ecosystem and bindings with a bunch of front-end frameworks (including React). Is there any specific motivation behind building one from scratch?
2. How is this different from Facebook's own DraftJS lib?
3. What's the story of realtime collaboration support with OT/CRDT? Prosemirror had this in mind when designing its state model and delta model, so it comes with out of the box support for realtime collaborations. Can we expect the same with Lexical?
4. What's the cross platform strategy for Lexical? If I store the editor's state as JSON on the server, how will I render it on devices and native desktop apps?
We've built our own library on top of Prosemirror to power the comments and feedback sections of Zoho Writer - https://writer.zoho.com
I'm always looking out for better approaches/alternatives in this space and I'm curious how different Lexical is. Thanks!
3. Lexical is not strictly tied to collaboration but its plugin system was built to be extensible enough to cater all developers needs. Collaboration is just another plugin (@lexical/yjs) and does listen and perform the conversion every time there's changes in the EditorState.
This model of independent plugins that can be plugged-and-played without further ado also simplifies devX as collaboration can be added later when the application is mature without the need to rethink any of the plugins that were originally created for non-collab plain/rich text.
4. Lexical Web is just the first of many. We want to port the API and fundamentals to various others platforms, including iOS for which we are already performing the initial set of testing. Cross-platform means the API, including Node's will look alike and EditorState and node's properties will be compatible even if behind the scenes the reconciler is constrained by the toolkit available on each platform (and doesn't render or behave 100% like Web's).
One of the big frustrations with DraftJS is that Facebook moved on (which is understandable), but the core repo wasn’t given control to the community, so patches and updates couldn’t be pulled in. Obviously it’s open source and could be hard forked, but that’s not ideal.
I’d be curious if there are plans internally to make sure Lexical continues
to be supported by Facebook and doesn’t end up with the same fate.
I completely understand. I can't guarantee anything, no on can in software. However, we do have a dedicated full-time team working on Lexical. DraftJS never had that, it only had a few part-time maintainers at Facebook.
The examples shown on the site are code editing. Which puts it in direct competition with the more established Monaco from Microsoft [1].
Competition is welcome, but the description sounds like this is more of a library than a finished product (which Monaco isn't), and if so, some examples showing how to take advantage of that would have been helpful.
By the examples, do you mean the fact we are using Codesandbox embed to show code examples of the editor itself?
Lexical definitely has the foundational requirements capable of building a CodeMirror or Monaco editor, but that wasn't our initial target with this library. That doesn't mean that we don't expect the community to push it that way in the future, we fully expect that. Let's see how things go, competition is healthy! :)
Is this in production on Facebook? I have not had the greatest experiences with their rich text editor, from not being able to remove styling on subsequent lines, to getting a nice little note saying that you can't edit rich text posts on mobile. Hoping lexical brings some improvements here.
It is in production at Facebook. We're slowly rolling out to more surfaces, replacing our existing DraftJS implementations as we go. We've noticed a big improvement internally from doing so, both in terms of less bugs but also performance and accessibility.
It crashed after I created a code block, converted it to a quote block, and the hit ctrl+z to undo (something about a history node not being found, I think. Sorry, should have saved the output).
Here I was ready to be crabby about yet another web based rich text editor, but after reading so many comments about how it’s not a good code editor—which it’s not, it’s not one at all atm—I’m kind of just crabby about the discussion being completely about something other than the topic. Y’all, I know it’s a thing in software to curmudgeon everything but can we at least curmudgeon the actual thing it actually is? Or maybe just suspend curmudgeon-ness and see if the thing is deserving of that in the first place?
I understand the API will change, but will the JSON representation in such a way that it's not safe to use currently? I don't mind a bug here and there, but it would be quite serious not to be able to use old content with a new version of the editor.
This has exactly the same maddening maladaptations that forced me to switch browsers for a reasonably adequate Facebook "experience". JavaScript that breaks in older or less popular browsers is not something I think needs to be promulgated even outside Facebook.
> Lexical is an extensible JavaScript web text-editor framework
The terminology is also confusing. In some places its called a library. In other places it's called a framework. Then other commenters mentioned that the demo gives the impression that it is a full package editor, but is just pegging onto CodeMirror. That's clarified here?
> It doesn't directly concern itself with UI components
> core of Lexical is ... a DOM reconciler that takes a set of editor states, diffs the changes, and updates the DOM according to their state.
> Lexical is designed for everyone. It follows best practices established in WCAG
These are weird and conflated set of buzzwords. Why should something that isn't concerned with UI components be concerned with accessibility best practices?
I'm building my own text editor and I thought VSCode was impressive enough. See this well written article about their text buffer reimplementation: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r.... Then I realized Ace.js has some even crazy magic implementation that can handle millions of LoC files without lag. Can Lexical handle 100k+ LoC? Normally I'd benchmark myself, but in this case I don't see other compelling reasons too. The author mentioned the 22kB bundle size is less than Draft.js by Facebook, but Slate.js is 10kB and much more mature.
Some features that could make Lexical have "powerful features" as claimed: UNDO/REDO manager (without storing the entire state on the stack, which is just not scalable on memory), possibly implementing the Command pattern, then make easy consumption of collaborative editing such as with Operational Transform.
Always trips me out how even though a HN users know about software, they judge releases as though they are not software and that they are moment in time and wont get any better.
I'm all for criticism. It is great for everyone, but a library gets open sourced and you're complaining about empty docs? Seriously? Just hold off until it's more mature or open up a PR to add some stuff to the docs.
> I'm building my own text editor and I thought VSCode was impressive enough. See this well written article about their text buffer reimplementation: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r.... Then I realized Ace.js has some even crazy magic implementation that can handle millions of LoC files without lag. Can Lexical handle 100k+ LoC?
Also, to clear up any confusion, Lexical isn't a code editor - it could be used to build one, for sure, but some sort of virtualization would probably be required in order to support millions of lines of code.
Thank for the feedback - we're definitely still working on the docs.
> These are weird and conflated set of buzzwords. Why should something that isn't concerned with UI components be concerned with accessibility best practices?
Are they? Support for speech-to-text technologies and IME/composition input, for example, are independent of UI components.
Internally, we've been replacing Draft.js with Lexical. To be clear though, they're different projects with little API compatibility. We hope to add some docs explaining how we've approached our upgrade path in the future.
To expand on this further, I'll pull this from another HN thread:
Draft.js was built a long time ago when many of the concerns around making contentEditable work stemmed from patching browser-support. Today, it's nowhere near as bad. We can leverage modern events and we can try and tackle things from a different point of view.
One of the core things we've tried to do is make the developer experience and performance better. DraftJS pulled in a lot of JavaScript and much of it was hard to reason with because of the lack of types. ImmutableJS just didn't scale how we would have liked it to, and from our experience, developers didn't really like using it all that much. DraftJS also had a block based approach, which quickly fell apart when you wanted to do something more complex. Not to mention compatibility with React 18+ and the countless issues with having to depend on ReactDOM for rendering when fighting with browser extensions that want to take over control of the DOM from Draft.
With these things in mind, we looked at how we could keep the good ideas from Draft, Slate, ProseMirror and also invent some new ideas of our own. Lexical doesn't have any dependencies, so you can use it with Svelte or Solid (once their bindings have been created), or any other framework of your choice. Lexical also doesn't need ImmutableJS, which means the APIs are fully typed in Flow and TypeScript, reducing issues. Lexical is also around 22kb gzip+min, so it's far smaller than Draft. Typing performance in our testing is around 30-70% faster compared to Draft.
I'd like to hear anyone else's experience of building a Notion like editor (or any other block based/full page editor)
Something guides never cover and I am stuck on is how to let users drop "widgets" into these RTEs. Think photos and galleries, where what is displayed in the editor is not what is present in the output (the real output could be 1+ React tags with attributes set) ; tables where the edit view is a spreadsheet & so on.
When I try to build these I get stuck between the representation in the RTE, the final output, and the "edit mode" in the RTE which may be in its own window.
We already provide most common plugins out of the box (inc. lists and tables) but if you're planning to build a feature rich interface with many custom plugins it may take somewhat longer.
The core Lexical library is really a framework for building such editors. However, we also provide many common rich-text features out-of-the-box via separate packages, such as @lexical/rich-text. We also expose bindings for React (and hope to have them for other frameworks soon). Check out the lexical-playground package on GitHub for an example of how you can create a rich-text editor by adding plugins to the LexicalComposer component in @lexical/react.
Let's say I'm building a stack overflow style editor (you type markdown and it gets rendered in a preview tab) -- would there be any reason to use lexical?
Yeah, you could easily do that. We do the exactly that right now for Workplace.
You could also roll with a `<textarea>` but that can be limiting if you want additional functionality further on down the line – such as mentions or inline markdown shortcuts.
Despite the name (and the misleading-at-first-glance "demo" on the home page), Lexical appears to be a rich text editor like Quill or ProseMirror, not a code editor.
You don't need React. Lexical has no dependencies, so you can build bindings for your framework/library of choice. There are folks working on a SolidJS implementation right now. You could also do it with VanillaJS if you wanted too.
The reason we have React bindings from the start, is because we needed these internally at Meta.
It does. If you get the chance to try Lexical out, please do let us know of any issues you face when using Android, as I'm sure there are some we've yet to find yet.
Is this the text editor used in products like Facebook (Blue), Messenger and Instagram? Because if it is it's buggy and terrible but thanks anyway I guess.
> Lexical is comprised of editor instances that each attach to a single content editable element.
Now if I only knew what was meant by attach, content editable, and element. Then I suspect I don't know what is meant even by comprised or editor.
To me: A bit is a 0 or a 1. A byte is 8 bits in a sequence where by sequence we mean the order of the bits matters. Or in terms of pure math, a byte is not a set but is an 8-tuple.
A file is a sequence of bytes in a file system on a computer. A leading example of such a file system is Microsoft's NTFS -- New Technology File System.
Each byte can be regarded as a character in the Roman alphabet plus the digits 0-9, some punctuation symbols, and a little more, all as in the common, old definition called ASCII (American Standard Code for Information Interchange).
An editor is a computer program that reads a file, displays the bytes as in the ASCII definition, permits a user of the program to modify the bytes and then writes the sequence of bytes to a file again on the file system.
Uh, what is WCAG?
In what sense "minimal"?
For "rich-text features and markdown", by rich-text is meant Unicode, some technique in Microsoft's program Word, D. Knuth's word processing program TeX? For "markdown", I looked that up at Google and found
"Markdown is a text-to-HTML conversion tool for web writers."
So, in particular Markdown is a computer program. Okay.
Again, from Google, apparently React is a JavaScript library for building user interfaces.
I've been a heavy user of text editors for years. The editor Kedit is my most important tool. Macros? Sure, I've written about 300 of them.
Text? I've got good experience with Knuth's TeX: Wrote about 50 macros for TeX and have published applied math I wrote with TeX.
Uh, for a new Web site, I have written code, 100,000 lines of text in Microsoft's Visual Basic .NET using ASP.NET and ADO.NET and some for their "platform invoke". The 100,000 lines of code runs, apparently as intended. To type in the code, I just used Kedit -- worked great.
But I did nothing with React or JavaScript.
After reading the OP and more, I still have no idea what Lexical is, what it is for, what it can do as an editor, why anyone would use it, etc.
I write this post because in my work far and away the biggest obstacle is getting meaningful information from the available documentation. E.g., I spent all of yesterday on the question, what is a video adapter card? Such cards go for $15, $65, or $500, but what the cards are and the differences are not made at all clear. Before that, I wasted several days working with Microsoft's programs COMP and FC, intended to compare files. I gave up and wrote my own program to compare files. Before that I wasted 1+ weeks mud wrestling trying to get an HP laptop and Windows 10 to write some DVDs -- after wasting several supplies of DVDs, DVD-R, DVD+R, DVD+RW, I concluded that somehow HP or Microsoft just doesn't want people writing DVDs -- millions of bytes of documentation and several YouTube videos didn't contradict that conclusion.
Another problem, Microsoft's Outlook 2003, that I used successfully for years, now won't read my email from my ISP (Internet Service Provider). I wrestled with that problem for some days and finally decided to use Thunderbird. Reading email should not be difficult -- for some years I used my own email software I'd written just with the scripting language Rexx and its way to use TCP/IP.
I mention these problems because they are, in the world of computing, simple, trivial, old, etc., should be taken for granted but all of them remain.
The real, original, core creative work, with some pure and applied math, for my Web site has been fast, fun, and easy, but the real problem that has nearly ruined my effort is bad documentation of the tools I must use.
Now along comes Lexical where I can get no idea at all what the heck they are talking about -- to me that is an example of a big problem in computing.
I think the answer to your woes is to accept that the computing domain (while labelled by a single word "computing"), in reality is so vast that no one can expect to be a master of it all. Most of us are content to carve out our own little niche; I for one have no idea what a video adapter card is, nor how Tex works, but I have good grasp of what a content editable element is, and so on.
The computing domain is perhaps peculiar compared to other domains too, in that there is no "basic concepts" that one needs to master to understand everything else (like mathematics for example). One can live a good life as a web developer without knowing the innards of a database, and vice versa. It is not a big problem in computing, it's just the nature of the field.
lewisjoe|3 years ago
1. Marijn has built an awesome open source richtext library (https://prosemirror.net/) which has a huge plugin ecosystem and bindings with a bunch of front-end frameworks (including React). Is there any specific motivation behind building one from scratch?
2. How is this different from Facebook's own DraftJS lib?
3. What's the story of realtime collaboration support with OT/CRDT? Prosemirror had this in mind when designing its state model and delta model, so it comes with out of the box support for realtime collaborations. Can we expect the same with Lexical?
4. What's the cross platform strategy for Lexical? If I store the editor's state as JSON on the server, how will I render it on devices and native desktop apps?
We've built our own library on top of Prosemirror to power the comments and feedback sections of Zoho Writer - https://writer.zoho.com
I'm always looking out for better approaches/alternatives in this space and I'm curious how different Lexical is. Thanks!
zurfyx|3 years ago
3. Lexical is not strictly tied to collaboration but its plugin system was built to be extensible enough to cater all developers needs. Collaboration is just another plugin (@lexical/yjs) and does listen and perform the conversion every time there's changes in the EditorState.
This model of independent plugins that can be plugged-and-played without further ado also simplifies devX as collaboration can be added later when the application is mature without the need to rethink any of the plugins that were originally created for non-collab plain/rich text.
4. Lexical Web is just the first of many. We want to port the API and fundamentals to various others platforms, including iOS for which we are already performing the initial set of testing. Cross-platform means the API, including Node's will look alike and EditorState and node's properties will be compatible even if behind the scenes the reconciler is constrained by the toolkit available on each platform (and doesn't render or behave 100% like Web's).
zeroonetwothree|3 years ago
andygcook|3 years ago
I’d be curious if there are plans internally to make sure Lexical continues to be supported by Facebook and doesn’t end up with the same fate.
trueadm|3 years ago
petilon|3 years ago
Competition is welcome, but the description sounds like this is more of a library than a finished product (which Monaco isn't), and if so, some examples showing how to take advantage of that would have been helpful.
[1] https://microsoft.github.io/monaco-editor/
trueadm|3 years ago
Lexical definitely has the foundational requirements capable of building a CodeMirror or Monaco editor, but that wasn't our initial target with this library. That doesn't mean that we don't expect the community to push it that way in the future, we fully expect that. Let's see how things go, competition is healthy! :)
cetra3|3 years ago
trueadm|3 years ago
dang|3 years ago
Lexical is now open-source (web text-editor) - https://news.ycombinator.com/item?id=31017943 - April 2022 (13 comments)
bhl|3 years ago
SaulJLH|3 years ago
petepete|3 years ago
HL33tibCe7|3 years ago
stareatgoats|3 years ago
Of course inclined to believe you, but do you have a source to back this up?
koheripbal|3 years ago
manigandham|3 years ago
asxd|3 years ago
zurfyx|3 years ago
mlajtos|3 years ago
https://github.com/facebook/lexical/blob/4e57eb8d7e0ca00fe99...
zurfyx|3 years ago
eyelidlessness|3 years ago
dabedee|3 years ago
compiotr|3 years ago
Vivtek|3 years ago
Disappointing.
alephnan|3 years ago
More than half docs page are blank:
- https://lexical.dev/docs/concepts/commands
- https://lexical.dev/docs/getting-started/quick-start
- https://lexical.dev/docs/concepts/extending-nodes
- https://lexical.dev/docs/concepts/editor-state
- https://lexical.dev/docs/api/lexical
- https://lexical.dev/docs/api/lexical-selection
- https://lexical.dev/docs/api/lexical-text
- https://lexical.dev/docs/api/lexical-offset
> An extensible text editor library
> Lexical is an extensible JavaScript web text-editor framework
The terminology is also confusing. In some places its called a library. In other places it's called a framework. Then other commenters mentioned that the demo gives the impression that it is a full package editor, but is just pegging onto CodeMirror. That's clarified here?
> It doesn't directly concern itself with UI components
> core of Lexical is ... a DOM reconciler that takes a set of editor states, diffs the changes, and updates the DOM according to their state.
> Lexical is designed for everyone. It follows best practices established in WCAG
These are weird and conflated set of buzzwords. Why should something that isn't concerned with UI components be concerned with accessibility best practices?
I'm building my own text editor and I thought VSCode was impressive enough. See this well written article about their text buffer reimplementation: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r.... Then I realized Ace.js has some even crazy magic implementation that can handle millions of LoC files without lag. Can Lexical handle 100k+ LoC? Normally I'd benchmark myself, but in this case I don't see other compelling reasons too. The author mentioned the 22kB bundle size is less than Draft.js by Facebook, but Slate.js is 10kB and much more mature.
Some features that could make Lexical have "powerful features" as claimed: UNDO/REDO manager (without storing the entire state on the stack, which is just not scalable on memory), possibly implementing the Command pattern, then make easy consumption of collaborative editing such as with Operational Transform.
motoxpro|3 years ago
I'm all for criticism. It is great for everyone, but a library gets open sourced and you're complaining about empty docs? Seriously? Just hold off until it's more mature or open up a PR to add some stuff to the docs.
acywatson|3 years ago
Also, to clear up any confusion, Lexical isn't a code editor - it could be used to build one, for sure, but some sort of virtualization would probably be required in order to support millions of lines of code.
acywatson|3 years ago
> These are weird and conflated set of buzzwords. Why should something that isn't concerned with UI components be concerned with accessibility best practices?
Are they? Support for speech-to-text technologies and IME/composition input, for example, are independent of UI components.
> but Slate.js is 10kB and much more mature.
Is it?
https://bundlephobia.com/package/slate@0.77.0
johnny35|3 years ago
trueadm|3 years ago
To expand on this further, I'll pull this from another HN thread:
Draft.js was built a long time ago when many of the concerns around making contentEditable work stemmed from patching browser-support. Today, it's nowhere near as bad. We can leverage modern events and we can try and tackle things from a different point of view. One of the core things we've tried to do is make the developer experience and performance better. DraftJS pulled in a lot of JavaScript and much of it was hard to reason with because of the lack of types. ImmutableJS just didn't scale how we would have liked it to, and from our experience, developers didn't really like using it all that much. DraftJS also had a block based approach, which quickly fell apart when you wanted to do something more complex. Not to mention compatibility with React 18+ and the countless issues with having to depend on ReactDOM for rendering when fighting with browser extensions that want to take over control of the DOM from Draft.
With these things in mind, we looked at how we could keep the good ideas from Draft, Slate, ProseMirror and also invent some new ideas of our own. Lexical doesn't have any dependencies, so you can use it with Svelte or Solid (once their bindings have been created), or any other framework of your choice. Lexical also doesn't need ImmutableJS, which means the APIs are fully typed in Flow and TypeScript, reducing issues. Lexical is also around 22kb gzip+min, so it's far smaller than Draft. Typing performance in our testing is around 30-70% faster compared to Draft.
shubham_sinha|3 years ago
porker|3 years ago
Something guides never cover and I am stuck on is how to let users drop "widgets" into these RTEs. Think photos and galleries, where what is displayed in the editor is not what is present in the output (the real output could be 1+ React tags with attributes set) ; tables where the edit view is a spreadsheet & so on.
When I try to build these I get stuck between the representation in the RTE, the final output, and the "edit mode" in the RTE which may be in its own window.
zurfyx|3 years ago
We already provide most common plugins out of the box (inc. lists and tables) but if you're planning to build a feature rich interface with many custom plugins it may take somewhat longer.
philfreo|3 years ago
What is the format that it creates that you could then persist in a database? Does it just save its state in HTML or some JSON format or what?
acywatson|3 years ago
vsroy|3 years ago
trueadm|3 years ago
You could also roll with a `<textarea>` but that can be limiting if you want additional functionality further on down the line – such as mentions or inline markdown shortcuts.
unknown|3 years ago
[deleted]
jasonshen|3 years ago
zaptheimpaler|3 years ago
trueadm|3 years ago
unknown|3 years ago
[deleted]
unknown|3 years ago
[deleted]
melony|3 years ago
trueadm|3 years ago
rattray|3 years ago
csande17|3 years ago
Thexyman|3 years ago
jzer0cool|3 years ago
zurfyx|3 years ago
rvnx|3 years ago
vbezhenar|3 years ago
acywatson|3 years ago
https://github.com/facebook/lexical/issues/new?assignees=&la...
unknown|3 years ago
[deleted]
endisneigh|3 years ago
trueadm|3 years ago
The reason we have React bindings from the start, is because we needed these internally at Meta.
tvararu|3 years ago
Really neat that it has no dependencies and works with anything.
Rodeoclash|3 years ago
trueadm|3 years ago
shashanoid|3 years ago
jbverschoor|3 years ago
bauripalash|3 years ago
slappy7|3 years ago
trueadm|3 years ago
mdoms|3 years ago
graycat|3 years ago
Now if I only knew what was meant by attach, content editable, and element. Then I suspect I don't know what is meant even by comprised or editor.
To me: A bit is a 0 or a 1. A byte is 8 bits in a sequence where by sequence we mean the order of the bits matters. Or in terms of pure math, a byte is not a set but is an 8-tuple.
A file is a sequence of bytes in a file system on a computer. A leading example of such a file system is Microsoft's NTFS -- New Technology File System.
Each byte can be regarded as a character in the Roman alphabet plus the digits 0-9, some punctuation symbols, and a little more, all as in the common, old definition called ASCII (American Standard Code for Information Interchange).
An editor is a computer program that reads a file, displays the bytes as in the ASCII definition, permits a user of the program to modify the bytes and then writes the sequence of bytes to a file again on the file system.
Uh, what is WCAG?
In what sense "minimal"?
For "rich-text features and markdown", by rich-text is meant Unicode, some technique in Microsoft's program Word, D. Knuth's word processing program TeX? For "markdown", I looked that up at Google and found
"Markdown is a text-to-HTML conversion tool for web writers."
So, in particular Markdown is a computer program. Okay.
Again, from Google, apparently React is a JavaScript library for building user interfaces.
I've been a heavy user of text editors for years. The editor Kedit is my most important tool. Macros? Sure, I've written about 300 of them.
Text? I've got good experience with Knuth's TeX: Wrote about 50 macros for TeX and have published applied math I wrote with TeX.
Uh, for a new Web site, I have written code, 100,000 lines of text in Microsoft's Visual Basic .NET using ASP.NET and ADO.NET and some for their "platform invoke". The 100,000 lines of code runs, apparently as intended. To type in the code, I just used Kedit -- worked great.
But I did nothing with React or JavaScript.
After reading the OP and more, I still have no idea what Lexical is, what it is for, what it can do as an editor, why anyone would use it, etc.
I write this post because in my work far and away the biggest obstacle is getting meaningful information from the available documentation. E.g., I spent all of yesterday on the question, what is a video adapter card? Such cards go for $15, $65, or $500, but what the cards are and the differences are not made at all clear. Before that, I wasted several days working with Microsoft's programs COMP and FC, intended to compare files. I gave up and wrote my own program to compare files. Before that I wasted 1+ weeks mud wrestling trying to get an HP laptop and Windows 10 to write some DVDs -- after wasting several supplies of DVDs, DVD-R, DVD+R, DVD+RW, I concluded that somehow HP or Microsoft just doesn't want people writing DVDs -- millions of bytes of documentation and several YouTube videos didn't contradict that conclusion.
Another problem, Microsoft's Outlook 2003, that I used successfully for years, now won't read my email from my ISP (Internet Service Provider). I wrestled with that problem for some days and finally decided to use Thunderbird. Reading email should not be difficult -- for some years I used my own email software I'd written just with the scripting language Rexx and its way to use TCP/IP.
I mention these problems because they are, in the world of computing, simple, trivial, old, etc., should be taken for granted but all of them remain.
The real, original, core creative work, with some pure and applied math, for my Web site has been fast, fun, and easy, but the real problem that has nearly ruined my effort is bad documentation of the tools I must use.
Now along comes Lexical where I can get no idea at all what the heck they are talking about -- to me that is an example of a big problem in computing.
stareatgoats|3 years ago
The computing domain is perhaps peculiar compared to other domains too, in that there is no "basic concepts" that one needs to master to understand everything else (like mathematics for example). One can live a good life as a web developer without knowing the innards of a database, and vice versa. It is not a big problem in computing, it's just the nature of the field.