Re: A UUID function for web developers

Philipp Kewisch <[email protected]>
Newsgroups gmane.comp.mozilla.devel.seamonkey
Message-ID <[email protected]>
On 3/19/16 9:31 PM, [email protected] wrote:
> It is surreal I have to justify the inclusion of this, because it is already a basic feature in all platforms beside web browsers. You know, if just one team of web browser developers break their long-standing tradition of not including a UUID generator function, all others will follow.
> 
> I'll consider submitting a proposal to the standards bodies, but what if it is rejected or takes any length of time. How can you justify the immeasurable number of manhours that will go to waste, because you resist providing a simple wrapper over a system function call?
> 

A list of other things that could be included in the platform:

* auto-grow text area
* human readable filesizes from numbers
* image format conversion
* sortable tables
* code to create a lightbox effect
* templating
* markdown conversion
* pretty printing and syntax highlighting
* more elements like in jquery-ui
* more functional tools
* ...

As you see, there are a lot of things that are used pretty commonly, and
also a lot of simple items in there. Should they all be in the browser?
I hope you agree this is more than core functionality, just like UUIDs.

If you say "but uuids are even more simple", where in that list should
the line be drawn? Should all the helper functions in jquery be
available natively in the browser, because they are similarly simple?
What about other js libraries? There is always a next thing that is just
a little bit more effort.

What is available in the browser should be most minimal, so that
libraries can be used to implement on top of it. This is for the same
reason that programming languages give you just the basics and libraries
allow extending it. Adding it just because it may be convenient would
not be helpful, as each new feature requires extra work and needs to be
maintained.

Also, if it is implemented and people rely on it, it is hard to make
changes to the API in the future. This is why we prefer going to the
standards body first. If the feature is rejected from the standards
body, then probably for a good reason. If the feature is just available
in Firefox, then you might as well not implement it at all because
developers will have to add the code for other browsers anyway.

As others have mentioned, I don't see this happening in Firefox. I hope
this helps understand why. If you still believe this is a viable option
you can try convincing the standards body, but I think the best option
forward is to continue using libraries as before.

Philipp
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.