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